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,

Thanks for the response! Looking forward to knowing more about it.

[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