Max Transport Latency - nRF5340 Audio DK

[ayushFF]

Hi,

I wanted to know what the maximum transport latency does. It seems that no matter what I set the max transport latency parameter to, it is always at 20ms.

I verified this by checking latency between a gateway and headset on the oscilloscope, and i was getting a total latency of around 34ms (transport latency = 20ms + Pres Delay = 10ms + 4ms?). Not sure what the additional 4ms is for, maybe it is the encoding+decoding delay?

Does the controller somehow default to 20ms because this is the minimum required for a stereo stream? Increasing max transport latency to 40 or 65ms still gives a 20ms transport latency, and I would imagine that higher max transport latency would let the controller send packets over multiple isochronous intervals by changing PTO and IRC, but this does not seem to be the case.

BR,

Ayush

[Karl Ylvisaker]

Hello Ayush,

ayushFF said:

Thanks for getting back to me and I hope you're doing well.

Thank you for saying so! :) 

ayushFF said:

Regarding configurations, I tested with 48 KHz, for 80Kbps and 96Kbps streams, and with a retransmission number of both 4 and 1, with presentation delay of 10ms and transport latency of 20ms. They all showed the same overall latencies.

Thank you for the clarification.
Regarding the retransmissions I should also note that the later retransmissions will not be sent if the first packet is acknowledged.
Lastly, could you detail your test setup that you use to measure the end-to-end latency?

I will make sure to update you here once the next release is live.

Best regards,
Karl

[ayushFF]

Hi Karl,

Sorry, I forgot to mention that I am testing for Broadcasts, so all the retransmissions would be required i guess, and then the transport latency would always be 20ms?

The test setup for latency is simple, I have one channel of the oscilloscope probing the Line-In Tip / Ring on the Gateway and another channel probing the Headphone Tip on the Headset. I then send a one-shot sine wave to the gateway and measure the time difference between the start of the sine wave on the two channels

Best Regards,

Ayush

[Karl Ylvisaker]

Hello again, Ayush

I just heard from some colleagues that we plan to release a new controller version with the next version of nRF Connect SDK - the v2.5.0. We do not have a public release date for this, but my personal guess - based on previous nRF Connect releases and the general nRF Connect release schedule - is that this release likely will happen towards the end of October.
If you require a more exact date or answer to this you will have to reach out to your Regional Sales Manager (RSM) to discuss this, since they have the information about future releases and roadmaps.

Apologies for the questions from your previous comment falling through the cracks and taking so long to get back to:

ayushFF said:

Sorry, I forgot to mention that I am testing for Broadcasts, so all the retransmissions would be required i guess, and then the transport latency would always be 20ms?

Correct - the gateway will not receive any acknowledgements in this case, and so it will transmit the configured number of retransmissions +1 each ISO event. Your total end-to-end latency should still be the same regardless of which of the transmissions that are picked up by the headset due to the presentation delay.

ayushFF said:

The test setup for latency is simple, I have one channel of the oscilloscope probing the Line-In Tip / Ring on the Gateway and another channel probing the Headphone Tip on the Headset. I then send a one-shot sine wave to the gateway and measure the time difference between the start of the sine wave on the two channels

Thank you for clarifying this - it is helpful for me to know how the measurements are produced! :) 

Best regards,
Karl