nRF5340 broadcast sink does not get BIG/PA loss callbacks when broadcast source reboots; only "Unhandled vendor-specific event 0x01"

[GlennEngel]

Hi,

I have a custom nRF5340-based LE Audio broadcast sink built on nRF Connect SDK v3.2.0 (Zephyr 4.2.x). It scans for a broadcast source, establishes PA sync, creates a BAP broadcast sink, syncs to a BIS, and receives audio normally.  No problems.

Problem:
If the broadcast source reboots while audio is streaming, the sink stops receiving audio and never reconnects automatically.

What I observe:
- Audio stops permanently after the source reboots.  Other threads continue.
- I often see this warning on the sink:
bt_hci_core: Unhandled vendor-specific event 0x01 len 37: 240000000162010000000000005d0100005801000021000000850c0201acb3000118000081
- The normal app-level teardown callbacks do not seem to fire in this case:
- bt_bap_broadcast_sink_cb.stopped
- bt_le_per_adv_sync_cb.term
- I also tried registering a low-level bt_iso_big_cb and did not see its stopped callback fire either

Current sink behavior:
- This build is using self-scan, not scan offload / Broadcast Assistant
- On source reboot, since no stop/term callback arrives, I eventually detect no more ISO data with an application timeout and force a reboot as a workaround

Expected behavior:
I would expect some supported callback/event path to indicate that the BIG or PA sync was lost so the sink can restart:
scan -> PA sync -> broadcast sink create -> BIG sync

Questions:
1. Is this vendor-specific event 0x01 expected from the Nordic controller when a broadcast BIG is lost because the source rebooted?
2. If so, what is the supported host/app callback that should be relied on in NCS for this condition?
3. Should bt_bap_broadcast_sink_cb.stopped and/or bt_le_per_adv_sync_cb.term normally fire on source reboot?
4. Is this a known issue on nRF5340/NCS 3.2.0 for LE Audio broadcast sink teardown when the source disappears abruptly?
5. Is there a recommended workaround or patch other than rebooting the sink application?

Additional detail:
- The source reboot is abrupt from the sink’s point of view
- The sink was previously receiving audio successfully
- The problem is not that scanning/re-sync logic is missing; the issue is that the expected loss/termination indication does not seem to surface to the application

Thanks.

[Maria Gilje]

Hello, 

With the default broadcast source and sink configurations for the Audio application, this issue is not reproducible. I know that you have modified your application, so I need to know some more details about what these modifications are to be able to diagnose this properly. 

Are you using a broadcast name as the match critera for the broadcast sink? If yes: Does the broadcast source have a set broadcast name which is consistent across boots? 

4. Is this a known issue on nRF5340/NCS 3.2.0 for LE Audio broadcast sink teardown when the source disappears abruptly?

This is not a known issue. Our implementation of the broadcast sink handles abrupt reboots of the broadcast source properly. 

When rebooting the broadcast source I get these logs on the broadcast sink: 

HL [00:02:11.224,304] <inf> broadcast_sink: Stream sync lost
HL [00:02:11.224,365] <inf> broadcast_sink: Stream index 0 stopped. Reason: 8
HL [00:02:11.225,372] <inf> main: Sync lost
HL [00:02:11.226,013] <inf> main: PA sync lost, reason: 22

Do you get any similar logs for your application when the broadcast source reboots? 

I'll adress your other questions when I know a bit more about your application and configuration. 

Best regards,

Maria

[GlennEngel]

Perhaps one significant item is that my broadcast source is doing a controlled reboot where it is going to sleep and waiting for a wakeup event so it's not a hard reset pin action.  Before going to sleep it makes a call to bt_bap_broadcast_source_stop

    err = bt_bap_broadcast_source_stop(broadcast_source);
	if (err != 0 && err != -EALREADY) {
		printk("Failed to stop broadcast source: %d\n", err);
		return err;
	}
	
	// snip - shut down other stuff
	
	LOG_PANIC();
	k_sleep(K_MSEC(120));
	sys_poweroff();

 

[Maria Gilje]

Hello,

I see. In that case it could be necessary to also perform more cleanup for the broadcast source before the device goes to sleep. For comparison, when stopping the broadcast in the BAP Broadcast Audio Source sample, the source is also deleted and periodic and extended advertising is stopped (and deleted). See the process from line 683 in bap_broadcast_source/src/main.c. 

Best regards,

Maria

[GlennEngel]

In testing I get the error on the receiver even if I just 'hard reset' the sender.  In any case the receiver shouldn't hang up so there is some issue there.  I'll try to replicate on the demo app next week to see what might be different in your testing vs my experience.