Decrease time to sync audio broadcast

[RakeLund]

We have a project with a device acting as a ble peripheral and a broadcast sink. First the ACL connection is set up and then it will scan for and sync to a broadcast with a configured name. 

In the current prototype the time from starting to scan for broadcast and until the audio stream is synced and ready is typically 10-20seconds, with getting the BASE and BIG sync taking the longest. Is this expected with LE Audio broadcast or should it be possible to significantly reduce this delay?

Here are some logs that shows the timing (in ms):

[15552::INFO] (broadcast_sink.cpp:1116) Scanning for broadcaster XXX
[15634::INFO] (broadcast_sink.cpp:428) Found broadcaster with ID 0x199823 and addr 02:97:3C:BC:C5:EF (
[15804::INFO] (broadcast_sink.cpp:428) Found broadcaster with ID 0x199823 and addr 02:97:3C:BC:C5:EF (
[15976::INFO] (broadcast_sink.cpp:428) Found broadcaster with ID 0x199823 and addr 02:97:3C:BC:C5:EF (
[16234::INFO] (broadcast_sink.cpp:428) Found broadcaster with ID 0x199823 and addr 02:97:3C:BC:C5:EF (
[16404::INFO] (broadcast_sink.cpp:428) Found broadcaster with ID 0x199823 and addr 02:97:3C:BC:C5:EF (
[16553::INFO] (broadcast_sink.cpp:999) Attempting to PA sync to the broadcaster with id 0x199823
[16554::INFO] (broadcast_sink.cpp:1006) Waiting for PA sync to complete
[16564::INFO] (broadcast_sink.cpp:428) Found broadcaster with ID 0x199823 and addr 02:97:3C:BC:C5:EF (
[17424::INFO] (broadcast_sink.cpp:428) Found broadcaster with ID 0x199823 and addr 02:97:3C:BC:C5:EF (
[17744::INFO] (broadcast_sink.cpp:473) PA sync 0x2000dbd8 synced for broadcast sink with broadcast ID 
[17744::INFO] (broadcast_sink.cpp:1013) Broadcast source PA synced, creating Broadcast Sink
[17745::INFO] (broadcast_sink.cpp:1020) Broadcast Sink created, waiting for BASE
[24944::INFO] (broadcast_sink.cpp:785) Received BASE with 1 subgroups from broadcast sink 0x2000e228
[24944::INFO] (broadcast_sink.cpp:791) Subgroup: 0 BIS: 0 index = 1
[24944::INFO] (broadcast_sink.cpp:621) Octets per frame: 40
[24944::INFO] (broadcast_sink.cpp:766) Codec info: id: 0x06, cid: 0x0000, vid: 0x0000, frequency: 2400
[24944::INFO] (broadcast_sink.cpp:830) Received SYNCABLE from broadcast sink 0x2000e228: unencrypted
[24944::INFO] (broadcast_sink.cpp:1027) BASE received, waiting for syncable 
[24944::INFO] (broadcast_sink.cpp:1034) Waiting for broadcast code
[24945::INFO] (broadcast_sink.cpp:1041) Waiting for BIS sync request
[24945::INFO] (broadcast_sink.cpp:1048) Syncing to broadcast
[00:00:24.945,129] <dbg> bt_bap_broadcast_sink: broadcast_sink_ep_init: ep 0x2000e338
[00:00:24.945,159] <dbg> bt_bap_iso: bt_bap_iso_bind_ep: iso 0x2000e100 ep 0x2000e338 dir sink
[00:00:24.945,556] <dbg> bt_bap_broadcast_sink: broadcast_sink_set_ep_state: ep 0x2000e338 id 0x00 idle -> qos-configured
[24945::INFO] (broadcast_sink.cpp:1055) Waiting for BIG sync
[32144::INFO] (broadcast_sink.cpp:785) Received BASE with 1 subgroups from broadcast sink 0x2000e228
[32144::INFO] (broadcast_sink.cpp:791) Subgroup: 0 BIS: 0 index = 1
[32144::INFO] (broadcast_sink.cpp:621) Octets per frame: 40
[32144::INFO] (broadcast_sink.cpp:766) Codec info: id: 0x06, cid: 0x0000, vid: 0x0000, frequency: 2400
[00:00:32.150,909] <dbg> bt_bap_broadcast_sink: broadcast_sink_iso_connected: stream 0x2000ca34
[00:00:32.150,909] <dbg> bt_bap_broadcast_sink: broadcast_sink_set_ep_state: ep 0x2000e338 id 0x00 qos-configured -> streaming
[32150::INFO] (broadcast_sink.cpp:339) Stream 0x2000ca34 started

Both sides (broadcast sink and broadcast source) is nrf5340 and running nrf Connect v2.6.0, so we're also wondering if there has been changes to the audio implementation lately that might be beneficial for this issue?

[Maria Gilje]

Hello,

From the release notes for the versions from nRF Connect SDK v2.6.0 to v2.9.0 I did not find any specific points which addressed sync time. I would like to do a quick test though to see if v2.9.0 is quicker. It looks like you are running the BAP Broadcast source and sink samples?

That being said, I think you should be able to adjust some settings to make the sync quicker, but I'm not 100% sure here. I will check this in parallel with running the samples.

Best regards,

Maria

[Maria Gilje]

I have tested with nRF Connect SDK v2.9.0 now and the sync seems to be quicker than 20 seconds. See the log below.

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
[00:00:00.290,008] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.290,039] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.290,069] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 3.7 Build 99
[00:00:00.292,236] <inf> bt_hci_core: Identity: D1:D9:6F:57:FD:47 (random)
[00:00:00.292,266] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x0000, manufacturer 0x0059
[00:00:00.292,297] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0xffff
Bluetooth initialized
[00:00:00.292,358] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,358] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,358] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,388] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,388] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,419] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,419] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,419] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,449] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,449] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,449] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,449] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,480] <wrn> usb_nrfx: invalid endpoint type
[00:00:00.292,480] <wrn> usb_nrfx: invalid endpoint type
Reset
Starting advertising
Waiting for Broadcast Assistant
[00:00:00.534,240] <wrn> usb_device: Endpoint 0x88 already disabled
[00:00:00.534,423] <wrn> usb_device: Endpoint 0x08 already disabled
[00:00:00.540,863] <wrn> usb_device: Endpoint 0x88 already disabled
[00:00:00.541,076] <wrn> usb_device: Endpoint 0x08 already disabled
No Broadcast Assistant connected
Scanning for broadcast sources
Waiting for Broadcaster
Found broadcaster with ID 0xDD7889 and addr 33:93:8D:E2:71:F9 (random) and sid 0x00
broadcaster_broadcast_id = 0xDD7889
Attempting to PA sync to the broadcaster with id 0xDD7889
Waiting for PA synced
PA sync 0x200087a0 synced for broadcast sink with broadcast ID 0xDD7889
Broadcast source PA synced, creating Broadcast Sink
Receive state updated, pa sync state: 2
Broadcast Sink created, waiting for BASE
[00:00:11.960,449] <dbg> bt_bap_broadcast_sink: pa_decode_base: Updating BASE for sink 0x20008d00 with 1 subgroups

