LE audio: Simultaneous Broadcast Sink and Broadcast Source

[droid]

Hello,

Is it possible to configure an nRF5340 to be both a Broadcast Sink and a Broadcast Source, but with the condition that only frames received by the Broadcast Sink are sent ("relayed") to the Broadcast Source?

So long as the data stream is compressed, there should be sufficient bandwidth, but can the SD Controller support this configuration?

A simple test with NCS 3.2.0 and SD Controller received and sent data, however the received stream was unstable (100ms or so gaps in data received from Controller after some minutes followed by bursts of invalid frames).

Thank you,

Carl

[Maria Gilje]

Hi Carl, 

It is possible for the SoftDecive Controller to support both a broadcaster and a receiver role, but I'm not quite sure if it is feasible to do so simultaneously. Could you please explain a bit more about your usecase? Is it necessary for the device to have the roles simultaneously or could it switch between them? Would it be an option for it to be a broadcast source and a unicast server? 

Best regards,

Maria

[droid]

Hello Maria,

The use case is an important one: Range Extension. The Broadcast Receiver can use the co-located Broadcast Source to re-transmit ("relay") received audio to other Broadcast Sinks, which may be located farther away from the original Broadcast Source. This procedure can be repeated multiple times, and/or with multiple Broadcast Sinks at each stage to further extend the range. As encoded frames are not decoded or re-encoded, this can also be quite efficient.

Examples:

- Original Broadcaster is located in a large building with many interior walls, and broadcast audio cannot be directly received at throughout building. Broadcast Sink(s) co-located with Broadcast Source(s) ("relays") can be placed at one or more interior points within building to re-transmit audio so that the distance from any Broadcast Source ("relay") to any Broadcast Sink is within transmission range.

- Original Broadcaster is located outdoors e.g. in an urban environment with many buildings which block RF signals. Broadcast Sink(s) co-located with Broadcast Source(s) ("relays") can be placed at corners, enabling audio reception "around" buildings.

In order for the above to work, nRF5340s would need to function simultaneously in Broadcast Sink and Broadcast Source roles. The change in roles would need to be supported in real-time without reboot or re-configuration.

This is a Broadcast-only application, so Unicast cannot be used.

It is interesting that this configuration does function correctly (for some tens of minutes) before failing. It is possible there are packet collisions (since timing of received packets is controlled by remote Broadcast Source and not local Broadcast Sink) but perhaps these need not be fatal. There may be other reasons as well. Perhaps some changes in audio stream definition (bandwidth, latency, retransmit count, etc.) and/or SD Controller configuration could be used to improve the results. We appreciate any insight or suggestions you may be able to provide.

Thank you,

Carl

[droid]

Hello Maria,

Thank you for the upload instructions and message re-formatting. I do not have a professional sniffer, so only Segger trace and program log information is available. I have uploaded main.c sources for bap_broadcast_source (modified from NCS 3.2.0, zephyr/samples/bluetooth/bap_broadcast_source) and bap_broadcast_sink (modified from NCS 3.2.0, zephyr/samples/bluetooth/bap_broadcast_sink). Please let me know what other information I can provide.

Also, I will be out of the office from April 11 until April 29.

bap_broadcast_sink_main.zip

bap_broadcast_source_main.zip

[Maria Gilje]

Hi Carl, 

I hope you are doing well after your time off.

While you were already out of office, I started to run the bap_broadcast samples with your modified main on two nRF7002 DKs, but unfortunately I am not able to get the broadcast source to start on the combined device. My current prj.conf looks like this: 

