[CIS][SDK3.2.1] nRF5340 with SDK 3.2.1 periodically misses CIS events from Pixel 10 Phone - clicks in audio

[Alex B]

I have a nRF5340 module with an application built using SDK 3.2.1.

The nRF5340 is acting as a CIS Peripheral.

It has an ACL connection and a CIS connection with a Pixel 10 Phone acting as a Central and sending audio over the CIS.

CIS configuration:

• ISO Interval = 10 ms
• NSE = 2
• BN C to P = 1
• BN P to C = 0
• MAX PDU C to P = 40
• PHY C to P = 2M
• PHY P to C = 1M

Sniffer capture of the CIS_REQ packet:

The Audio received on the nRF5340 has some clicks in it.

These are some captures from the sniffer (Teledyne LeCroy Sodera) which showed that the nRF5340 periodically misses some CIS events form the Pixel 10 phone.

The nRF53 also acts as Central for a Peripheral device, on an ACL connection, with a very high Peripheral Latency, around 80.

Please see below and example of the nRF5340 not responding to a CIS event from the PIxel 10, and the Pixel 10 repeating the payload in both subevents of the CIS.

I noticed that the missed CIS events seem to happen immediately after an ACL event with the other device.

Is it possible tat the nRF5340 prioritizes the ACL over the CIS and that is why it is missing the CIS event?

Technically, it has enough time to figure out that the Peripheral did not answer and catch at least the retransmission from the second CIS subevent which is ~1.6 ms from the end of the ACL packet.

The clicks were not audible in the previous SDK we used, 3.1.1. Has the behavior changed since then?

If this is the cause of the missed CIS is it possible to configure the device to always prioritize the CIS over ACL (maybe with the exception of special situations like connection update instants)?

[Alex B]

Hi Amanda Hsieh .

I have implemented your suggestion to use continuous scanning, using the BT_LE_SCAN_PASSIVE_CONTINUOUS option and now the nRF5340 scans for the low latency Peripheral between CIS events. We nolonger hear gaps in the audio. Thanks for the suggestion!

I have also found that the connection interval was changed to 12.5 ms on the ACL by the nRF5340 because the Peripheral sent L2CAP_CONNECTION_PARAMETER_UPDATE_REQ to which the nRF5340 sent an affirmative response.
I solved this by assigning a function which always returns false to the .le_param_req connection structure member. In this way, the nRF5340 rejects any connection parameter updates requested by the Peripheral and keeps the interval a multiple of 10 ms and 7.5 ms.

A third mechanism I implemented to solve the audio issue was to disconnect the Peripheral whenever the Pixel 10 starts the audio stream on the CIS. I did this to force the nRF5340 and the low latency Peripheral to re-connect so the nRF5340 can choose a timing for the ACL which does not conflict with the CIS.

This mechanism mostly works. Most of the time the nRF5340 schedules the Peripheral ACL, on re-connection, in the middle of the interval between CIS events. And in this situation, the audio is fine. See the screenshot.

But other times it schedules the RC ACL very close before the CIS event. Initially this works fine, but suddenly the nRF5340 starts missing CIS events again from the Pixel 10.
Apparently, it starts missing CIS events after and ACL with the Peripheral where the Peripheral does not respond.
The Peripheral eventually responds but the nRF5340 keeps missing CIS events from the Pixel 10.
I suspect this is an Window Widening issue and the Window Widening is not reset correctly once the Peripheral responds.

Please ask the Controller team what they think about this.

See the following screenshots for this issue.

Initially no CIS events are missed:

But later all CIS events following the ACL with the Peripheral are missed.

The issue starts here where the nRF5340 does not send an ACL event to the Peripheral for some reason:

[Amanda Hsieh]

It doesn't seem like window widening is the cause here; it seems like this is still a scheduling conflict. Regarding the secondary ACL where the 5340 is the central, unfortunately, the application is unable to control the anchor point of the first connection event (whereby all other connection event timings are based off), and the controller does not take into account the CIS peripheral activity when setting up the secondary ACL. This aligns with what you are seeing, and if the initial connection anchor point lands in a good position after reconnection, it should remain conflict free (with the 90ms connection interval). But if not then scheduling conflicts will occur. Unfortunately, the controller does not support any mechanism that can mitigate this. If possible, you can try to keep disconnecting until the secondary ACL initial anchor point falls in a better location.

[Alex B]

Thanks for the quick reply, Amanda Hsieh .

My impression after doing a lot of tests is that the nRF5340 does take into consideration the timing of the ACL + CIS with the Pixel 10 (where it is acting as Peripheral) when setting the timing of the ACL with the other device (where it is acting as Central). I have not seen situations where the ACL with the other device was established right on top of the ACL or the CIS with the Pixel 10.

The issues I see are in a situation where the CIS event with the Pixel 10 is very close after the ACL with the Peripheral.

When initially established, the ACL with the Peripheral device did not cause any issues with the ACL + CIS with the Pixel 10. The issues started after a particular ACL event with the Peripheral, approximately 6 seconds after the connection is established. Up to that ACL event the nRF5340 responds to CIS events from the Pixel 10 if the ACL has only one PDU from each side. If the ACL exchange is longer, obviously the nRF5340 does not have enough time to handle the CIS. Immediately after that event the nRF5340 fails to respond to all CIS events from the Pixel 10 immediately following an ACL event with the Peripheral, irrespective of the ACL length with the Peripheral. It does not respond even if the Peirpheral sends no PDU during the ACL event and it has more than enough time to handle the CIS.

This is obviously a conflict between the Peripheral ACL and the CIS. But it starts manifesting itself some time after the ACL is established. This behavior starts immediately after an ACL event with the Peripheral where not even the nRF5340 sends an ACL packet. This is why I am suspecting Window Widening issues, based on my experience as a Controller developer.

Anyway, this is not reproducible every time and the ACL Peripheral must not be continuously connected. It can be connected later, only when it is needed.

We will think about the idea to disconnect and reconnect the Peripheral until it does not bother the CIS. But it's hard to figure out from the software when this happens. Maybe we can use the audio underrun warnings we get in the log when this issue starts manifesting itself.