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

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

user3313 — Wed, 15 Jun 2022 22:16:40 GMT

Hi Karl, welcome back, and thank you for the responses.

For example, I would regard @Hillman007 use-case as a non-standard LE Audio use case.

I understand ( or I think I understand) that the PacketCraft controller handles BLE 5.3 operations on the network core, and I understand the upper layers of LE Audio are handled by NCS, running on the application core.

So for the binary PacketCraft controller, are there limitation such as:

a limit on the # of concurrent isochronous channels ?
any restrictions on number of concurrent "normal" LE Central / Peripheral connections
any restrictions on ability to support simultaneous LE Audio gateway and headset operation ?
is the PacketCraft work compliant with MPLS in any way, still allowing concurrent operation of ShockBurst/Gazell if we so choose.
for nRF5340 project, if we wanted to change DLE ( data length ), we had to change prj.conf setting for the network core, and rebuilt the network core. Are DLE changes affected/limited by the binary PacketCraft controller ?
compared to Nordic's own SoftDevice Controller are they any other capabilities missing from the PacketCraft controller ?

Thanks, Martin

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

user87869 — Wed, 15 Jun 2022 21:24:14 GMT

Hello mtsunstrum,

Thank you for your patience with this.

[quote user="mtsunstrum"]Does it have limitations that may prevent developers from working with non-standard LE Audio use cases ?[/quote]

Could you elaborate on what kind of non-standard LE Audio use cases you are referring to here?
The precompiled Packetcraft controller should not limit your LE Audio application, no. The Packetcraft controller implements the isochronous channels necessary for LE Audio.

Best regards,
Karl

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

user87869 — Wed, 15 Jun 2022 21:20:36 GMT

[quote user="Hillman007"]So I think my issue is that I need to use chlild image to compile the net core. But by default the audio application uses a precompiled one. Is this something I can change?[/quote]

The precompiled one is Packetcraft controller I mention in my previous comment.
Is there a particular reason for why you would not like to use the Packetcraft controller?

Best regards,
Karl

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

user87869 — Wed, 15 Jun 2022 21:19:38 GMT

Hello again,

Thank you for your extreme patience with this - I have been out of office for some time now, but I am now back.

[quote user="Hillman007"]Yes just to show I can receive two streams at the perpherial/headset end. I hope that will be enough for me to measure the power consumption for receiving one or more streams. [/quote]

That should be enough to measure the power consumption of receiving and processing two streams, yes. The main power consumption will come from the added radio traffic and processor usage, while the power used to output the stream to a speaker should be minimal.

[quote user="Hillman007"]I am new do Zephyr and in general to BLE/Nordic.[/quote]

Thank you for saying so, this is good for us to know.

[quote user="Hillman007"]

1. I have added to prj.conf:

CONFIG_BT_LL_SOFTDEVICE=y
CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT=2

So this will run the Nordic softdevice which supports some additional features vs Zephyr Host? And then setting the number of concurrent connections? (which will only apply to the peripheral / headset ? I am hoping - based on another forum post I read, that this is sufficient to make the advertising resume.

[/quote]

The SoftDevice Controller does not support Isochronous streams, and so you should not add these configurations to your prj.conf.
Instead, you should use the rpmsg controller from Packetcraft that is included in the nrf5340_audio application's /bin folder as your network core / controller image.
The Packetcraft controller is the controller we have made available for LE Audio development for the nRF5340, and it is the controller that the nrf5340_audio reference application uses.

[quote user="Hillman007"]This gives me an error of:[/quote]

The errors are likely due to dependencies and supported functions not being present with the SoftDevice controller included instead of the Packetcraft controller.

[quote user="Hillman007"]

2. in overlay headset:

CONFIG_BT_MAX_CONN=2
CONFIG_BT_ISO_MAX_CHAN=2
CONFIG_BT_MAX_PAIRED=2

So I am now thinking I'll need to change the callback behaviour to differentiate the connections - I imagine it was written assume just one connection.

[/quote]

Yes, you will need to duplicate the enabling and handling/processing of the additional stream, since the headset applications indeed are written for receiving a single stream (such as in the earbud / hearing aid use-case).

Best regards,
Karl

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

user3313 — Sun, 12 Jun 2022 00:28:09 GMT

Curious to see how this effort progresses.

@Hillman007 have you found you may need to make changed to the net core ( child image ) ?

I am interested in knowing what limitations there may be in the binary child image.

Does it have limitations that may prevent developers from working with non-standard LE Audio use cases ?

Hopefully NordicSemi can shed light on this.

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

user101804 — Wed, 01 Jun 2022 09:59:25 GMT

[quote userid="101804" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/370299#370299"]warning: ENTROPY_NRF5_RNG (defined at drivers/entropy/Kconfig.nrf5:14) has direct dependencies !ENTROPY_NRF_FORCE_ALT && HAS_HW_NRF_RNG && ENTROPY_GENERATOR with value n, but is currently being y-selected by the following symbols:
- BT_LLL_VENDOR_NORDIC (defined at subsys/bluetooth\controller\Kconfig.ll_sw_split:11), with value y, direct dependencies SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y), and select condition SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y)[/quote]

