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]

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

[mtsunstrum]

Yes, I stand corrected, the underlying LE Audio framework is quite flexible, and can support that use case.

I was basing off of demonstrated application modes:

See https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/nrf5340_audio/README.html#application-modes

But I now understand that is not the only configurations that LE Audio supports, but rather limits of nRF Audio DK demo applications.

As you have indicated CPU resources may be the limiting factor, if attempting to decode 5+ microphone transmitters simultaneously. This might be overcome, depending on mic audio bandwidth needs, and possible usage of other lower complexity codecs.

[Karl Ylvisaker]

Hello,

mtsunstrum said:

Yes, I stand corrected, the underlying LE Audio framework is quite flexible, and can support that use case.

I was basing off of demonstrated application modes:

Thank you for elaborating - I see how the note in the documentation could be interpreted this way.

mtsunstrum said:

But I now understand that is not the only configurations that LE Audio supports, but rather limits of nRF Audio DK demo applications.

Yes, that is to say: the nrf5340_audio application is still being developed - with new features and improvements still in the making.
However, there are no technical limitations on neither the nRF5340 SoC nor the LE Audio specification that prevents anyone from implementing a multiple-sink scenario themselves independently, based on the nRF5340_audio application.

mtsunstrum said:

As you have indicated CPU resources may be the limiting factor, if attempting to decode 5+ microphone transmitters simultaneously. This might be overcome, depending on mic audio bandwidth needs, and possible usage of other lower complexity codecs.

Yes - the flexibility of the LE Audio specification and the performance of the LC3 codec opens many possibilities for this. However, the biggest bottleneck for 5+ microphones would likely be the CPU load, but these issues could very well be alleviated by the configurations you note in your comment, or for example by relaxing the latency constraint - so long as they are feasible for the application, of course.

Best regards,
Karl