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,

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

[Susheel Nuguru]

Hi Carl, your points seems very valid.

the root cause is likely BIG anchor drift between the two ISO trains.

Your local Source BIG and the received Sink BIG both run at 10ms but are on independent clocks (±40ppm crystal difference = ~0.8µs drift per interval). After few minutes, the two event windows overlap enough that the SDC scheduler must drop one, most likely causing the burst errors you see.

• detect sequence number gaps in bt_iso_recv and restart the Source BIG. Re-creation lands at a random anchor offset, buying another ~10–15 minutes before the next collision window.

• Test on NCS 3.3.0, i recently learnt that there have been SDC scheduling improvements since 3.2.0 worth evaluating.

[droid]

Hello Susheel,

The issue does not occur with NCS 3.3.0 SD Controller (previously using NCS 3.2.0 SD Controller).

I did not notice anything particular in the SD Controller CHANGELOG but perhaps certain data timings are handled differently.

Thank you for your help.

Carl Stehle