Receive state updated, pa sync state: 2
subgroup 0 bis_sync: 0x00000000
Received BASE with 1 subgroups from broadcast sink 0x20008d00
bis_index_bitfield = 0x00000002
Broadcast sink (0x20008d00) is syncable, BIG not encrypted
BASE received, waiting for syncable
Waiting for broadcast code
Waiting for BIS sync request
Syncing to broadcast with bitfield: 0x00000002 = 0x00000002 (bis_index) & 0xffffffff (req_bis_sync), stream_count = 1
[00:00:11.961,181] <dbg> bt_bap_broadcast_sink: broadcast_sink_ep_init: ep 0x20008da4
[00:00:11.961,303] <dbg> bt_bap_iso: bt_bap_iso_bind_ep: iso 0x20008b64 ep 0x20008da4 dir sink
[00:00:11.961,364] <dbg> bt_iso: bt_iso_chan_add: iso 0x200067a8 chan 0x20008b64
[00:00:11.961,791] <dbg> bt_iso: bt_iso_chan_set_state_debug: chan 0x20008b64 iso 0x200067a8 disconnected -> connecting
[00:00:11.961,853] <dbg> bt_bap_broadcast_sink: broadcast_sink_set_ep_state: ep 0x20008da4 id 0x00 idle -> qos-configured
Waiting for stream(s) started
Receive state updated, pa sync state: 2
subgroup 0 bis_sync: 0x00000002
[00:00:13.173,034] <dbg> bt_iso: hci_le_big_sync_established: BIG[0] 0x20008b14 sync established, status 0x00 
[00:00:13.173,034] <dbg> bt_iso: bt_iso_connected: 0x200067a8
[00:00:13.173,492] <dbg> bt_iso: bt_iso_chan_set_state_debug: chan 0x20008b64 iso 0x200067a8 connecting -> connected
[00:00:13.173,522] <dbg> bt_bap_broadcast_sink: broadcast_sink_iso_connected: stream 0x20000fb8
Stream 0x20000fb8 connected
[00:00:13.173,583] <dbg> bt_bap_broadcast_sink: broadcast_sink_set_ep_state: ep 0x20008da4 id 0x00 qos-configured -> streaming
Stream 0x20000fb8 started
Enable: stream with codec 0x20008d64
Enabling LC3 decoder with frame duration 10000us, frequency 16000Hz and with channel allocation 0x00000002, 40 octets per frame and 1 frame blocks per SDU
Waiting for PA disconnected
Stream 0x20000fb8: received 1000 total ISO packets: Valid 1000 | Error 0 | Loss 0

