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,

I recall a potential bug being reported with the transport latency configuration some time back. I will have to check the current status of this with the developers, and I will get back to you on Monday about this.

Best regards,
Karl

[ayushFF]

Hi Karl,

Just wanted to know if you heard anything further regarding this. I also tested a case for Mono (num. BIS = 1) and it seems the transport latency seems to be the same as Stereo (20 ms).

Would you be able to share some documentation regarding how the controller schedules the transmissions? I would imagine that Mono takes half the time to transport compared to stereo, but it seems the controller implementation assumes a stereo stream always and thus dedicates a 20 ms slot to transmit the payloads, regardless of the number of BISes in the group.

Best regards,

Ayush

[Karl Ylvisaker]

Hello Ayush,

Thank you very much for your extreme patience with this - I was unfortunately out of office during the start of this week due to sickness, but now I am back.

Having discussed this with my colleagues there seems to be a bug within the controller that prevents the flush timeout from increasing according to the defined max transport latency.
Your initial assessment is also correct, that a higher max transport latency (and flush timeout) will increase the reliability of the sender since it will allow it to attempt the same packet over multiple ISO events.

Lastly, what parameters were you using when you measured the end-to-end latency?
The 34 ms results is within the ballpark of what I would have expected, but if this is using the default configuration of the nRF5340 Audio project then there are configurations you could change to optimize further for latency if that is your goal.

The fix for this issue is scheduled to be part of the next controller release, which to my knowledge likely will be available sometime first half of September.
Fortunately, this release will also contain the documentation you request regarding the scheduling within the controller.

Best regards,
Karl

[ayushFF]

Hi Karl,

Thanks for getting back to me and I hope you're doing well. Good to know that its a bug that will be fixed soon.

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.

Best Regards,

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