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

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.

  • Hi,

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

    Kind regards,
    Andreas

  • 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

  • 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.

Related