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,

[Karl Ylvisaker]

Hello,

Excited to have ordered my BLE Audio DK

I am happy to hear that! :) 

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?

The rule of thumb is that the LC3 codec produces approximately ~15% CPU load when decoding and ~30% CPU load when encoding a 96 kbps stream, so you may indeed decode multiple incoming streams on your nRF5340 Audio DK.

I wasnt sure whether you'd recommend connected or broadcast - I understand connected minimises packet loss due to feedback. 

Could you clarify what you mean when you say 'feedback' in this context?
As a side note, you can configure retransmissions for the Broadcaster as well, so that there are multiple chances for the receiver to pick up the audio frame, if that is what you are asking.

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

This will largely depend on a number of factors such as your audio parameters, retransmissions count, link stability / RF environement (in the Connected Isochronous Streams case), audio input/output configuration, and what other peripherals your application is using, so it is hard for me to estimate what you may expect here.
I will ask internally if we have some concrete numbers we can share on this, and I will update you as soon as I hear back about it.

Best regards,
Karl

[Hillman007]

Karl Ylvisaker said:

Could you clarify what you mean when you say 'feedback' in this context?
As a side note, you can configure retransmissions for the Broadcaster as well, so that there are multiple chances for the receiver to pick up the audio frame, if that is what you are asking.

Yes, about retransmissions to over come link issues. I heard in a video that Connected mode is better for robustness but obviously limits the number of listeners. 

Karl Ylvisaker said:

I will ask internally if we have some concrete numbers we can share on this, and I will update you as soon as I hear back about it.

That would be good. I guess I could use your ~15CPU to estimate. I am probably interest in 16bit 16kHz input stream.