LE Audio timeout behaviour (0x08) interfacing with third party devices.

[kieran.cheung]

Hi, I'm currently developing a device that acts as an LE Audio client. Everything works as expected when interfacing with an LE Audio server counterpart on a 5340 Audio DK, also using the Zephyr BLE Audio API.

However I recently attempted to interface my client with a third party pair of LE Audio headphones, specifically the Earfun Air Pro 3s, and upon enabling the streams (bt_audio_stream_enable) the device receives no response callback and supposedly hits the supervisory timeout (disconnect reason 0x08.) At first I suspected this may be an issue with the headphones, and I haven't ruled out this possibility.

But then I decided to test the nrF5340 audio application (unmodified) with the Android LE Audio framework in the developer settings, which seems to work decently well with the Earfun Air Pro 3s. I found that the 5340 headset application was successfully receiving and playing back the stream for 4s, but then receives a timeout event and immediately stops playing. 

There's a chance these are unrelated issues but seeing as they both involve supervision timeouts, there's the possibility something is not being handled correctly on the 5340? Can something about the LE Audio framework cause it to stop sending packets to the peer device? Has the audio application been tested with any third party devices?

I have tried changing the clock source with:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

As I heard this has been related to other timeout issues, but that doesn't seem to be the cause here as it has no effect.

Log from headset:

HL [00:01:04.268,341] <inf> cis_headset: Connected: 0C:C4:13:2F:AD:44 (public)
HL [00:01:09.610,137] <inf> ble_audio_services: Volume = 10, mute state = 0
HL [00:08:10.497,955] <dbg> bt_audio_stream: bt_audio_stream_attach: conn 0x20002db8 stream 0x2000a728 ep 0x2000ba34 codec 0x2000ba44
HL [00:08:10.587,951] <dbg> bt_audio_stream: bt_audio_stream_iso_listen: stream 0x2000a728 conn 0x20002db8
HL [00:08:10.683,288] <wrn> audio_datapath: I2S RX continuing stream
HL [00:08:10.691,284] <wrn> audio_datapath: I2S RX overrun. Single msg
HL [00:08:10.704,315] <inf> audio_datapath: Drft comp state: INIT
HL [00:08:11.243,072] <dbg> bt_audio_stream: bt_audio_stream_iso_accept: acl 0x20002db8
HL [00:08:11.243,072] <dbg> bt_audio_stream: bt_audio_stream_iso_accept: iso_chan 0x2000bb20
HL [00:08:11.440,124] <inf> audio_datapath: Drft comp state: CALIB
HL [00:08:11.441,101] <wrn> audio_datapath: Data received, total underruns: 755
HL [00:08:11.492,218] <wrn> audio_datapath: Data received, total underruns: 756
HL [00:08:11.540,344] <inf> audio_datapath: Drft comp state: OFFSET
HL [00:08:12.021,820] <inf> audio_datapath: Drft comp state: LOCKED
HL [00:08:12.029,510] <inf> audio_datapath: Pres comp state: MEAS
HL [00:08:12.139,495] <inf> audio_datapath: Pres comp state: WAIT
HL [00:08:12.239,501] <inf> audio_datapath: Pres comp state: INIT
HL [00:08:12.249,511] <inf> audio_datapath: Pres comp state: MEAS
HL [00:08:12.359,497] <inf> audio_datapath: Pres comp state: LOCKED
HL [00:08:16.800,872] <inf> cis_headset: Stream stopped
HL [00:08:16.800,903] <dbg> bt_audio_stream: bt_audio_stream_iso_listen: stream 0x2000a728 conn 0x20002db8
HL [00:08:16.801,727] <inf> cis_headset: Disconnected: 0C:C4:13:2F:AD:44 (public) (reason 0x08)
HL [00:08:16.802,673] <inf> cis_headset: Direct advertising to 0C:C4:13:2F:AD:44 (public) started

[kieran.cheung]

Update: Think upgrading the version of the network controller binary has resolved this issue for the demo application. Will see if it resolves timeout in my original use-case. 

[kieran.cheung]

Unfortunately upgrading to the most recent version of the SDK has not resolved the timeout when the 5340 is acting as a gateway/client.

I have tested the Audio Application on versions 2.2.99-dev3 and 2.2.0 and in both instances a timeout occurs when calling bt_audio_stream_enable() while connected to the Earfun headphones. I have no way of knowing whether this is an issue on the headphones or on the client, however the headphones are able to work with Android on the Google Pixel 7.

The fact that there was also a (now fixed) timeout related issue in the CIS headset mode in a previous version makes me suspect there may be some issue in the gateway mode within the current version? Has the gateway mode been tested with any third party server devices?

I made only minor adjustments to attempt to use the application with the headphones, setting presentation delay to 25000 instead of 10000 as the headphones require this, and changing the scanning process to look for the name of the headphones. Plus some logs to show when things are happening.

Here is the log:

(bt_audio_stream_enable is called just after QOS is set.)

GW [00:00:00.259,490] <inf> fw_info: ------- DEBUG BUILD -------
GW [00:00:00.259,490] <inf> fw_info: Compiled for GATEWAY device
GW [00:00:00.270,111] <inf> board_version: Compatible board/HW version found: 1.0.0
GW [00:00:02.305,999] <wrn> bt_hci_core: Controller to host flow control not supported
GW [00:00:02.309,143] <inf> bt_hci_core: No ID address. App must call settings_load()
GW [00:00:02.309,204] <inf> ble: MAC: 00:00:00:00:00:00 (public)
GW [00:00:02.309,783] <inf> ble: Controller version: 3310
GW [00:00:02.403,839] <inf> cis_gateway: Scanning successfully started
GW [00:00:07.595,367] <inf> cis_gateway: Found Whitelisted Advertiser
GW [00:00:07.680,114] <inf> cis_gateway: Connected: 70:5A:6F:60:62:71 (public)
GW [00:00:11.072,418] <inf> cis_gateway: Scanning successfully started
GW [00:00:11.851,776] <wrn> bt_unicast_client: No space left to parse ASE
GW [00:00:12.752,319] <inf> cis_gateway: Stream configured 0x2000b5ac
GW [00:00:12.752,349] <inf> cis_gateway: LEFT sink stream connected
GW [00:00:12.812,164] <inf> cis_gateway: QOS Set for stream 0x2000b5ac
GW [00:00:16.834,625] <inf> cis_gateway: Disconnected: 70:5A:6F:60:62:71 (public) (reason 0x08)

[Kenneth]

Hello, let me check internally if someone have a suggestion, 0x08 is BLE_HCI_CONNECTION_TIMEOUT, and this happens typically because the supervision timeout is hit (no packets from the peer is received in x seconds), so it could be as you suspect related to tolerance of lfclk (or that the peer asserted/disconnected intentionally for some reason). 

Kenneth

[kieran.cheung]

Hi thanks Kenneth, just to confirm the cis_headset issue definitely appears to have been fixed in some recent update when the 5340 is acting as a headset streaming from a Pixel 7.

But the timeout when enabling a stream as a cis_gateway is still present in the most recent version, at least for these headphones. Unfortunately I don't have any other off-the-shelf headphones to test on, so would be useful to know if any of your devs have had a successful test with an off the shelf peripheral-role product.

Thanks!

[Kenneth]

Hello,

I am not sure if we have officially tested with any third party headsets. I know the team went to Bluetooth UPF (interoperability test event) few weeks back, they did test with third party headphones at the time, but the result from the testing, who participated etc are confidential, so I am not able to find out who and results etc. The only thing I know is that Nordic is participating in these events and do test with third party, so I am sure this will improve if any issues was found. 

Kenneth