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

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

kieran.cheung — Thu, 16 Feb 2023 08:49:22 GMT

Hi Kenneth,

I've just been informed by the headphone manufacturer that their technical team has also encountered this problem when interfacing with certain devices and will be submitting a case with Qualcomm who must be supplying the LE Audio firmware component for the headphones.

Once I receive an update on this issue I will try again, but for now I'm assuming this bug is completely due to the headphone side.

Thanks for your help!

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

Kenneth — Wed, 15 Feb 2023 15:39:42 GMT

They are discussing this internally, but from the log it seems the headset is OK with the QoS setting, but suddenly headset disconnected. The reason is 0x08, which means headset stop sending any packets. Probably the issue is from headset side. Will let you know if I receive more feedback internally.

Kenneth

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

kieran.cheung — Wed, 15 Feb 2023 14:17:06 GMT

Hi Kenneth,

Here is the log I get when trying to connect using a build of the 5340 application from version 2.2.99-dev3 with only the following changes in addition to the log flags you mentioned.

CONFIG_BT_AUDIO_PRESENTATION_DELAY_US=25000
CONFIG_BT_AUDIO_MAX_TRANSPORT_LATENCY_MS=30
Connecting to headphones based on their name.

devzone.nordicsemi.com/.../Connection-Attempt-Log.txt