Is this a good enough reason for you to upgrade to nRF Connect SDK v2.9.0 or should I find more tangible indicators for improvements in nRF Connect SDK?

One I can think of off the top of my head is that the ISO features for the SoftDevice Controller has improved since nRF Connect SDK v2.6.0, since that was the first version where the controller supported ISO at all.

Best regards,

Maria

[Maria Gilje]

Hi again,

I got some feedback this morning.

In nRF Connect SDK v2.9.0 we have the CONFIG_BT_AUDIO_SCAN_DELEGATOR option, which will make the sink device act as a peripheral to a broadcast assistant. Here is a log from the nRF5340 Audio application headset device with some explaining comments along the way:

          nRF5340 Audio nRF5340 Audio DK cpuapp
         NCS base version: 2.9.0
         Cmake run : Thu Mar 27 15:45:07 2025
HL [00:00:00.308,746] <inf> fw_info: ------- DEBUG BUILD -------
HL [00:00:00.308,746] <inf> fw_info: HEADSET left device
HL [00:00:00.378,875] <inf> bt_mgmt_ctlr_cfg: Controller: SoftDevice: Version 6.0 (0x0e), Revision 8299
HL [00:00:00.379,089] <inf> bt_mgmt: Local identity addr: CC:CF:B2:BE:15:80 (random)
HL [00:00:00.408,111] <wrn> broadcast_sink: CSIP using the default SIRK, must be changed before production
HL [00:00:00.409,118] <dbg> broadcast_sink: broadcast_sink_enable: Broadcast sink enabled
HL [00:00:00.410,461] <inf> bt_mgmt_adv: Local addr: CC:CF:B2:BE:15:80 (random)
HL [00:00:00.410,949] <inf> bt_mgmt_adv: Advertising successfully started

// The time when BIS headset connected by a phone with broadcast assistant feature
HL [00:01:20.222,503] <inf> bt_mgmt: Connected: 78:CE:74:BD:D4:CC (random)

// The time when broadcast assistant from phone tell the BIS headset to sync with nearby nRF5340 broadcaster 
HL [00:01:26.646,942] <inf> bt_mgmt_scan: broadcast ID received = 534BD0
HL [00:01:26.858,306] <inf> bt_mgmt_scan: PA synced to name: , id: 0x534bd0, addr: 1D:78:B6:CF:B5:43 (random)
HL [00:01:26.858,764] <dbg> broadcast_sink: broadcast_sink_pa_sync_set: Trying to set PA sync with ID: 5458896
HL [00:01:27.458,190] <dbg> broadcast_sink: base_recv_cb: Received BASE with 1 subgroup(s) from broadcast sink
HL [00:01:27.458,221] <dbg> broadcast_sink: base_subgroup_cb: Subgroup 0x2001f8e7 has 2 BISes
HL [00:01:27.458,282] <dbg> broadcast_sink: base_subgroup_bis_cb: BIS found, index 1
HL [00:01:27.458,282] <dbg> broadcast_sink: get_codec_info: Failed retrieving sampling frequency: -61
HL [00:01:27.458,282] <dbg> broadcast_sink: get_codec_info: Failed retrieving frame duration: -61
HL [00:01:27.458,312] <dbg> broadcast_sink: get_codec_info: Failed retrieving octets per frame: -61
HL [00:01:27.458,312] <dbg> broadcast_sink: get_codec_info: Failed calculating bitrate: -61
HL [00:01:27.458,343] <dbg> broadcast_sink: base_subgroup_bis_cb: Channel allocation: 0x1 for BIS index 1
HL [00:01:27.458,343] <dbg> broadcast_sink: base_subgroup_bis_cb: BIS found, index 2
HL [00:01:27.458,343] <dbg> broadcast_sink: get_codec_info: Failed retrieving sampling frequency: -61
HL [00:01:27.458,374] <dbg> broadcast_sink: get_codec_info: Failed retrieving frame duration: -61
HL [00:01:27.458,374] <dbg> broadcast_sink: get_codec_info: Failed retrieving octets per frame: -61
HL [00:01:27.458,374] <dbg> broadcast_sink: get_codec_info: Failed calculating bitrate: -61
HL [00:01:27.458,404] <dbg> broadcast_sink: base_subgroup_bis_cb: Channel allocation: 0x2 for BIS index 2
HL [00:01:27.458,465] <dbg> broadcast_sink: base_recv_cb: Channel HL active
HL [00:01:27.458,465] <dbg> broadcast_sink: base_recv_cb: Waiting for syncable
HL [00:01:27.458,557] <dbg> broadcast_sink: syncable_cb: Broadcast sink is syncable
HL [00:01:27.458,587] <inf> broadcast_sink: Syncing to broadcast stream index 0
HL [00:01:27.458,801] <inf> main: Presentation delay 3000 us is set

