BLE Audio - many to one, power consumptions of DK?

[Hillman007]

Excited to have ordered my BLE Audio DK which uses NRF5340.

In my use case I am looking for many microphones (audio transmitters) to a single listening device (audio receiver). Ideally, they'd be synchronised reasonably well but again that is something we can deal with in the back-end system. In terms of link robustness, will this work? e.g. 5 senders to one listener? 16bit, 16kHz ideal, but could be reduced if needed. 5 was a random number, even two would be useful. Can one use variable rates on each stream? And then I wasnt sure whether you'd recommend connected or broadcast - I understand connected minimises packet loss due to feedback. 

Finally, any idea of the DK / estimated power consumption for nRF5340 to send a single audio stream?

Thanks in advance,

[mtsunstrum]

I suspect the current consumption would be roughly comparable.

My main point though was that LE Audio with many transmitters to one receiver is not technically possible.

[Hillman007]

ok thanks - that isnt what I took away from Karl, but thank you for being clear. 

[Karl Ylvisaker]

Hello Hillman and mtsunstrum,

mtsunstrum said:

My main point though was that LE Audio with many transmitters to one receiver is not technically possible.

This is not correct at all. Could you elaborate on what gives you this impression?
LE Audio definitively allows for multiple transmitters to the same receiver - it is not as prominent a feature as Audio Sharing, but it is definitively possible. The main limitation here would be on the receiver's side in how many concurrent streams it would be able to decode, like I explained in my initial comment.

mtsunstrum said:

I suspect the current consumption would be roughly comparable.

As for expected power consumption I have not been able to find any numbers on this internally, unfortunately.
The nrf5340_audio application does not have any power optimization as far as I know, and so I expect its current draw to be quite high as is, so long as power saving measures are not added.

Best regards,
Karl

[Karl Ylvisaker]

I would also like to add a comment regarding the possibility to use 'traditional BLE' for real-time audio transfer:

While you in many cases would be able to achieve a microphone-speaker design with a pre-LE Audio BLE connection it is far from ideal, since the BLE connection is loss-less, meaning that either every packet will be transmitted, or the connection will be terminated.
This is a great feature for data-transfer in general, but for Audio in particular it gets a little rocky when you start missing packets and the time of playback for those packets is approaching.
In the pre-LE Audio BLE case, the lost packets will still be transferred, but they will no longer be useful to the receiver.
However, with Isochronous channels the BLE Controller will be able to discard packets that will not make it to the receiver in time for their playback, which enables it to proceed with the next audio instead of building up a backlog of no-longer-relevant packets that still needs to be transferred.
This is just one of the many reasons why LE Audio is a much better fit for audio transmission applications over pre-LE Audio BLE Connections.

Best regards,
Karl

[Hillman007]

Karl thank you for responding. My boards have arrived so I am going to start to implement two to one and see how we do. I will then look into power optimisitions - is there any specific areas you'd recommend looking at?

[Hillman007]

I enjoyed reading your thinking on this. Thank you for sharing. I will, of course, reply with how it goes.

[Karl Ylvisaker]

Hillman007 said:

Karl thank you for responding.

No problem at all, I am happy to help! :) 

Hillman007 said:

My boards have arrived so I am going to start to implement two to one and see how we do.

Great! Please do not hesitate to let us know if you should encounter any other issues or questions when working with this.
I highly recommend familiarizing with the audio application specific 'buildprog' tool, by the way, since it makes building and flashing multiple boards with different versions of the same application (debug/release, gateway/headset) automated and efficient.
You can read about the buildprog tool in the documentation, or use the python buildprog.py --help command to see its options.

Hillman007 said:

I will then look into power optimisitions - is there any specific areas you'd recommend looking at?

In general, the best way to save power is to maximize the time spent in SYSTEM_ON sleep. How to best achieve this will wary for each application / use-case, but if you can reduce radio time (reduce retransmissions, increase connection parameters, etc.) you can spend more time in sleep, which should yield more time spent in SYSTEM_ON sleep.
My recommendation would here be that you try out the unmodified nrf5340_audio application from the v1.9.99-dev1 tag, and then use those measurements as a reference for when you try to tweak the different parameters and configurations, to see their impact.

Best regards,
Karl