• State Not Answered
  • Replies 3 replies
  • Subscribers 65 subscribers
  • Views 1004 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 301967
Options

Clock drift with gateway, I2S slave

John Graley

Hi, we're planning to connect the nRF5340 (running Audio SDK in gateway config) via I2S (and UART) to a custom device. We need to configure the nRF5340 be I2S slave even though the SDK configures it as master. The rate at which nRF5340's I2C interface receives audio data will therefore be governed by the clock source on our custom device, which could drift relative to the clock source in the nRF5340. Is this clock drift likely to be a problem? I have not been able to find the answer in the SDK source code or docs.

I'm aware that drift compensation ability is provided in the code, but it appears not to be applied when the nRF5340 is operating as a gateway - I2S audio data enters a FIFO, goes to LC3 encode, and then across to the LE audio controller on the network core.

I guess my question is, once the isochronous stream is started, does the LE audio controller require blocks of data at a rate governed by the nRF5340 system clock, or is it "flexible" enough to accept data at approximately, but not exactly, this rate?.

Parents
  • 0

    Hi,

    Is this clock drift likely to be a problem?

    Clock drift is going to be present. As a receiver, the nRF5340 device would be able to accept other rates, but this would probably cause buffer underruns and overruns. 

    does the LE audio controller require blocks of data at a rate governed by the nRF5340 system clock, or is it "flexible" enough to accept data at approximately, but not exactly, this rate?.

    For right-left/multi-channel sync it will not work. The master clock is on the sender side, it is propagated to the receiver side over the air and used there to synchronize playback. In your case, this would create 2 master clocks on the receiver side which is not good for audio solution. It is strongly recommended to have a receiving nRF5340 as I2S master. If this is for some reason not possible, then having another master should work, but you would need to find a way how to discard a sample if buffer is full and how to cover the situation with missing sample.

    Best regards,
    Dejan

  • 0 in reply to dejans

    Hi Dejan

    Thanks for your quick reply.

    I would like to clarify our intention:

     - Our custom device is a source of audio, and it passes the audio to an nRF5340 system that is acting as "gateway".

     - We would like the custom device to be I2S master and the gateway-nRF5340 to be the I2S slave.

     - The earbud/headset role could be performed by any third-party device.

     - But for development we'll use a second nRF5340 system in "headset" mode - using a codec chip to get analogue output exactly like the SDK.

    Given this, do we still have a problem? You say the master clock is on the sender side. Do you mean Bluetooth audio sender? If so does that mean the sender can be an I2S slave?

Reply
  • 0 in reply to dejans

    Hi Dejan

    Thanks for your quick reply.

    I would like to clarify our intention:

     - Our custom device is a source of audio, and it passes the audio to an nRF5340 system that is acting as "gateway".

     - We would like the custom device to be I2S master and the gateway-nRF5340 to be the I2S slave.

     - The earbud/headset role could be performed by any third-party device.

     - But for development we'll use a second nRF5340 system in "headset" mode - using a codec chip to get analogue output exactly like the SDK.

    Given this, do we still have a problem? You say the master clock is on the sender side. Do you mean Bluetooth audio sender? If so does that mean the sender can be an I2S slave?

Children
Related