# It only took couple seconds to start the stream
HL [00:01:28.062,957] <inf> broadcast_sink: Stream index 0 started
HL [00:01:28.062,988] <inf> broadcast_sink: Codec config for LC3:
HL [00:01:28.062,988] <inf> broadcast_sink:     Frequency: 48000 Hz
HL [00:01:28.062,988] <inf> broadcast_sink:     Frame Duration: 10000 us
HL [00:01:28.062,988] <inf> broadcast_sink:     Octets per frame: 120 (96000 kbps)
HL [00:01:28.062,988] <inf> broadcast_sink:     Frames per SDU: 1
HL [00:01:28.062,988] <inf> broadcast_sink:     Channel allocation: 0x1
HL [00:01:28.063,964] <wrn> le_audio_rx: Not in streaming state (1), thrown 1 packet(s)
HL [00:01:28.083,068] <inf> audio_datapath: Drft comp state: CALIB
HL [00:01:28.084,045] <wrn> audio_datapath: Data received, total under-runs: 9
HL [00:01:28.183,074] <inf> audio_datapath: Drft comp state: OFFSET
HL [00:01:28.283,081] <inf> audio_datapath: Drft comp state: LOCKED
HL [00:01:28.292,755] <inf> audio_datapath: Pres comp state: MEAS
HL [00:01:28.402,740] <inf> audio_datapath: Pres comp state: WAIT
HL [00:01:28.542,724] <inf> audio_datapath: Pres comp state: INIT
HL [00:01:28.552,734] <inf> audio_datapath: Pres comp state: MEAS
HL [00:01:28.662,750] <inf> audio_datapath: Pres comp state: LOCKED

As you can see from the logs it takes a few seconds to start the stream after the Broadcast Assistant has set up which stream the headset should sync to. So it should be very possible to reduce the time from your case, especially when upgrading to nRF Connect SDK v2.9.0 or v2.9.1 to make use of the CONFIG_BT_AUDIO_SCAN_DELEGATOR feature.

Best regards,

Maria

[RakeLund]

I've been trying to upgrade to nRF Connect SDK v2.9.1, but having trouble getting it to work. I've finally managed to build, but when the application calls bt_enable I get an error return -12 (ENOMEM) so I assume I've done something wrong with the configuration of the network core. I copied the sysbuild folder and kconfig.sysbuild from nrf5340 audio application because I assume that should choose the correct controller?

Any ideas of what could be wrong?

[RakeLund]

I figured this out myself. After migrating to hardware model 2 for our board some configurations were missing because of wrong boardnaming in the file. Specifically the Kconfig.defconfig and Kconfig files needed to be updated

[Maria Gilje]

RakeLund said:

I figured this out myself. After migrating to hardware model 2 for our board some configurations were missing because of wrong boardnaming in the file. Specifically the Kconfig.defconfig and Kconfig files needed to be updated

Great that you were able to solve this and thank you for sharing your solution!

Best regards,

Maria

[RakeLund]

Everything seems to work now after upgrading to 2.9.1 (except our ADC, but that's not related to bluetooth in any way). The delay did not seem to change, but I could test the Scan Delegator feature. For this to work you will have to have a seperate device acting as a broadcast assistant?

In the logs above: The time from connecting to the phone telling the BIS headset to sync, is that due to waiting for a user interaction or is it a time the phone uses to process information first? What exactly does the scan delegator do that makes the process quicker? 

[Maria Gilje]

RakeLund said:

For this to work you will have to have a seperate device acting as a broadcast assistant?

Yes, that's correct. This can be a phone or a dedicated broadcast assistant device.

RakeLund said:

The time from connecting to the phone telling the BIS headset to sync, is that due to waiting for a user interaction or is it a time the phone uses to process information first?

That is user interaction. After connecting the broadcast assistant to the headset, the user can select which broadcast stream the headset should sync to.

RakeLund said:

What exactly does the scan delegator do that makes the process quicker? 

The scan delegator feature allows the headset to offload the scanning to the broadcast assistant. The speed will depend on how the assistant functions.

I failed to mention before, that the reason for pointing you to the scan delegator feature is that it demonstrates a similar scenario to yours where the headset acts as a peripheral as well as a broadcast sink. Having the headset perform the scanning is still an option.

Best regards,

Maria