CONFIG_BT=y
CONFIG_LOG=y
CONFIG_BT_AUDIO=y
CONFIG_BT_SMP=y
CONFIG_BT_PAC_SNK=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n
# Set preferred values based on BT_BAP_CONN_PARAM_RELAXED
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=50
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=70
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=400
CONFIG_BT_OBSERVER=y
CONFIG_BT_GATT_DYNAMIC_DB=y
CONFIG_BT_EXT_ADV=y
CONFIG_BT_PER_ADV_SYNC=y
CONFIG_BT_ISO_SYNC_RECEIVER=y
CONFIG_BT_BAP_BROADCAST_SINK=y
CONFIG_BT_BAP_SCAN_DELEGATOR=y
CONFIG_BT_ISO_MAX_CHAN=2
# Allocate 4 RX buffers per channel
CONFIG_BT_ISO_RX_BUF_COUNT=8
CONFIG_BT_BAP_BROADCAST_SNK_SUBGROUP_COUNT=2
CONFIG_BT_BAP_BROADCAST_SNK_STREAM_COUNT=2
CONFIG_BT_BAP_BASS_MAX_SUBGROUPS=2
CONFIG_BT_BUF_ACL_RX_SIZE=255
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_AUDIO_CODEC_CFG_MAX_METADATA_SIZE=64
CONFIG_BT_AUDIO_CODEC_CFG_MAX_DATA_SIZE=64
CONFIG_BT_AUDIO_CODEC_CAP_MAX_METADATA_SIZE=64
CONFIG_BT_AUDIO_CODEC_CAP_MAX_DATA_SIZE=64

CONFIG_BT_DEVICE_NAME="Broadcast Audio Sink"

# Broadcaster configs
CONFIG_MAIN_STACK_SIZE=2048
CONFIG_BT_ISO_BROADCASTER=y
CONFIG_BT_BAP_BROADCAST_SOURCE=y
CONFIG_BT_BAP_BROADCAST_SRC_STREAM_COUNT=2
CONFIG_BT_BAP_BROADCAST_SRC_SUBGROUP_COUNT=1

CONFIG_BT_ISO_TX_BUF_COUNT=12
CONFIG_BT_ISO_TX_MTU=60

CONFIG_BROADCAST_ID=0x123123

CONFIG_REBOOT=y

During my testing and trying different Kconfig symbols I was not able to get the broadcast source to start. bap_broadcast_source is working well. 

Could you please share your prj.conf for your modified bap_broadcast_sink? Both for the main application and hci_ipc (or the network core image you are using). 

My apologies for not having better feedback to give you after your break. I realise I should have done a test run before you went away, but alas. 

Best regards,

Maria

[droid]

Hello Maria,

It may be that changes to SD Controller .conf are required. System error codes may help to indicate this. Attached are bap_broadcast_sink and nrf/applications/ipc_radio (overlay) .conf files.The latter has some extra values used here for internal testing (e.g. PAwR) which may be removed if there is any issue with Flash/RAM sizes (there should not be). Please let me know if I can provide further information.

Thank you,

0880.prj.confoverlay-bt_hci_ipc.conf

[Susheel Nuguru]

Hi Carl,

Maria is partly away and I will try to assist during that time.

Firstly, I think we need to understand one thing, The SDController supporting scanning and advertising simultaneously does not translate into it being reliably sustain simultaneous broadcase sink + broadcase cource ISO audio under arbitrary BIS timing. LE Audio is much tighter than normal adv/scan

That said, it is not that easy to see where exactly the issue is. We would need a sniffer trace without which it is difficult to see what loss/collision or starvation happened and on which side. 

Try reducing load and see if that helps, 1BIS, longer ISO interval, larger presentation delays and try using 2M PHY. 

The feature you are testing seems to be very demanding given the clock speed of nRF53

[droid]

Hello Susheel,

I appreciate your looking into this issue.

About your suggestions:
- bap_broadcast_source sample does send only 1 BIS
(we set CONFIG_BT_BAP_BROADCAST_SRC_STREAM_COUNT=1 in prj.conf)
- only 1 BIS is LC3 decoded (and no BIS is LC3 encoded) by
bap_broadcast_sink sample ("relay"), so CPU load should be low
- only 40B data is sent/received in 10ms ISO interval
- presentation delay should not affect results as bap_broadcast_sink
sample ("relay") only re-transmits received (LC3 encoded) frames
- 2M PHY is configured

Also, nRF53 supports bi-directional CIS:
docs.nordicsemi.com/.../README.html

Although CIS and BIS are quite different, CIS load is higher
(due to LC3 encoding) and yet it can be bi-directional.

The modified bap_broadcast_sink sample ("relay") operates correctly
for several minutes, indicating load and timing are not issues
(at least for those several minutes).

I agree a sniffer trace would be helpful, and I had previously understood
that Nordic could run test applications, which I uploaded.
As SD Controller source code is unavailable, it is difficult to debug
further here. Our Nordic sniffer does not appear able to capture
relevant information.

I would be grateful for any further help you may be able to provide.

Thank you,
Carl Stehle