nrf5340_audio example sample rate issue with bidirectional streaming

[Odiug]

SDK version: 3.2.4

I am using two nRF5340 Audio DK boards configured as gateway and left headset.

I added "CONFIG_STREAM_BIDIRECTIONAL=y" to prj.conf and I built everything with: "python tools/buildprog/buildprog.py -c both -b debug -d both -t unicast -p --pristine".

When just recording from "Headset Microphone (nRF5340 USB Audio)" everything is fine.

When just playing back something to "Headset Earphone (nRF5340 USB Audio)" that also works.

But when playing and recording at the same time, the audio output is choppy and playing at half the speed. There seems to be some sample rate mismatch.

To reproduce with Audacity: Load some audio data, check Preferences->Recording->"Record on a new track", make sure the right playback and recording devices are selected and hit the record button. Audacity should now play and record as an additional track at the same time. Listen to the headphone output on the headset device.

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?

I let CoPilot (GPT-5.3-Codex) analyze the issue and got a lengthy Root Cause Analysis that I can share if you want. As I am not familiar with your audio framework, I cannot judge its accuracy.

I have read your AI generated response claiming that it is a resource issue, but I think it is not the full picture. Well, indeed, hard to tell.

Actually, I wanted to test a certain scenario to evaluate Bluetooth LE Audio synchronization where I output audio data from USB directly at the gateway and record microphone data coming from the headset via BLE audio. That would only involve one path via BLE Audio. Would such a setup work?

Kind regards,

Guido

[Elfving]

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.

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?

Could you link me to this?

Regards,

Elfving

[Odiug]

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

[Elfving]

Hi,

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

Odiug said:

Both signals are mono and 16000kHz sample rate

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

[Odiug]

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

[Elfving]

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

Regards,

Elfving

[Odiug]

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

[Elfving]

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

[Odiug]

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

[Elfving]

Sorry about the wait Guido, catch-up after the Easter took a bit longer than expected. Did you not see these "Out of RX buffers" logs before enabling these THREAD_ANALYZER configs?