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,

[Hillman007]

Karl Ylvisaker said:

In general, it is however the nRF5340 that we recommend for wireless audio applications, as the LC3 codec significantly will reduce the necessary size of transfer, which in turn reduced power consumption by requiring less CPU and RADIO time.

Yes - you are right. So we just need to send the audio the server for playback another day. So standard BLE is not an issue from latency.HOWEVER as you say, the CODEC is still very much of interest and clearly reduces the power consumption of the overall system despite the added computation over-head. So I am still very much looking at the dual core SoC.

Karl Ylvisaker said:

There is currently no power optimization made to the nRF5340_audio reference application.
Could you detail your setup for the 12 mA power consumption measurement?

This was simply the default application - audio from laptop to speaker. I used the head on the evaluation kit to meaure it. Indeed no optimisation. So I am hopeful for lower but that is sufficient starting point to be worthy of investment. 

So my next step is to go back to "the non audio dk" and build up a custom application - including adding the LC3 codec. Karl Ylvisaker does that seem the right approach to you? That way I dont need to worry about lack of packet craft documentaiton either. 

[mtsunstrum]

Yes, if it is just voice, not music you need to transfer, you can skip the memory and processing intensive LC3 codec.

You can use other open-source codecs out there like Broadcom BV16/BV32 ( 8 or 16kHz bandwidth ).

They will encode/decode comfortably within the processing/RAM available in a nRF52832.

[mtsunstrum]

When doing BV16 encoding ( for your microphone transmission ) on a nRF52832, CPU % utilization was about 35%

For BV16 decoding ( for reception ) on a nRF52832, CPU % utilization was about 7.5%

So roughly, your nRF52832 receiver unit could conceivably handle receiving from about 10 transmitters simultaneously. ( leave some CPU utilization for other activities )

Current draw roughly would be in 10mA range overall, or about 1mA for each audio link.