Panic, when playing music

[Zhongsan]

Hi

I have build a sample project nRF5430_audio for nRF5340 Auido DK(two DK, one for gateway, one for headset), following the guide:nRF5340 Audio — nRF Connect SDK 2.0.99 documentation (nordicsemi.com)

build the project: 

python buildprog.py -c both -b debug -d both -p

add following to prj.conf
CONFIG_SW_CODEC_SBC=y
CONFIG_AUDIO_SOURCE_USB=y
CONFIG_TRANSPORT_CIS=y

after streaming for a while,the headset will panic:
HL [00:08:42.849,517] <wrn> audio_datapath: Invalid sdu_ref_us delta (9983) - Estimating sdu_ref_us 
HL [00:08:44.309,600] <wrn> audio_datapath: Invalid sdu_ref_us delta (9983) - Estimating sdu_ref_us 
HL [00:08:53.321,838] <wrn> sw_codec_select: PCM samples dropped 
HL [00:08:53.321,868] <err> audio_datapath: Decoded audio has wrong size 
HL [00:08:53.321,868] <err> audio_datapath: ERR_CHK Err_code: [-140] @ line: 815 
HL [00:08:53.321,868] <err> os: r0/a1: 0x00000003 r1/a2: 0x00000003 r2/a3: 0x00000002 
HL [00:08:53.321,899] <err> os: r3/a4: 0x20001e10 r12/ip: 0x00000002 r14/lr: 0x00017b85 
HL [00:08:53.321,899] <err> os: xpsr: 0x41000000 
HL [00:08:53.321,899] <err> os: s[ 0]: 0x00000000 s[ 1]: 0x00000000 s[ 2]: 0x00000000 s[ 3]: 0x00000000 
HL [00:08:53.321,899] <err> os: s[ 4]: 0x00000000 s[ 5]: 0x00000000 s[ 6]: 0x00000000 s[ 7]: 0x00000000 
HL [00:08:53.321,929] <err> os: s[ 8]: 0x00000000 s[ 9]: 0x00000000 s[10]: 0x00000000 s[11]: 0x00000000 
HL [00:08:53.321,929] <err> os: s[12]: 0x00000000 s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0xffffffff 
HL [00:08:53.321,929] <err> os: fpscr: 0x200002f0 
HL [00:08:53.321,960] <err> os: Faulting instruction address (r15/pc): 0x0000651c 
HL [00:08:53.321,960] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0 
HL [00:08:53.321,960] <err> os: Current thread: 0x20001688 (AUDIO DATAPATH) 
HL [00:08:53.321,960] <err> error_handler: Caught system error -- reason 3. Entering infinite loop 

so, i think there is a bug, is any patch for it?

thanks

[Karl Ylvisaker]

Hello,

It seems that the data received is reported as the wrong size, which causes the operation to cancel.
Have you made any other changes to the reference application than those you have listed at the beginning of your ticket?

I notice that you are using the SBC codec, could you confirm that you have also removed the following:

CONFIG_LC3_ENC_CHAN_MAX=2
CONFIG_LC3_DEC_CHAN_MAX=1

from overlay-headset.conf and overlay-gateway.conf?

As a side note I would also like to recommend that you use the LC3 codec for your evaluation if possible, since it significantly outperforms the SBC in all aspects for the common audio use-cases.

Best regards,
Karl

[Zhongsan]

Hi

i am sure i have remove that from both  overlay-headset.conf and overlay-gateway.conf

thanks

[Zhongsan]

Hi, Karl

ok, next we will test the LC3 codec

thanks

[Zhongsan]

Hi, Karl

i have add a counter for bad frame, and after more than 9 hours testing, I got following information:

HL [09:08:46.645,050] <dbg> audio_datapath: audio_datapath_stream_out: Bad audio frame: 5437

the number looks a bit too much

thanks

[Karl Ylvisaker]

Hello again,

Could you describe the test setup and environment? What are between the two devices, and how is the RF noise in the environment?
5437 bad frames in the span of 9 hours equates to less than 0.0016 of frames being bad. Was there ever any audible artifacts caused by this?

Best regards,
Karl

[Zhongsan]

Hi，Karl

Sounds ok, no noticeable artifacts 

thanks

[Karl Ylvisaker]

Great, that is good news! :)
Then I suppose the dropped frames over that time is nothing to worry about - frames may be dropped unexpectedly from time to time due to RF noise or changes in the physical environment, but as long as it only happens as seldomly as it does in this case it should be no problem at all.
Thank you for sharing the test results with me nevertheless!

Please do not hesitate to open another ticket if you should encounter any other issues or questions in the future.

Good luck with your developing! :)

Best regards,
Karl