After the timeout, at ~15.9s the device then continuously finds and fails to pair to the headphones until I cycle both. I believe this is because the initial headphone that the gateway tries to enable the stream to asserts (it visibly seems to blink red and turn off while the other continues blinking for advertising) and the other one keeps advertising, but security fails because of (I'm guessing) some spec behaviour around pairing to the same address.

I have also reported this to the headphone manufacturer, but as I noted they work with Android which makes it harder to dismiss the problem as only relevant to the headphone and not the 5340.

Thanks

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

Kenneth — Wed, 15 Feb 2023 12:56:53 GMT

We are looking into this, can you add the following config in the gateway for getting more information?

CONFIG_BT_AUDIO_DEBUG_UNICAST_CLIENT=y
CONFIG_BT_AUDIO_STREAM_LOG_LEVEL_DBG=y
CONFIG_LOG_BUFFER_SIZE=8192

Kenneth

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

kieran.cheung — Tue, 14 Feb 2023 09:09:25 GMT

Hi Kenneth,

Thanks for your response,

I have noticed the connection interval seems very critical to LE Audio connections with the 5340, but I haven't found any documentation on what exactly is the appropriate value based on the parameters involved. Why does the audio controller not like 40ms for example?

I have connected to the headphones via the nRF Connect app and they have Published Audio Capability Service (PACS,) Audio Stream Control Service (ASCS,) Volume Control Service (VCS). I had decoded the PACs on the device (see attached) to check that the parameters I was configuring the stream with were valid.

devzone.nordicsemi.com/.../Earfun-PACs.txt

For QoS the only change I made was to increase the presentation delay to 30000us as the headphones were giving response notifications via the LE Audio service when providing the lower default values. With these changes the configure QoS command appears to give a successful completion callback with no warnings.

I will look into getting a sniffer log. The way the headphones are behaving during the error looks like it's the headphone that is asserting. It clearly seems to hard-reset before the 5340 detects a timeout. It's just unusual because they work with Android so there must be something different about the connection with the 5340 that it doesn't like.

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

Kenneth — Tue, 14 Feb 2023 08:27:43 GMT

One question that may help the developers with the debugging: Can you connect to the earbuds with the nRFConnect phone app and see whether there are any LE Audio services there?

Thanks,
Kenneth

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

Kenneth — Mon, 13 Feb 2023 18:46:17 GMT

Hello, I received feedback from one in the gruop working with audio, adding it here:

1. The user tests our headset with Pixel 7 and found the Pixel 7 disconnected after stream start couple seconds later.

This is a known issue, probably because the Pixel 7 sends a connection parameter request for using 40ms ACL interval, which audio controller is not happy and out of response. From my side I can see that Pixel will try to reconnect the headset again in the latest AOSP Android, and then stream can recover, since Pixel will try to use different connection parameters.

There might be a quick workaround is that we add connection parameter request callback, return false if interval_min/max is 0x40. But this is something we will check with the audio controller developers.

It seems during the handshaking, headset will expose the minimal/maximum presentation delay, Pixel chooses the minimal one, but it cannot handle it properly, so glitch happens. We have a PR in the later for telling the Phone uses a higher number.

2. For the case when nRF5340 gateway connects with Earfun, I would assume Earfun refuse the QoS setting from our gateway. I will check if we can low down the log level to see more details. It is hard to figure out where is the issue (central or peripheral). A sniffer log from Ellisys would provide great help.

Kenneth

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

kieran.cheung — Wed, 08 Feb 2023 15:10:40 GMT

Hi Kenneth,

Thanks for your response. I believe I am currently matching the audio parameters supported by the Earfun Air Pro 3.

The only change needed from the default configuration of the gateway demo to match the PACs of these headphones is increasing the presentation delay to 25000 from 10000 us. Everything else can remain the same and matches the Earfun Air Pro 3, although I have also tried with other supported audio parameters.

My problem isn't an error response with the LE Audio interface, it's a generic BLE timeout when issuing the 'enable' command for a stream, after successfully configuring it.

So I think the issue has to either be a general Bluetooth connectivity problem, such as the one that caused the timeouts with Android in a previous SDK version (when the device was acting as a headset,) or an assert within these headphones, although as mentioned the Earfuns do work with Android.

If I knew that the 5340 acting as an audio gateway was able to successfully enable a stream to another off-the-shelf peripheral, that would narrow down the problem to these headphones and I could just purchase that off-the-shelf product if it's out.

I understand that testing and building compatibility takes time but is there a possibility of receiving info on test results with available off-the-shelf products in the near future? Especially as more become publically available for testing outside UPF.

Thanks

Kieran

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

Kenneth — Wed, 08 Feb 2023 14:55:37 GMT

Hello,

After discussion internally I learned that the gateway at the moment is not very flexible, so you would likely need to match the sample rate, bitrate and presentation delay of the Earfun Air Pro 3. An application log from the nRF5340 gatway may help to see how gateway negotiates with Earfun Air Pro 3.

The team is currently working on making the gateway more dynamic, so moving forward you can expect that the gateway will automatically apply whatever the headset is supporting (in other words avoid this manual configuration described above).

Best regards,
Kenneth

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

ClinicalAudio — Wed, 08 Feb 2023 14:46:51 GMT

Following this thread with interest - would be great if there were further updates on the compatibility of the Nordic kit as a gateway device.

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

Kenneth — Wed, 08 Feb 2023 09:42:23 GMT

I will ask around a bit internally and get back to you. Let me know if you have any findings in the meantime.

Kenneth

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

kieran.cheung — Wed, 08 Feb 2023 09:39:27 GMT

Hi Kenneth,

If you could check what testing has been done outside the UPF, it would be much appreciated.

I've seen the thread you posted and seems his initial problem was at the pairing and then location stage, which I haven't had any problems with. I'd specifically be interested if anyone has been able to successfully get a response to the 'enable stream' command with a pair of third party headphones.

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

Kenneth — Wed, 08 Feb 2023 09:22:57 GMT

I can check, but by coincidence this case popped in yesterday:
nRF5340 audio CONNECT_IND Question

Kenneth

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

kieran.cheung — Wed, 08 Feb 2023 09:02:57 GMT

Hi Kenneth, I appreciate the results of the UPF are confidential. However there seems to be a few available off-the-shelf peripherals that support LE Audio. The Earfun Air Pro 3s do to at least some extent, as they work with Android. Could I get a confirmation of whether the team has tested anything outside of the UPF?

Thanks

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

Kenneth — Tue, 07 Feb 2023 11:05:22 GMT

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

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

kieran.cheung — Mon, 06 Feb 2023 13:50:09 GMT

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!

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

Kenneth — Mon, 06 Feb 2023 13:41:17 GMT

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

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

kieran.cheung — Mon, 06 Feb 2023 13:13:06 GMT

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)

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

kieran.cheung — Mon, 06 Feb 2023 12:02:10 GMT

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.