So I think my issue is that I need to use chlild image to compile the net core. But by default the audio application uses a precompiled one. Is this something I can change?

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

user101804 — Tue, 31 May 2022 20:44:27 GMT

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/369856#369856"]Do I understand it correctly that you would still like the device to stay in a connection and receive a stream that it is not necessarily outputting to a speaker/headphone, simultaneously as it is playing the audio from the other source[/quote]

Yes just to show I can receive two streams at the perpherial/headset end. I hope that will be enough for me to measure the power consumption for receiving one or more streams.

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/369856#369856"]There is however no issue for the gateway to encode and transfer multiple streams at the same time.
To demonstrate stereo sound you would therefore have to use 2 Audio DKs as headphones, where each of them outputs one of the stereo channels.[/quote]

Yes - I understand that. For now, I dont need to hear it. Just to allow measurements is sufficient. Hopefully you feel this approach is sufficient.

I am new do Zephyr and in general to BLE/Nordic. So a few things:

1. I have added to prj.conf:

CONFIG_BT_LL_SOFTDEVICE=y
CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT=2

This gives me an error of:

warning: ENTROPY_NRF5_RNG (defined at drivers/entropy/Kconfig.nrf5:14) has direct dependencies !ENTROPY_NRF_FORCE_ALT && HAS_HW_NRF_RNG && ENTROPY_GENERATOR with value n, but is currently being y-selected by the following symbols:
- BT_LLL_VENDOR_NORDIC (defined at subsys/bluetooth\controller\Kconfig.ll_sw_split:11), with value y, direct dependencies SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y), and select condition SOC_COMPATIBLE_NRF && BT_LL_SW_SPLIT && BT_CTLR && BT_HCI && BT (value: y)

2. in overlay headset:

CONFIG_BT_MAX_CONN=2
CONFIG_BT_ISO_MAX_CHAN=2
CONFIG_BT_MAX_PAIRED=2

So I am now thinking I'll need to change the callback behaviour to differentiate the connections - I imagine it was written assume just one connection.

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

user87869 — Sun, 29 May 2022 13:33:26 GMT

Hello,

[quote user="Hillman007"]approach: modify the audio applicationn sample - good?[/quote]

Yes, if you are using the buildprog tool you will need to modify the application sample directly.
If you would like to use the traditional NCS approach you can do so as well, through using the 'generate application from sample' option in VS code. You will then have to program and flash each kit with each configuration / variation that you make, but there will be a clearer distinction between the application, and easier versioning for complex projects.

[quote user="Hillman007"]So this would mean building two gateways and one headset. The gateways currently have the same name. Do you think that is a problem?[/quote]

Are you working with the CIS or the BIS mode? In case of the CIS mode then the gateways are traditional central devices, and so their name will not be advertised - it is also the centrals who initiate connections, etc.
You should then see your headset device advertise as a traditional peripheral device, displaying its device name.
So as long as the headset keeps advertising as connectable after the first connection it should not be any problem.

[quote user="Hillman007"]To get the headset to allow two connections, I will modify the advertising behaviour to re-advertise to allow the second gateway/controller connect. And increase the maximum number of connecitons. I play to then use a button to make the audio output stream to the headphones to select between the two sent audio streams.[/quote]

This is what I too would recommend you to do. Do I understand it correctly that you would still like the device to stay in a connection and receive a stream that it is not necessarily outputting to a speaker/headphone, simultaneously as it is playing the audio from the other source?

[quote user="Hillman007"]Maybe as an extention I might add a stereo codec and have left for controller A and right for controller B streams. what do you think? [/quote]

The Audio DK can encode and stream stereo (multiple streams concurrently) audio, but the issue you would face here would be the stereo playback capabilities of the Audio DK - the audio DK is made to demonstrate / develop for the 'earbud scenario' - i.e the HEADPHONES audio jack output can only output mono channel audio. That is to say, if you plug in a stereo headset into the HEADPHONES jack you will only have audio on the left ear.
There is however no issue for the gateway to encode and transfer multiple streams at the same time.
To demonstrate stereo sound you would therefore have to use 2 Audio DKs as headphones, where each of them outputs one of the stereo channels.

