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

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

Alex B — Wed, 29 Apr 2026 12:41:13 GMT

Amanda Hsieh I did some more tests in the last few days and I found out you were right about the scheduling.

Unfortunately, I stumbled again on a situation where the audio has clicks.

And I could confirm by looking at the over-the-air traces that the RC ACL was scheduled right on top of the CIS.

The Peripheral does high duty cycle directed advertising and the nRF5340 connects to it while the CIS+ACL with the Phone are being handled.

The Peripheral ACL has an interval of 90 ms and causes the CIS with the Pixel 10 to be dropped (10 ms ISO interval).

And sometimes both the CIS and ACL with the Pixel 10 are dropped. The ACL with the Pixel 10 has a connection interval of 20 ms.

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

Alex B — Fri, 24 Apr 2026 13:38:08 GMT

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.

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

Amanda Hsieh — Fri, 24 Apr 2026 12:28:47 GMT

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.

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

Alex B — Wed, 22 Apr 2026 13:32:44 GMT

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:

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

Alex B — Tue, 14 Apr 2026 21:16:36 GMT

Thanks for these new details, Amanda Hsieh.

I will play with the CONFIG_BT_AUDIO_MAX_TRANSPORT_LATENCY_MS setting, which directy impacts the chosen Flush Timeout, to try to make the audio more resilient to occasional missed CIS events.

I'll see what I can do about the ACL where the nRF5340 is Central.

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

Amanda Hsieh — Thu, 09 Apr 2026 12:26:29 GMT

Hi Alex,

The peripheral can request the Connection update procedure, but it is only the central which will update the connection parameters. The controller only executes this procedure when initiated by the host. The SoftDevice Controller does not support the Connection Parameter Request procedure. So the customer will be unable to suggest specific anchor point offsets as a peripheral through bt_conn_le_param_update().

If the CIS conflicts with the ACL connection with the pixel 10 phone, then as a mitigation it should be possible to increase the Flush Timeout, which will prevent the central from flushing the SDU and allow it to retransmit the SDU in the next ISO interval. However, this does come at the cost of increased transport latency. The Flush timeout is controlled by the central. At the application level this is often referred to as Retransmission Number (RTN).

On the secondary low bandwidth ACL, where nRF5340 is the central, scheduling conflicts will occur and so setting the connection interval to a multiple of 7.5 ms and 10 ms is reasonable to try to minimize these conflicts.

-Amanda H.

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

Alex B — Wed, 08 Apr 2026 14:01:26 GMT

Thanks for the clarifications, Amanda Hsieh !

I will implement the continuous scan suggestion you made next week. This will surely solve some of the audio issues we have (gaps in audio when the device is scanning).

Also, thanks for the link about the priorities. This clarifies some behaviours.

You said the Central always does a Connection Update. Is this coming from the Controller or the Host? I have not dug into the Host yet. But, off the top of my head, I remember that the Controller is allowed to independently start a Connection Update.

I don't think increasing the Supervision Timeout or decreasing the Peripheral Latency will solve the second audio issue (clicks in audio when the device misses CIS events). In my opinion, the only way to solve this is to make sure the ACL events fall between the CIS events. This can be done by controlling the timing (Offset) and the Interval of the ACL.This is kind of hard to do because we are acting as a Peripheral for the ACL connection. One way we could do this form the Peripheral is by using the LL_CONNECTION_PARAM_REQ PDU, which can be sent during a Connection Update procedure started form the Peripheral. Is there way to make the nRF5340 Controller send a LL_CONNECTION_PARAM_REQ PDU which suggests some good offsets to the Central (see Offset0 to Offset5 in the PDU CtrData field)? Will the bt_conn_le_param_update() function do this?

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

Amanda Hsieh — Wed, 08 Apr 2026 13:01:51 GMT

Hi Alex,

Your suggestion of making the ACL interval a multiple of 7.5 ms and 10 ms to avoid overlaps sounds reasonable. The new scheduler was introduced in SDK 3.2.1, but it does not seem to be the cause of the issue. Unfortunately, while ~1.6 ms is enough to catch the second subevent, the controller schedules all subevents at once. So either we will be able to receive all subevents or none.

You should be able to scan between events by setting the scan window equal to the scan interval, BT_LE_SCAN_ACTIVE_CONTINUOUS can be used for convenience, as in this configuration, the scanner should have lower priority than the ACL and CIS. Lastly, the parameters set in the CONNECT_IND apply at the start of the connection. After a Connection Update procedure, the parameters in the LL_CONNECTION_UPDATE_IND will take precedence. The LL_CONNECTION_UPDATE_IND is always issued by the central, but the peripheral may request an update of the parameters. The ACL and CIS should run at equal priority, unless the connection is close to timing out. This is the case when the central connection interval is 12.5 ms, the supervision timeout is 4s, and the peripheral latency is 79. Therefore, I think that either the connSupervisionTimeout should be increased or the peripheral latency should be lowered. Your questions seem to focus on scheduling priorities so you may find https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/softdevice_controller/doc/scheduling.html useful.

-Amanda H.

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

Alex B — Tue, 31 Mar 2026 21:44:45 GMT

I have also seen another issue in my experiments.
I have started setting Connection_Interval_Min to 60 ms (48 * 1.25 ms) and Connection_Interval_Max to 90 ms (72 * 1.25 ms) for the low bandwidth ACL on which the nRF5340 is Central.
It starts with a Connection Interval of 90 ms (CONNECT_IND):

But then it switches the interval to 12.5 ms (LL_CONNECTION_UPDATE_IND):

According to the specification the Connection_Interval_Min to and the Connection_Interval_Max values from the _CONNECT_IND PDUs are mandatory.

Here:

And here:

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

Alex B — Tue, 31 Mar 2026 21:21:52 GMT

I have done more experiments on my side.

I have disabled the Peripheral device with which the nRF3540 only has a low bandwidth ACL.

In the following screenshots, only the ACL and CIS with the Pixel 10 Phone are active.

Now I hear gaps in the audio and I see gaps in nRF5340 responses in the sniffer capture on both the ACL and the CIS with the Pixel 10.

The sniffer capture shows that the nRF5340 periodically does not answer the for 3 CIS events and 1 ACL event.

Zoom in on one of the gaps:

What I am suspecting that the gaps in ACL and CIS events responses are caused by the nRF5340 scanning for the missing peer.

Can you confirm this. Is there any way to make it scan between CIS and ACL events?

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

Alex B — Fri, 27 Mar 2026 13:41:35 GMT

Thanks Amanda Hsieh .

I am mainly interested to know if that secondary, lower importance ACL may be prioritized over the CIS and that is the reason the nRF5340 does not respond.

Meanwhile, as a mitigation for this I am considering making the ACL interval a multiple of 7.5 ms and 10 ms to avoid overlaps completely with Audio (CIS in this case) since these are the 2 most common used ISO Intervals by the Audio profiles. We control the connection interval and the scheduling because the nRF5340 is the Central on the secondary ACL.

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

Amanda Hsieh — Fri, 27 Mar 2026 13:11:24 GMT

Hi,

[quote user=""]The clicks were not audible in the previous SDK we used, 3.1.1. Has the behavior changed since then?[/quote]

I am checking with the team. I will update the case once I collect enough information.

Regards,
Amanda H.