Decrease time to sync audio broadcast

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?

  • 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

  • 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

  • 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? 

  • 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

Related