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

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

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)
Name of the topology file
- Topology: ? (I don't know how to get that)
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!

@fxthomas

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'?

@fxthomas

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.

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.

@fxthomas

@fxthomas Would you please dump the codec registers?

dump registers when beep sound happened
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?

@fxthomas

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 ?

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

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 ?

@jwrdegoede

@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 😉

@fxthomas

@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

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.

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.

After I stepped upon this bug, put intel_idle.max_cstate=2 and disabled intel_iommu. Still testing but even without sof.debug=1 no sound freezes yet.
This is all with latest 6.2-rc1 kernel and 2.2.3 SOF.

@Friptick

@Friptick Thanks a lot, adding the line options snd-intel-dspcfg dsp_driver=2 at the end of my /etc/modprobe.d/alsa-base.conf file fixed the beep sound issue on my Asus Chromebook C301SA (Braswell CPU) with Xubuntu 22.10 🎉

Now trying what I understand is the last resort: options snd-intel-dspcfg dsp_driver=2. Will edit with update.

Update. No surprises, that fixed it.

I would like to add my expirience with this on intel-z3735 and xubuntu-2204. In alsa-base.conf i activated sof and debug but there was still buzz-sound. In qmplay2 I redirected sound to alsa instead of pulse, this way buzz was much shorter. Then in qmplay2 for video I activated ffmpeg with opengl instead of ffmpeg-vaapi with vulcan, and it seems that buzz-sound doesn't happen anymore.

Just to add my own experience, I had this buzzing problem on an Acer Aspire Switch 10 tablet (Intel Atom Z3745), even with fully updated Ubuntu 22.04.1.
Adding options snd-intel-dspcfg dsp_driver=2 to /etc/modprobe.d/alsa-base.conf made the sound stop working entirely (there were no output devices found), but adding options snd_sof sof_debug=1 instead seems to have fixed the issue.

@Friptick

I'd share my experience too. I had this problem on an Asus VivoBook E200HA (Intel Atom x5-Z8300) with fully updated Lubuntu 22.04 (kernel 5.19).
Adding options snd-intel-dspcfg dsp_driver=2 to /etc/modprobe.d/alsa-base.conf as @Friptick suggested solved my problem.

@Friptick

Adding options snd-intel-dspcfg dsp_driver=2 to /etc/modprobe.d/alsa-base.conf as @Friptick suggested solved my issue on CHUWI Hi10HQ64G with Ubuntu 22.04.2 LTS, Intel Atom x5-Z8350 too.

@Friptick

Adding options snd-intel-dspcfg dsp_driver=2 to /etc/modprobe.d/alsa-base.conf as @Friptick suggested solved my issue on CHUWI Hi10HQ64G with Ubuntu 22.04.2 LTS, Intel Atom x5-Z8350 too.

Right I believe that the SOF driver is never going to get fixed on this older devices. Fedora has stopped setting CONFIG_SND_INTEL_BYT_PREFER_SOF for a long long time already. I think we should just remove CONFIG_SND_INTEL_BYT_PREFER_SOF from the upstream kernel all together and have the kernel always default to SST (dsp_driver=2) on BYT + CHT hardware.

@plbossart what do you think, shall I submit a patch upstream dropping CONFIG_SND_INTEL_BYT_PREFER_SOF ?

@plbossart

@plbossart what do you think, shall I submit a patch upstream dropping CONFIG_SND_INTEL_BYT_PREFER_SOF ?

Yes, I agree @jwrdegoede, we've unfortunately dropped the ball on SOF+Baytrail.

This is still broken. I cannot get audio working properly on my Linx 1010b. Constant beep after 3 minutes. SST driver plays the audio in the wrong pitch and in slow motion. Debug mode does nothing. Setting the kernel parameters breaks the audio completely. "No Output Devices"

This is still broken. I cannot get audio working properly on my Linx 1010b. Constant beep after 3 minutes. SST driver plays the audio in the wrong pitch and in slow motion. Debug mode does nothing. Setting the kernel parameters breaks the audio completely. "No Output Devices"

This is a known issue, the fix is to not use SOF but use the old SST driver, that should work fine. Since SOF is known to be broken SST is also the default of the kernel.

This is still broken. I cannot get audio working properly on my Linx 1010b. Constant beep after 3 minutes. SST driver plays the audio in the wrong pitch and in slow motion. Debug mode does nothing. Setting the kernel parameters breaks the audio completely. "No Output Devices"

This is a known issue, the fix is to not use SOF but use the old SST driver, that should work fine. Since SOF is known to be broken SST is also the default of the kernel.

I'm using OpenSuse Tumbleweed with kernel 6.15.3 and SOF was the default driver.
But even with the SST driver, the audio is broken but in a different way. It plays the audio at half speed and so it's unusable.

I did manage to get it working, someone online suggested to try both the kernel parameters and setting the SOF driver to debug mode simultaneously. That seems to have worked. Setting one or the other does not work, I have to set both.

@yotoprules

@yotoprules, can I ask what kernel parameters you have added which appears to fix the problem?

@yotoprules, can I ask what kernel parameters you have added which appears to fix the problem?

intel_idle.max_cstate=2
intel_iommu=off

As well as adding options snd_sof sof_debug=1 to alsa-base.conf. if I add the kernel parameters without setting SOF to debug, I get no input or output devices (weirdly enough I still get a popping sound when changing volume using the physical volume buttons but no audio in anything else)

I encountered this issue on my Acer Chromebook 11 CB3-131 (gnawty) running on Antix/Debian 13.5 (trixie).

Adding options snd_sof sof_debug=1 to the conf file under modprobe.d worked when nothing else did.

I encountered this issue on my Acer Chromebook 11 CB3-131 (gnawty) running on Antix/Debian 13.5 (trixie).

Adding options snd_sof sof_debug=1 to the conf file under modprobe.d worked when nothing else did.

Hmm, this is just to enable the SOF firmware trace.

Navigation Menu

Repository navigation

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

103 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

plbossart commented on Feb 23, 2021

bardliao commented on Feb 24, 2021

fxthomas commented on Feb 24, 2021

shumingfan commented on Feb 25, 2021

jwrdegoede commented on Mar 9, 2021

lgirdwood commented on Mar 9, 2021

jwrdegoede commented on Mar 9, 2021

plbossart commented on Mar 9, 2021

fxthomas commented on Mar 9, 2021

plbossart commented on Mar 9, 2021

plbossart commented on Mar 9, 2021

fxthomas commented on Mar 9, 2021

103 remaining items

nrndda commented on Dec 27, 2022

laurentpayot commented on Dec 30, 2022

risky777 commented on Jan 9, 2023

MrAndeos commented on Jan 31, 2023

Mik3Rizzo commented on Mar 14, 2023

remrcll commented on Apr 15, 2023

jwrdegoede commented on Apr 15, 2023

plbossart commented on Apr 17, 2023

yotoprules commented on Jul 2, 2025

jwrdegoede commented on Jul 2, 2025

yotoprules commented on Jul 2, 2025

ujfalusi commented on Jul 2, 2025

yotoprules commented on Jul 2, 2025

Kovaelin commented on Jun 23, 2026

bardliao commented on Jun 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions