[BUG][BYT][CHT] Linux 5.11 Cherrytrail/rt5640 emits persistent beeping sound after a short while

[fxthomas]

I had this issue while trying to debug https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/530 on an HP Detachable x2 ultrabook, where we're trying to see if the SOF driver is somehow more stable than SST.

This issue happens with raw ALSA (neither Pipewire/Pulseaudio running) as well as with both PW/PA.

The following sequence reproduces the issue 100% of the time:

• Enable SOF with options snd-intel-dspcfg dsp_driver=3 on a 5.11 kernel
• Check that the SOF driver is actually used with dmesg | grep sof
• Play a relatively long sound file for a few minutes (aplay -D <device name> file.wav for example)
• After sometimes (usually 2-3 minutes, though not always), speakers/headphones stop playing anything and emit a loud persistent "beeeep" that doesn't stop

As far as I can tell the beep only goes away when starting (if running raw ALSA) or restarting (if already running) the Pipewire/Pulseaudio server, which restores proper playback until the next beep.

The default SST driver is stable for basic audio output in S16LE, despite issues in other areas.

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: v5.11-arch2 in testing
   • SOF: 1.6.1-1 (3dffc2ae on the Arch package source, sof-bin@b77c851)
2. Name of the topology file
   • Topology: ? (I don't know how to get that)
3. Name of the platform(s) on which the bug is observed.
   • Platform: Atom x5-Z8530 (Cherrytrail) / rt5640

Logs:

• There are no logs in dmesg at all
• Regarding sof-logger, is there a way for me to compile it without bringing up the whole toolchain?

I'm not familiar at all with SOF, so if this is the wrong place for a report do let me know!

[plbossart]

Thanks for reporting this @fxthomas

Nothing really comes to my mind as a possible issue and our good friend @jwrdegoede has played quite a bit with SOF on CherryTrail.

Do you have the ability to test with the latest SOF development kernel (branch topic/sof-dev)?

@bardliao anything on the RT5640 that could help explain a sustained 'beeep'?

[bardliao]

I guess it is something related to clock. @fxthomas Could you check is the "Platform Clock" widget always on the right state? I.e. It should be On in playback and Off after playback. You can cat the "Platform Clock" node in /sys/kernel/debug/asoc//dapm/. @oder-chiou @shumingfan FYI.

[fxthomas]

Thanks for the quick answers!

Do you have the ability to test with the latest SOF development kernel (branch topic/sof-dev)?

The one that's in https://github.com/thesofproject/linux/tree/topic/sof-dev? Never done a custom kernel build before, but the docs look clear enough. I'm compiling it right now.

You can cat the "Platform Clock" node in /sys/kernel/debug/asoc//dapm/.

It's in /sys/kernel/debug/asoc/sof-bytcht rt5640/dapm/Platform Clock for me. With the same kernel it's off before playback, on during playback and beeping, off after restarting the sound server ; will test again when I have the topic/sof-dev build running.

[shumingfan]

@fxthomas Would you please dump the codec registers?

1. dump registers when beep sound happened
2. dump registers when playing with the default SST driver

dump codec registers:
cat /sys/kernel/debug/regmap/i2c-10EC5640:00/registers

BTW, is it possible to measure the MCLK frequency on your side?

[jwrdegoede]

I've been testing SOF + BYT/CHT with pipewire instead of pulseaudio as audioserver this weekend and I did notice some instabilities where sound stopped playing (no beep though) until I stopped all audio-playback for a while and then tried again.

There were also some issues with pipewire not properly executing the UCM enable-seq for capture, so the capture pipeline was not working while the gnome-control-center sound-pane did try to use it (for the input vu-meter) so that might have been part of what I was seeing.

I switched back to SST to try and debug pipewire issues without also having SOF in play, during this I learned: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/866 that pipewire defaults to 24 bits (or maybe even 32 when advertised?) where pulseaudo will always pick s16_le as format if available.

@fxthomas did you specify e.g. "-Dhw:1" when testing with aplay ? Otherwise you are still going through the audio-server (through the alsa-plugin for the audio-server) I believe and then you may have been testing with pipewire. Also did you specify a format with the -f param to aplay ?

I wonder if the SOF CI is testing with 24 / 32 bits sample sizes on BYT/CHT and I wonder if the bigger sample size may be causing issues with e.g. the stack on the DSP, or just some things becoming slower enough to sometimes be a problem ?

[lgirdwood]

I wonder if the SOF CI is testing with 24 / 32 bits sample sizes on BYT/CHT and I wonder if the bigger sample size may be causing issues with e.g. the stack on the DSP, or just some things becoming slower enough to sometimes be a problem ?

Yes this will have impact on FW buffers and processing headroom. 24bit is on the CI test list for CHT, but it's likely not stressed like 16bit is (sinec it's the primary use case on the older HW). The CHT multi format test is here.

https://sof-ci.01.org/sofpr/PR3911/build8276/devicetest/?model=BYT_MB_NOCODEC&testcase=check-playback-all-formats

[jwrdegoede]

Yes this will have impact on FW buffers and processing headroom. 24bit is on the CI test list for CHT, but it's likely not stressed like 16bit is (sinec it's the primary use case on the older HW).

Ok, so that is what I expected, in that case it seems to me that it would be better if pipewire were to just use 16 bit formats on these device ? Also note that the SOF driver is even advertising 32 bit formats (S32_LE) I would not be surprised if pipewire actually picks that one.

If you agree that pipewire just using 16bit formats would be better, then the question becomes how we achieve this. I think that ideally the SOF driver should not advertise 24bit/32bit formats (on BYT/CHT) to userspace in that case. Or maybe have a module option to advertise these or not ?

[plbossart]

@jwrdegoede The SOF driver just reports what the topology defines, there is no hard-coded format. I would be surprised if there was any difference, the dai is already configured to support 24 bits.

[fxthomas]

@fxthomas did you specify e.g. "-Dhw:1" when testing with aplay ? Otherwise you are still going through the audio-server (through the alsa-plugin for the audio-server) I believe and then you may have been testing with pipewire.

Yes, I used -D sysdefault:CARD=bytcrrt5640 in SST (and the equivalent for SOF), and also made sure pipewire/pulse were not running (systemd sockets/services stopped and no processes running).

Also did you specify a format with the -f param to aplay ?

In the linked pipewire issue comment I noted the aplay command-lines I used for testing with the SST driver, and these included -f and a few other settings.

For a quick summary, the only two that worked in the SST driver were:

$ ffmpeg -i input.mp3 -f s16le -c:a pcm_s16le -ar 48000 -ac 2 test_s16le_48000.raw
$ aplay -D sysdefault:CARD=bytcrrt5640 -f s16_le -r 48000 -c 2 -v test_s16le_48000.raw
$ ffmpeg -i input.mp3 -f s32le -c:a pcm_s32le -ar 96000 -ac 2 test_s32le_96000.raw
$ aplay -D sysdefault:CARD=bytcrrt5640 -f s24_le -r 48000 -c 2 -v test_s32le_96000.raw

In the SOF driver, the beeping occurs after some time whether I use aplay or Pipewire or Pulse in any mode.

Also I said (famous last words!):

will test again when I have the topic/sof-dev build running.

...but while it boots just fine I'm having some trouble figuring out how to enable SOF in this build, because it is apparently not as simple as the default 5.11 kernel I'm running. I need to read the docs, I'm just a poor newcomer to that world 😉

[plbossart]

@fxthomas there is a kernel parameter to select SOF, by default SST is the default.

copy this to any file in /etc/modprobe.d/

options snd-intel-dspcfg dsp_driver=3

[plbossart]

alternatively there's also a build config
CONFIG_SND_INTEL_BYT_PREFER_SOF

but I am not sure if it's in our development version just yet.

[fxthomas]

options snd-intel-dspcfg dsp_driver=3

That's the one I used, it worked on the official 5.11 kernel but not on the SOF branch when I tried. I'm rebuilding the branch right now from scratch, let's see if I can make that work better.

CONFIG_SND_INTEL_BYT_PREFER_SOF

Looks like it's there in thesofproject/linux@3620c5394b8b. If I can't make it work with the module option I'll try this one next.