receiver does not sync to audio after getting back in range

[JeraDrson]

Hello,

i am debugging issue in our device. I ported the nrf5340 Audio application to our custom board and modified it for our use. We use audio broadcast mode.

Device works but sometime the receiver does not re-connect after the transmitter out of range and back(or restarts).

Testing shows that this maybe is related to cold temperature and battery not fully charged. However the tests are not conclusive so this may not be true.

It seems that the device just stops receiving (audio and some custom application data packets). Application runs but the device has to be restarted to reenable the communication.

I managed to get some logs of the bug. Following lines are preset when it happens.

I do not know if it is the cause of the issue or just another consequence.

To you have any suggestions?

[JeraDrson]

Update:
I did more tests. Dependence on temperature and battery did not confirm.

I now think it is now related to the scenario where 

LE_AUDIO_EVT_SYNC_LOST is handled in main shortly before the Sync timeout showed in previous message.

My understanding is that in original application the sync timeout was disabled after the first successful sync. However i needed to add custom data advertisement so i commented out the bt_le_scan_stop(); from pa_synced_cb function so my data is passing through. This was in my previous ticket here BL Audio multicast

[Amanda Hsieh]

Hi, 

When a timeout happens (like we lost the gateway), 

1. The stream_stopped_cb() triggered, with reason "BT_HCI_ERR_CONN_TIMEOUT"
2. Sending "LE_AUDIO_EVT_SYNC_LOST" event
3. In streamctrl_broadcast_sink.c, we catch LE_AUDIO_EVT_SYNC_LOST and delete PA sync
4. Once if the PA sync terminated, the callback for PA sync terminated will be triggered, and BT_MGMT_PA_SYNC_LOST will be sent
   Which trigger the scanning automatically

According to this page, The error code -120 returned by this line typically corresponds to EALREADY which means the Operation is already in progress, but this line should already stop scanning before it. 

What NCS version are you using? Do you modify the scan_restart_worker function?

Regards,
Amanda H.

[JeraDrson]

Thank you for the reply.

I use 2.6.1.

My current theory is that I needed to add custom advertisment and did not want to stop scanning when pa_synced_cb happens. So I commented the bt_le_scan_stop out from it. However the timeout restart pa_sync_timer is still running. Therefore when the sync is lost the scanning restart may come from the mechanism you described or from the pa_sync_timeout and this may cause the problem.
Does this make sense?

I now tried to disable the timer (with pa_sync_timeout) entirely so the restart happens only after sync lost.

It did not get stuck so far but it is too soon to know yet. Hope this does not cause another issues.

with regards Jeronym

 

[JeraDrson]

Ok, so after testing the solution was not correct. It did solve the original issue however sound had glitches and range was worse so I had  to reenabled the scan restart by timeout.

So i am back at the beginning.

To summarize:

When LE_AUDIO_EVT_SYNC_LOST is handled in main short before pa_sync_timer expires, the scanning can not be reenabled again.

Compared to the original audio application there is one related change. I added custom advertisement. To be able to receive it I removed bt_le_scan_stop from pa_synced_cb.

[Amanda Hsieh]

Hi, 

Please try to use the latest NCS v2.9.0 to get the improvement. 

-Amanda H.