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.

[AHaug]

Hi,

I've picked up your case and will look into your questions and I will get back to you asap.

Kind regards,
Andreas

[AHaug]

Hi,

Here's some input from the Audio team:

The nRF5340 plays the role of master in I2S, since there could be a chance that I2S clock could drift. And nRF5340 will use BLE timing as a ruler, for checking if I2S is too fast or too slow and then tuning it a little bit. That's drft compensation in audio datapath module.

Based on the request the Audio team has a clarification question: It wouls seem like you're aiming to make the nRF5340 as an I2S slave, which we don't support, since once you cannot change the speed of the I2S, we can't do drift compensation. 

Could you clarify if you're attempting to make the nRF5340 as an I2S slave or if we've misread your query?

Kind regards,
Andreas

[Larry_rad]

Hi Andreas

Thank you for your reply and for the input from the audio team.  We are an audio product consultancy so we may have high standards with this.

MCLK is not strictly I2S, usually I2S master or slave governs the frame/word/lr sync and the bit clock only.  With MCLK only required to the audio IC if the IC has a processor that requires some clock cycles between samples.  It is essential in high quality audio systems to have high accuracy clocks or oscillators providing the MCLK, generating clocks in processors or adjusting them on the fly even with PLLs leads to jitter and poor sound quality, which once embedded cannot be recovered.  If the 'adjustment' contains a frequency component, this decodes as an FM sideband to the original audio and doesn't sound good on a quality system.

In relation to there could be a chance the I2S clock could drift.  If the system is synchronised to a single clock running at an audio frequency multiple there cannot be drift, and that is the standard within audio design. This is especially important with the requirement to have multiple modules connected in tandem.

We are happy to use master or slave mode, whichever gives us good quality from the system, but from what you have said with MCLK and I2S as master only, and also having drift compensation I'm not sure the current system can provide that.

It is these above requirements which prompted our initial questions.

Essentially, to use a single nRF5340 module in a high quality solution requires the I2S to be generated or at least clocked in relation to MCLK from a low jitter external oscillator.

Using multiple nRF5340s in a system is made very easy to synchronise if again the MCLKs and I2S are inputs (I2S slave).

Our ideal would be to change the 32MHz system clock to 24.576MHz and bus it to all parallel nRF5340 modules, then the modules would have the best EMC coexistence performance, and all I2S would synchronous.  To have multiple modules outputting I2S requires all modules to be in I2S slave mode so the destination is the master.

If these important features most customers would require, can they be added to the SDK?  If so how long could this take?

I look forward to your reply.

Thanks and best

Larry.

[AHaug]

Hi Larry,

Noted, thank you for elaborating. I will have to discuss this with the audio team to fully understand the implications in what you're writing. I will return to you when I have an update for you, hopefully before the weekend.

Kind regards,
Andreas

[AHaug]

Hi Larry,

I have some follow up questions while waiting for a reply and some additional information.

From the nRF5340 I2S specification there's no way to set nRF5340 MCLK as input (which is our understanding of your request).

The MCLK for nRF5340

1. Can be disabled
2. Can be enabled, both in master/slave mode.
   But can only be output, with selected clock source (32MHz or audio PLL)

But there's no way to set MCLK as input. I'll double check with the 5340HW team internally and get back to you with an update regarding this unless this clarifies things for you. From P312 in the PS

As to why we adjust the MCLK in the system: AFAIK this is to ensure that you don't get buffer under/overruns. Using a clocking system as you suggest will lead to buffer under/overruns over time.

Could you also clarify why you need more than devices than 1 (I'm assuming it is for stereo, but feel free to expand anyways)? We're considering if the nRF54H20 may be a better fit for your project

Kind regards,
Andreas

[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