Bluetooth: Samples: bluetooth_audio_source does not send multiple streams

[carlst]

Describe the bug
samples/bluetooth/broadcast_audio_source with CONFIG_BT_AUDIO_BROADCAST_SRC_STREAM_COUNT=2 fails to send data after sending initial buffers.

Please also mention any information which could help others to understand
the problem you're facing:

• platform is nRF52840DK
• commit 1dfc469
• tried previous commits but other issues with multiple ISO channels prevented testing
• first 2 buffers appear to be sent for both streams. After this, stream_sent_cb is only invoked for 1st stream

To Reproduce
Steps to reproduce the behavior:

1. Edit samples/bluetooth/broadcast_audio_source/prj.conf to contain CONFIG_BT_AUDIO_BROADCAST_SRC_STREAM_COUNT=2
2. Add printk to src/main stream_started_cb and stream_sent_cb to display stream value each time a data buffer is sent
3. Build for nRF52840DK
4. Run (e.g. using Segger Embedded Studio) with RTT log

Expected behavior
Expect stream_sent_cb to show data sent for each stream in log.

Logs and console output
See attached console log file broadcast_audio_source_20220908.txt

broadcast_audio_source_20220908.txt

[Thalley]

Likely a controller issue

[carlst]

Checking samples/bluetooth/iso_broadcast with CONFIG_BT_ISO_MAX_CHAN=2, only 3 calls are made to bt_iso_chan_send()

[cvinayak]

@carlst Please try this #50126 and let me know it resolves the issue you face.

[carlst]

@cvinayak The issue does not occur with the code branch that fixes #50126. Initial testing indicates stream_sent_cb is now being called in an alternating fashion for both streams. Will continue to test both broadcaster and receiver with various samples, but I consider this issue resolved. Please close as you see fit.

[cvinayak]

@carlst Thank you for testing. The implementation on the synchronised receiver is not optimized and also I noticed that after certain number of subevents in the ISO event the PDUs are not received. I.e. on a nRF52833 DK (that I used today), second stream PDUs where not received (controller generates invalid status for the ISO data). This is to do with the window calculations that need some tuning. I will send separate PRs when I have satisfactory fix.

[carlst]

@cvinayak Ah, that may explain the variations in bt_iso_recv_info flags and len 0 values (see attached log from samples/broadcast_audio_sink on nRF52840DK with printk in stream_recv_cb). I was concerned about stability of multi-BIS (audio). I can attest 1 BIS has been rock-solid stable over extended periods of time (at least an hour on nRF52840DK with a PDM mic as source, and routing sink data through USB to a PC audio/speaker).

broadcast_audio_source_20220913.txt

[cvinayak]

@carlst It is surprising that you have the second stream data as much as the first stream on your board.

The occasional invalid data which appear on both streams is unrelated to what I am observing on my board where first stream get valid data and the second gets invalid data (this is apparently due to the listen time tuning required).

Your invalid data could be due to missing PDUs on-air from the broadcaster. It could be that the Extended Advertising and Periodic Advertising PDUs are taking more time causing that to overlap with BIG events that is being transmitted.