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. 

[Karl Ylvisaker]

Hello Hillman,

Sorry for the increase in response-time here. The summer holiday has begun here in Norway, and so DevZone is operating at reduced capacity for the duration.

Hillman007 said:

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.

Sure, that could work as long as you have the time and memory to see the audio transfer happen over a regular BLE link, then it should be no problem.
Please also keep in mind that our LC3 implementation is made specifically for use with, and optimized for, the nRF5340.

Hillman007 said:

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. 

Great, I am happy to hear that! :) You will definitely see a lower average consumption once it is power optimized.

Hillman007 said:

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. 

Yes - with the change in the application requirements to do non-live audio transfer it sounds to me like you will not be needing the on-board audio specific peripherals of the nRF5340 Audio DK, so long as you are able to get the data for transfer over to the nRF5340 some other way (such as through any of the serial protocols directly).
The application is thus reduced to a regular 'transfer data' use-case, for which the nRF53 DK should be used.

Best regards,
Karl

[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.