nrf5340 Audio interference and packet loss

[adunk]

When playing around with the nrf5340 Audio demo using nrf5340 Audio eval kits, if you play a tone through USB and transmit that through the Gateway to the Headset, you can hear glitches in the audio stream as you cover the PCB with your hand and start to move away from the board. You can start to hear them from just a few feet away. 

We have a product that is using this functionality and wanted to use a tone for verification and noticed this. Then I noticed its a problem on the eval kits and the nrf5340 audio demo straight out of the box. Latency is a priority to us but I made some tweaks to the Bluetooth Audio QoS retransmit values. I changed them from 2 to 8 and it definitely seemed to improve the packet loss/audio quality. Is there any documentation about whether this retransmission count is used and if it will be maxed out based on the latency maximums? I don't want to increase my latency by increasing the retransmission count and I'm assuming the device won't retransmit any longer once it reaches the packet frame time.

Thanks!

[Maria Gilje]

Hello,

Which nRF Connect SDK version are you using?

Please specify which device you are covering: headset or gateway?

Best regards,

Maria

[adunk]

SDK 2.6.1
Covering headset or you can just start to walk away

[adunk]

I have increased the retransmissions to the maximum value of 30 and am seeing very positive results on the audio quality. From our measurements, it doesn't appear to be increasing the latency, but I am still hoping to see some documentation on how the QoS values are used and implemented. Our tests indicate the way Nordic implemented it is that the latency setting sets the flush out time and although the maximum number of retransmissions is 30, if the flush out time occurs before then, it will stop retransmitting and move on to the next packet. But I'd like to see some documentation to illustrate this.

It would be very challenging to measure the latency only during times of poor audio quality so I'd like to ensure the latency is a constant and controls the maximum number of retries rather than the other way around.

[Maria Gilje]

Hello,

Thank you for your significant patience.

adunk said:

Our tests indicate the way Nordic implemented it is that the latency setting sets the flush out time and although the maximum number of retransmissions is 30, if the flush out time occurs before then, it will stop retransmitting and move on to the next packet. But I'd like to see some documentation to illustrate this.

The Bluetooth controller will select a suitable set of parameter based on what the host configures, see the documentation for SoftDevice Controller LE Isochronous Channels for details.

There are some nice examples which illustrates the effects of the audio quality and robustness parameters in Ch. 4.3.2 of the Introducing Bluetooth LE Audio book by Nick Hunn. Is that the kind of documentation you are looking for?

Best regards,

Maria

[adunk]

Was there ever any attempt to duplicate playing a tone on the audio demo? We are able to hear glitches and interruptions when playing a tone from the gateway to the headset when 10-20 feet away. Is this expected? Is it possible there is something different playing a tone versus audio? Maybe it can't be compressed?

[Maria Gilje]

Hello,

There could be two explanations for the playback artifacts: packet loss and non-optimized encoding. The packet loss concealment is good for music and speech but can be noticed for a tone. The LC3 codec is optimized for speech and music, so hearing artifacts on a transmittied tone is somewhat expected.

Best regards,

Maria