Please do not hesitate to ask if any part of this should be unclear, so that I may elaborate! :)

Best regards,
Karl

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

user101804 — Thu, 26 May 2022 19:01:55 GMT

user87869 progress so far so good. I have got the buildprog chain working and tested. and had a good look over the code - in terms of its architecture. Disabled LC3 for now, whilst I get repo access.

So I wanted to run my approach past you:

aim "I would like to audio senders to one audio receiver".

approach: modify the audio applicationn sample - good?

So this would mean building two gateways and one headset. The gateways currently have the same name. Do you think that is a problem? I couldnt figure out how to generate two individual names. It seemed CONFIG_BT_DEVICE_NAME is somewhat hard coded, and I couldnt find where the build script is pulling that value into the auto_config.h file. For example, I thought I could perhaps use the unused channel paramter in dk_devices.json. I also thought about using CONFIG_BT_DEVICE_NAME_DYNAMIC=y in the overlay. But I was unable to find a "ble set name" function...

To get the headset to allow two connections, I will modify the advertising behaviour to re-advertise to allow the second gateway/controller connect. And increase the maximum number of connecitons. I play to then use a button to make the audio output stream to the headphones to select between the two sent audio streams. Maybe as an extention I might add a stereo codec and have left for controller A and right for controller B streams. what do you think?

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

user87869 — Fri, 20 May 2022 09:58:04 GMT

Hello,

[quote user="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:

[/quote]

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

[quote user="mtsunstrum"]But I now understand that is not the only configurations that LE Audio supports, but rather limits of nRF Audio DK demo applications.[/quote]

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.

[quote user="mtsunstrum"]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.[/quote]

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

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

user3313 — Wed, 18 May 2022 17:46:09 GMT

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.

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

user87869 — Wed, 18 May 2022 15:12:17 GMT

[quote user="Hillman007"]Karl thank you for responding.[/quote]

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

[quote user="Hillman007"]My boards have arrived so I am going to start to implement two to one and see how we do.[/quote]

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.

[quote user="Hillman007"]I will then look into power optimisitions - is there any specific areas you'd recommend looking at?[/quote]

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

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

user101804 — Wed, 18 May 2022 14:13:20 GMT

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

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

user101804 — Wed, 18 May 2022 14:12:48 GMT

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?

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

user87869 — Wed, 18 May 2022 09:01:20 GMT

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

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

user87869 — Wed, 18 May 2022 08:24:57 GMT

Hello Hillman and mtsunstrum,

[quote user="mtsunstrum"]My main point though was that LE Audio with many transmitters to one receiver is not technically possible.[/quote]

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.

[quote user="mtsunstrum"]I suspect the current consumption would be roughly comparable.[/quote]

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

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

user101804 — Mon, 16 May 2022 19:18:04 GMT

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

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

user3313 — Mon, 16 May 2022 18:40:30 GMT

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.

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

user101804 — Mon, 16 May 2022 12:42:03 GMT

[quote userid="3313" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/367918#367918"]

Best to try to accomplish that using traditional BLE Central and multiple Peripheral connections.

[/quote]

Thanks for your thoughts. I appreciate that. You dont feel a BLE Audio stream 1:1 is lower power than standard BLE?

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

user3313 — Sat, 14 May 2022 20:57:19 GMT

LE Audio supports broadcast audio, from one audio source (transmitter) to multiple sinks ( receivers )

What you are describing is the opposite ... multiple sources, but only one sink.

Best to try to accomplish that using traditional BLE Central and multiple Peripheral connections.

ie. not LE Audio

This would be viable ... but best if the microphone transmissions are not persistent.

i.e. microphone transmission while a person is talking, but not other times.

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

user101804 — Fri, 13 May 2022 19:00:37 GMT

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/367897#367897"]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.[/quote]

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.

[quote userid="87869" url="~/f/nordic-q-a/87822/ble-audio---many-to-one-power-consumptions-of-dk/367897#367897"]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.
[/quote]

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

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

user87869 — Fri, 13 May 2022 17:25:39 GMT

Hello,

[quote user=""]Excited to have ordered my BLE Audio DK[/quote]

I am happy to hear that! :)

[quote user=""]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?[/quote]

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.

[quote user=""]I wasnt sure whether you'd recommend connected or broadcast - I understand connected minimises packet loss due to feedback. [/quote]

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.

[quote user=""]Finally, any idea of the DK / estimated power consumption for nRF5340 to send a single audio stream?[/quote]

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