Decrease time to sync audio broadcast

RE: Decrease time to sync audio broadcast

Maria Gilje — Fri, 04 Apr 2025 09:01:52 GMT

[quote user="RakeLund"] For this to work you will have to have a seperate device acting as a broadcast assistant?[/quote]

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

[quote user="RakeLund"]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?[/quote]

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

[quote user="RakeLund"]What exactly does the scan delegator do that makes the process quicker? [/quote]

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

RE: Decrease time to sync audio broadcast

RakeLund — Fri, 04 Apr 2025 08:35:10 GMT

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?

RE: Decrease time to sync audio broadcast

Maria Gilje — Thu, 03 Apr 2025 10:56:27 GMT

[quote user="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[/quote]

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

Best regards,

Maria

RE: Decrease time to sync audio broadcast

RakeLund — Wed, 02 Apr 2025 08:19:52 GMT

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

RE: Decrease time to sync audio broadcast

RakeLund — Tue, 01 Apr 2025 07:18:30 GMT

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?

RE: Decrease time to sync audio broadcast

Maria Gilje — Thu, 27 Mar 2025 10:00:57 GMT

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

RE: Decrease time to sync audio broadcast

Maria Gilje — Wed, 26 Mar 2025 15:18:08 GMT

Hello,

Thank you for sharing your configuration file. I have shared it internally and I'll update you when I get some feedback.

When looking through myself I found that CONFIG_BT_CTLR_DATA_LENGTH_MAX exceeds the upper limit of 251. I don't think this will affect the sync time, but it is outside the range for the symbol.

Is it your intention to have your device act as a Broadcast Assistant and a Broadcast Sink? This configuration seems unusual, because a Broadcast Snk is able scan for Broadcast sources and the point of having a Broadcast Assistant is to have a separate device from the Broadcast Sink to offload the scanning to to concerve power.

Best regards,

Maria

RE: Decrease time to sync audio broadcast

RakeLund — Tue, 25 Mar 2025 07:50:30 GMT

Here's our prj.conf I just removed a few names and ids

# Debugging and Optimization
CONFIG_DEBUG=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_DEBUG_THREAD_INFO=y

# C++ Support
CONFIG_CPP=y
CONFIG_STD_CPP17=y
CONFIG_GLIBCXX_LIBCPP=y

# Logging
CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=n
CONFIG_LOG_MODE_DEFERRED=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BUFFER_SIZE=2048
CONFIG_STDOUT_CONSOLE=y

# Bluetooth Settings
CONFIG_BT=y
CONFIG_BT_HCI=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_PRIVACY=n
CONFIG_BT_DEVICE_NAME="XXXX"
CONFIG_BT_EXT_ADV=y
CONFIG_BT_GATT_DYNAMIC_DB=y
CONFIG_BT_OBSERVER=y
CONFIG_BT_SCAN=y
CONFIG_BT_PER_ADV_SYNC=y
CONFIG_BT_HCI_VS_EXT=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=n
CONFIG_BT_MAX_CONN=2
CONFIG_BT_SCAN_WITH_IDENTITY=y
CONFIG_BT_PER_ADV=y
CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_ATT_PREPARE_COUNT=2
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_BUF_ACL_TX_COUNT=10
CONFIG_BT_BUF_ACL_TX_SIZE=502
CONFIG_BT_CTLR_DATA_LENGTH_MAX=1004
CONFIG_BT_BAP_BROADCAST_SINK_LOG_LEVEL_DBG=y
CONFIG_BT_BAP_ISO_LOG_LEVEL_DBG=y
CONFIG_BT_SMP=y
CONFIG_BT_AUDIO=y
CONFIG_BT_BAP_BROADCAST_SINK=y
CONFIG_BT_BAP_SCAN_DELEGATOR=y
CONFIG_BT_PAC_SNK=y
CONFIG_BT_BAP_BROADCAST_ASSISTANT=y
CONFIG_BT_BAS=y
CONFIG_BT_DIS=y
CONFIG_BT_DIS_HW_REV_STR="XXX"
CONFIG_BT_DIS_PNP=n
CONFIG_BT_DIS_SERIAL_NUMBER=n
CONFIG_BT_DIS_FW_REV=y
CONFIG_BT_DIS_HW_REV=y
CONFIG_BT_SETTINGS=y
CONFIG_SETTINGS_RUNTIME=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NONE=y
CONFIG_BT_DIS_SETTINGS=y
CONFIG_BT_DIS_STR_MAX=21
CONFIG_BT_PER_ADV_SYNC_MAX=2
CONFIG_BT_BAP_BROADCAST_SNK_SUBGROUP_COUNT=2
CONFIG_BT_BAP_BROADCAST_SNK_STREAM_COUNT=2
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=32
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=32

# Audio and Codec
CONFIG_LIBLC3=y
CONFIG_SW_CODEC_LC3_T2_SOFTWARE=y

# Stack and Threading
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_TIMESLICING=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2304

# UART and Console
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y
CONFIG_UART_ASYNC_API=n
CONFIG_UART_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y

# USB Device
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="XXXX"
CONFIG_USB_DEVICE_PID=0xXXXX
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n

# Flash and Bootloader
CONFIG_FLASH=y
CONFIG_BOOTLOADER_MCUBOOT=y

# MCU Manager
CONFIG_MCUMGR=y
CONFIG_MCUMGR_GRP_IMG=y
CONFIG_MCUMGR_GRP_OS=y
CONFIG_MCUMGR_TRANSPORT_BT=y
CONFIG_MCUMGR_TRANSPORT_BT_AUTHEN=n
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

# Peripheral Drivers
CONFIG_NRFX_I2S0=y
CONFIG_DATA_FIFO=y
CONFIG_I2C=y
CONFIG_ADC=y
CONFIG_ADC_NRFX_SAADC=y
CONFIG_NRFX_SAADC=y
CONFIG_SAMPLE_RATE_CONVERTER=y
CONFIG_SAMPLE_RATE_CONVERTER_FILTER_SIMPLE=y

# Floating Point Unit
CONFIG_FPU=y
CONFIG_FP_HARDABI=y

# Power Management
CONFIG_POWEROFF=y

# Board and RPMsg
CONFIG_BOARD_ENABLE_CPUNET=y
CONFIG_NCS_INCLUDE_RPMSG_CHILD_IMAGE=y

# RTT Console
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

RE: Decrease time to sync audio broadcast

Maria Gilje — Fri, 21 Mar 2025 14:14:46 GMT

Hello,

[quote user="RakeLund"]I was able to build and run the samples in the end, but the broadcast sink is failing when I try to sync to our broadcast source, maybe because we only have 1 stream/1 channel while it's expecting 2?[/quote]

Maybe. A Kconfig symbol for selecting BIS channels was introduced to the sample after v2.6.0, so this may cause the sync to fail with your custom broadcaster. The broadcast sink (from v2.9.0) will print "Failed to find a valid BIS" in that case. The default should be that it expects the left channel (CONFIG_TARGET_BROADCAST_CHANNEL=1), but setting CONFIG_TARGET_BROADCAST_CHANNEL to 0 or 2 instead will make it expect mono or the right channel respectively.

[quote user="RakeLund"]I will compare the sample to our application to see if there any obvious differences. Do you have any other pointers as to what to look for? Or some debug logs I could add with configurations in prj.conf? [/quote]

Would you be willing to share your prj.conf file so our developers can take a look. They would know if some configurations could cause increased sync times.

Best regards,

Maria

RE: Decrease time to sync audio broadcast

RakeLund — Tue, 18 Mar 2025 13:45:15 GMT

I was able to build and run the samples in the end, but the broadcast sink is failing when I try to sync to our broadcast source, maybe because we only have 1 stream/1 channel while it's expecting 2?

Then I tried running 2 nrf5340DK one with the broadcast sink sample and one with the broadcast source sample, both with nrf connect sdk 2.6.0 and it's a lot quicker than our application (2~3seconds while ours is 10-20seconds). So I doubt an upgrade of sdk will fix the issue alone.
I will compare the sample to our application to see if there any obvious differences. Do you have any other pointers as to what to look for? Or some debug logs I could add with configurations in prj.conf?

RE: Decrease time to sync audio broadcast

Maria Gilje — Mon, 10 Mar 2025 14:57:28 GMT

[quote user="RakeLund"] I tried running the broadcast sink sample v2.6.0 to check if the sample itself would behave differently than 2.9.0, but both on a nrf5340 audio dk and normal nrf5340 dk it failed to start advertising/scanning with an I/O error, not sure what is wrong. [/quote]

This could be because of the introduction of sysbuild (from v2.7.0). Include --sysbuild to the west build command or check the "Use sysbuild" option with the nRF Connect for VS Code extension.

[quote user="RakeLund"]I also tried running the nrf5340 audio application on my nrf5340 audio dk just to compare and even with 2.6.0 the syncing to a broadcast is very quick (~1 second) so I think the real issue is related to the fact that we're also keeping an ACL connection at the same time. I will do some more investigations.[/quote]

Let me know if I there is anything I can help with!

Best regards,

Maria

RE: Decrease time to sync audio broadcast

RakeLund — Mon, 10 Mar 2025 13:01:09 GMT

Thank you for running this test, it at least shows it should be possible to get the delay down. I tried running the broadcast sink sample v2.6.0 to check if the sample itself would behave differently than 2.9.0, but both on a nrf5340 audio dk and normal nrf5340 dk it failed to start advertising/scanning with an I/O error, not sure what is wrong.

I also tried running the nrf5340 audio application on my nrf5340 audio dk just to compare and even with 2.6.0 the syncing to a broadcast is very quick (~1 second) so I think the real issue is related to the fact that we're also keeping an ACL connection at the same time. I will do some more investigations.

RE: Decrease time to sync audio broadcast

Maria Gilje — Fri, 07 Mar 2025 16:11:14 GMT

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

RE: Decrease time to sync audio broadcast

Maria Gilje — Thu, 06 Mar 2025 15:54:19 GMT

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