nRF5340, Audio transmission delay between 2 peripherals (Tx1 and Tx2)

[tommy]

We could have found "transmission delay" in 2ch Audio recording sequence.

Here are the detail about the environment of DUT, and phenomenon.

Please find the attached file.

 

Would it be possible to let us know the possible cause of this delay?

 

We are using ver2.3.0 as NCS.

In addition, this phenomenon has been found in our pre-production model.

And if you can suggest any test environment provided by nordic's EVK to immitate, it would be highly appreciated.

 

BR,

4353.TX1TX2_difference.pptx

[SwRa]

Hello,

I just had a discussion with our R&D and was informed that this has already been discussed directly with them.. In short, we don't have synchronization mechanism for L and R send back to the central.. Synchronization only happens on the headset side.. It was informed to us that Canon will upgrade the SDK shortly.. But even then, this is a missing feature.

Best Regards,

Swathy

[tommy]

Thanks SwRa.

Here is my understanding, is it right?

“fs” on Left Acceptor and Right Acceptor are not synchronized via 2CIS’s transaction and transmission delay among 2 acceptors will not be resolved.

It is inevitab;e as a principle of LC3 and will certainly occur.

[Amanda Hsieh]

Hi, 

Swathy is out of the office, so I picked up this case. 

As Swathy gets from the developer: we don't have a synchronization mechanism for L and R to send back to the central. Synchronization only happens on the headset side.

We are using ver2.3.0 as NCS.

Your NCS version is a bit old. Could you test again with the latest version, v2.8.0?

-Amanda H.

[tommy]

Amanda,

Thank you for your supprt.

I understood that the wireless communication can be synchronized by ISO_Interval.
(And I think this issue surely occur regardless of the version.)

The each of the two microphones will occur individual clock drift for sampling frequency as 48kHz or 96kHz and as a result the audio from the two microphones will not be exactly synchronized.

Actually, this is a slight delay(the order is msec or usec), but in some cases such as a professional video recording, it's keen to minimize it.

If there is no way to sync, we would like to even assure maximum, minimum value of this delay.

Can you provide quantitive value for nrf5340?

And if there is a way to solve, we think one of the solution is to use RTC (Real-Time Clock) synchronization between TX and RX by BT command.

 

[Amanda Hsieh]

Hi, 

From the team:

For safety, I would say the range could be less than 20ms (2 ISO interval).

-Amanda H.

[tommy]

Amanda,

May I get some more detailed answer?

How could your team justify "20msec is safe"?
How could they derive this value theoretically?

BR,

[Amanda Hsieh]

Hi, 

Once if we start the audio stream, the unicast server will do sampling and push the data to ISO immediately, so the diff should be in 1 ISO interval.

The reason why there's a small gap is that there's no presentation delay mechanism for syncing between L and R for the gateway side (this only happens on the headset side, for the TWS scenario)

2 x ISO interval is because now we would like to put the data into a queue for small buffering

-Amanda H. 

[tommy]

>there's no presentation delay mechanism for syncing between L and R for the gateway side (this only happens on the headset side, for the TWS scenario)

Introducing-Bluetooth-LE-Audio-book states that Presentation Delay applies from Peripheral to Central concerning audio capture.

From Introducing-Bluetooth-LE-Audio-book
"Presentation Delay is also applied to audio capture, where audio data is travelling from an
Acceptor to an Initiator (denoted in the specs as P>C, or Peripheral to Central)."

Is my understanding correct that Presentation Delay is is applied in the BT standard although it is not applied in the nRF Connect SDK?

Introducing-Bluetooth-LE-Audio-book.pdf

[Amanda Hsieh]

Hi, 

Currently, our solution only focuses on the presentation from the unicast client to the unicast server (TWS scenario). We haven't added the pres-comp for MIC streams since our unicast client will only decode and output one MIC stream from two unicast servers.

-Amanda H.