I2S MCLK as input for syncing multiple nRF5340 running 24bit 48kHz audio

[Larry_rad]

Hi

We have an application in hardware development that requires multiple nRF5340 (PAN1783 modules) syncd together, so the I2S outputs can be input to an external DSP.  The firmware will be based on the Nordic headset app.

The external DSP will run from an audio clock that is 12.288MHz or 24.576Mz to support the 48kHz only output.  The DSP has inputs that only use the frame, bit clock and data, so the MCLK in is not a problem.  But it is possible and likely that due to not being clocked from the same source the timing will drift over time and lose sync. For high quality audio we require all processors to be running from the same clock source for guaranteed timing, and even if the 32MHz system clock could divide down perfectly, it is still not as suitable for high quality audio as a low jitter clock source.  So this leads to some questions.

1. I have looked at the I2S MCLK setup code for the V2.5.2 SDK and seen there is no easy way to change the MCLK to an input. Has this changed on the latest SDK or is it planned to?
2. If the MCLK was an input, does the nRF5340 have the capability to run the I2S code from MCLK input?  Or does this code only operate from the 32MHz system clock?
3. Could the 32MHz system clock be replaced with a 24.576MHz clock? What would be the implications to the rest of the system especially the BLE-Audio?

Thanks in advance

Larry.

[Larry_rad]

Hi Andreas

Thank you for you informative answer.  

Does the product spec relate to hardware blocks of the device or firmware?  If it is firmware it looks to be a very simple modification to the MCLK signal flow to have a MCLK input generate the SCLK and LRCLK. Of course SDATA would not be related and that would require the easy DMA to be either synchronous in time/frequency, or running at a suitably higher speed to ensure SDATA is always ready in time for the SCLK and frame sync.

The next question that hasnt been mentioned is to ask how BLE Audio handles sample contingency. I assume that as the RX of the headset app is the server it will define the sync of the BLE so this MCLK is the most critical to output good quality audio. If we wish to switch direction of the BLE Audio data, must the RX always be the server?

Am happy to share project details with Nordic although we are under NDA with our customer so we would have to set this up and share privately.

All the best

Larry.

[AHaug]

Hi,

Larry_rad said:

Does the product spec relate to hardware blocks of the device or firmware?  If it is firmware it looks to be a very simple modification to the MCLK signal flow to have a MCLK input generate the SCLK and LRCLK. Of course SDATA would not be related and that would require the easy DMA to be either synchronous in time/frequency, or running at a suitably higher speed to ensure SDATA is always ready in time for the SCLK and frame sync.

My understanding is that MCLK is seen as an output from the hardware.

Larry_rad said:

The next question that hasnt been mentioned is to ask how BLE Audio handles sample contingency. I assume that as the RX of the headset app is the server it will define the sync of the BLE so this MCLK is the most critical to output good quality audio. If we wish to switch direction of the BLE Audio data, must the RX always be the server?

I'll have to check with the audio team w.r.t this

Larry_rad said:

Am happy to share project details with Nordic although we are under NDA with our customer so we would have to set this up and share privately.

The reason we're mentioning the nRF54H20 is mainly due to more processing powers so you can encode/decode more channels in parallel and it has the TDM interface so you can run more channels from one device. These will then be running from the same MCLK so they will be in sync. However it will still use the ADPLL so the clock will be adjusted, i.e you won't get around the same issue this way as you're asking about w.r.t setting the MCLK as input.

If you need the contact information to your the RSM in your location to discuss this closer, let me know and I'll relay it to you.

Kind regards,
Andreas