nrf5340_audio example sample rate issue with bidirectional streaming

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Odiug — Wed, 01 Apr 2026 08:52:39 GMT

I used this in prj.conf:

CONFIG_THREAD_ANALYZER=y

CONFIG_THREAD_ANALYZER_USE_PRINTK=y

#CONFIG_THREAD_ANALYZER_USE_LOG=y

CONFIG_THREAD_ANALYZER_AUTO=y

CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5

It outputs statistics on VCOM0 now. But only as long as I have not enabled any playback. Then output freezes and after stopping playback, I get a lot of:

GW [00:19:01.010,559] <wrn> le_audio_rx: Out of RX buffers

I guess the UART handling starves while playback is active.

Guido

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Elfving — Tue, 31 Mar 2026 09:07:07 GMT

If you happened to not use 48 in both directions, then that might have ironically inreased the CPU usage since the sample rate converter would need to be active. But I thought having a single stream in each direction would be okay.

Could you check the CPU numbers using this or this? The thread analyzer might be the easiest.

Regards,

Elfving

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Odiug — Fri, 27 Mar 2026 09:14:23 GMT

Yes, indeed.

The simplest reproduceable setup would be compiling nrf5340_audio with CONFIG_STREAM_BIDIRECTIONAL=y added in prj.conf. Then I used Audacity (under Windows) with a 48kHz audio file. Only playing works, and only recording works, but not playing and recording at the same time, which leads to stuttering and slow playback (set Audacity->Recording->Record on a new track, then Record).

But I understand that this might be a resource limitation of the nRF5340.

Guido

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Elfving — Fri, 27 Mar 2026 09:03:07 GMT

I think 48 would be good. Was 48 used in both directions?

Regards,

Elfving

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Odiug — Thu, 26 Mar 2026 12:08:16 GMT

I stated "16000kHz sample rate would be sufficient", well, I meant "16 kHz is sufficient".

I was actually using 48 kHz. But if anything else would be better suited...

Regards,

Guido

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Elfving — Thu, 26 Mar 2026 11:51:54 GMT

Hi,

This does sound like something that should be supported, yet also might be on the verge of being a resource issue.

[quote user="Odiug"]Both signals are mono and 16000kHz sample rate[/quote]

Is that also what you ran your original test with?

Btw, I've reached out to the relevant R&D team about this, but I am afraid that several are away on vacation at the moment, so there might be some delays in getting you an accurate answer here.

Regards,

Elfving

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Odiug — Thu, 26 Mar 2026 06:56:24 GMT

Hi Elfving,

What I actually wanted to do is having a look at how audio synchronization performs in general.

We wanted to investigate the following scenario: A device (gateway) connected via USB to a PC, playing audio to a speaker (headphone out) and at the same time capturing microphone audio from a remote BLE audio device (headset). We wanted to see how well the captured microphone audio data is synchronized to the played audio on the speaker. Both signals are mono and 16000kHz sample rate would be sufficient.

I thought the easiest example to start from would have been the bidirectional gateway + (single) headset setup (nrf5340_audio with -t unicast). It would provide synchronization between both devices and a microphone path from headset to gateway. The only thing to add would have been an additional audio output to the headphone jack on the gateway. But then I realized, I can either play OR record from the PC host, but not both at the same time.

Would it be possible to not send audio data to the remote device (headset) and only stream the microphone data to the gateway, but still play the audio data on gateway to the headphone?

So, I need the following functionalities

Gateway:

USB (from host) -> headphone jack (I2S)
USB (to host) <- BLE audio (from headset)

Headset:

BLE audio (to gateway) <- microphone (I2S)

I would assume that on the gateway side the I2S clock and the BLE frame clock are synchronized to the USB clock. On the headset the I2S clock should be synchronized to the BLE frame clock.

But this kind of synchronization might be different from how it is done normally in the unicast case.

Can you give some feedback on how to achieve our plans?

Kind regards,

Guido

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Odiug — Wed, 25 Mar 2026 09:12:50 GMT

Hi Elfving,

I was referring to:

There is also OCT-3560 under Known Issues (https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/known_issues.html#nrf5340_audio):

"OCT-3560: The audio application might be resource intensive, using significant amount of CPU for encoding, decoding, sample rate conversion, and USB

This is apparent when running bidirectional audio on the unicast gateway or client on the nRF5340. This might push the load over 100 % and result in poor audio, and lower priority threads such as logging. This is a known limitation."

So, I guess bidirectional and USB is not possible.

Regards,

Guido

RE: nrf5340_audio example sample rate issue with bidirectional streaming

Elfving — Fri, 20 Mar 2026 15:08:43 GMT

Hi Guido,

But besides these basic changes you haven't done anything else to the sample?

The issue here remings me a bit of the rule of thumb that for high quality audio, encoding a single channel takes about 30 % of the APP core CPU, and decoding takes 15 %. The USB takes ~20 % for receiving audio from a PC/host and another 10 % for sending. Although this shouldn't be a problem in the scenario you describe.

[quote user=""]

I saw an old issue posted here stating that bidirectional audio was not possible, but as this option is now available, I assume it should work by now?

[/quote]

Could you link me to this?

Regards,

Elfving