[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)?

[Amanda Hsieh]

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.

[Alex B]

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?

[Amanda Hsieh]

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.

[Alex B]

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.