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]

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?