Audio codec malfunction

Hello community,
At the end of last week we encountered a malfunction in the audio driver of several Linaro kernels for the Dragonboard 410c. We use a Yocto build system with a Linaro 4.14 kernel for our Myon1 board (From keith & koep, snapdragon-410 SoM)
On our Myon1, one of the headphone channels (HEADPHONE_R) fails after about 3x switching between on-board and headset audio, both headphone channels are overlaid with a low-frequency square-wave signal, see oscilloscope pictures in the appendix.
Since the Myon1 is based on the Dragonboard DB410c and we still had a DB410c including an audio mezzanine board here, I tested various linaro debian releases on the DB410c to find out whether the audio problem was related to our Yocto build system. It has been shown that all linaro debian distributions greater or equal to 17.04 have the same audio problem!

releases.linaro.org/96boards/dragonboard410c/linaro/debian

table

The misconduct can be reliably reproduced as follows:

  1. DB410c with audio mezzanine board
  2. Speakers connected to SPKR
  3. Headset connected to audio jack
  4. linaro debian 17.04 http://releases.linaro.org/96boards/dragonboard410c/linaro/debian/17.04/linaro-stretch-alip-qcom-snapdragon-arm64-20170510-233.img.gz
  5. Kernel image http://releases.linaro.org/96boards/dragonboard410c/linaro/debian/17.04/boot-linaro-stretch-qcom-snapdragon-arm64-20170510-233.img.gz

If an audio file is played over the loudspeaker after booting the LXDE desktop, everything seems to be OK for now. If you now switch between headset audio and loudspeaker a few times via the audio mixer, the loudspeaker is suddenly turned fully in one direction and therefore becomes hot (see oscilloscope pictures).
Do you know where this problem originated from and is there a fix for it? We cannot use our hardware like this because we rely on OnBoard Audio (Class-D amplifier) ​​and the headset.

Thanks a lot
Manuel

Could you please check if you reproduce the issue with latest release:
http://releases.linaro.org/96boards/dragonboard410c/linaro/debian/20.02/

Hi Loic,
I’d try to test with the 20.02 release.

linaro-buster-alip-dragonboard-410c-660.img

  • On the root console, error messages are printed repeatedly until the DB410c reboots after some seconds
  • X doesn’t start.

linaro-buster-developer-dragonboard-410c-660.img

  • On the root console, error messages are printed repeatedly until the DB410c reboots after some seconds

root@linaro-developer:~# [ 57.300615] qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading mpss
[ 57.540882] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up
[ 57.565134] qcom-q6v5-mss 4080000.remoteproc: fatal error received: fs_device_efs_rmts.c:154:[8 ,917504, 1] EFS: rmts_get_buffer api failed
[ 57.578094] remoteproc remoteproc0: crash detected in 4080000.remoteproc: type fatal error
[ 57.589944] remoteproc remoteproc0: handling crash #19 in 4080000.remoteproc
[ 57.600351] remoteproc remoteproc0: recovering 4080000.remoteproc
[ 59.365656] remoteproc remoteproc0: stopped remote processor 4080000.remoteproc
[ 60.040611] qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading mpss
[ 60.325294] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up
[ 60.338063] qcom-q6v5-mss 4080000.remoteproc: fatal error received: fs_device_efs_rmts.c:154:[8 ,917504, 1] EFS: rmts_get_buffer api failed
[ 60.348453] remoteproc remoteproc0: crash detected in 4080000.remoteproc: type fatal error
[ 60.361538] remoteproc remoteproc0: handling crash #20 in 4080000.remoteproc
[ 60.371925] remoteproc remoteproc0: recovering 4080000.remoteproc
[ 62.136504] remoteproc remoteproc0: stopped remote processor 4080000.remoteproc

Sorry, didn’t read Important note(s) about this release:

A firmware/bootloader upgrade is required for this release, you must ensure you are using the most recent firmware version. If you install using the SD card method, then the bootloaders are flashed automatically, if you install with the fastboot images, then you need to install the latest bootloader package.

After updating the bootloader, both 20.02 rootfss and the 5.4.17 kernel are working quite good :slight_smile:
Even after switching the audio path via lxde gui for 30 times, the faulty state is no longer reached.

table2

I think the solution for my audio problem in our product is to upgrade the linaro kernel from 4.14.96 to 5.4.17

Thanks for pointing this out

Good to know!

Exact, except if you identify the right fix to backport, but the gap can be important, and 5.4 is the new supported kernel anyway.