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 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? 

[Karl Ylvisaker]

Hello,

Hillman007 said:

approach: modify the audio applicationn sample - good?

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.

Hillman007 said:

So this would mean building two gateways and one headset. The gateways currently have the same name. Do you think that is a problem?

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.

Hillman007 said:

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.

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?

Hillman007 said:

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? 

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

[Hillman007]

Karl Ylvisaker said:

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

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. 

Karl Ylvisaker said:

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.

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

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.

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.

[Hillman007]

Hillman007 said:

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)

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?

[Karl Ylvisaker]

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.

Hillman007 said:

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. 

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.

Hillman007 said:

I am new do Zephyr and in general to BLE/Nordic.

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

Hillman007 said:

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.

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.

Hillman007 said:

This gives me an error of:

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

Hillman007 said:

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.

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

[Karl Ylvisaker]

Hillman007 said:

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?

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