[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, 

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

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

Regards,
Amanda H.

[Alex B]

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.

[Alex B]

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?

[Alex B]

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:

And here:

[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.