amixer settings are no longer respected?
- PipeWire version (
pipewire --version
):
pipewire
Compiled with libpipewire 0.3.65
Linked with libpipewire 0.3.65
- Distribution and distribution version (
PRETTY_NAME
from/etc/os-release
):Debian GNU/Linux 12 (bookworm)
- Desktop Environment: KDE, but the issue can be reproduced without Desktop Environment
- Kernel version (
uname -r
):locally built6.1.39-1-stable
Description of Problem:
I'm not sure what is the best way to describe our need and the issue we are facing, so sorry that the title is not very clear.
We (Radxa) are a single board computer manufacturer mostly focus on ARM64 devices, as such, we also provide per-configured system images for our products with working audio.
Previously with Debian 11, PipeWire was not officially supported, so we stayed with PulseAudio. One issue we had back then was that we were getting spammed with fe.dai-link-0: ASoC: no backend DAIs enabled for fe.dai-link-0
error in our serial console and kmsg. The cause was said to be missing mixer settings, so we include the suggested LibreELEC soundconfig
and the associated udev
rule, and all is good. We no longer saw those annoying error messages.
With Debian 12, PipeWire is now officially supported, so we gave it a try. This time, we are getting error messages for fe.dai-link-1
and fe.dai-link-2
instead. Indeed, fe.dai-link-0
was recognized by PipeWire and WirePlumber, with "alsa.id": "fe.dai-link-0 (*)"
defined in Node 43 of the attached pw-dump.log
below. However, the other 2 devices are missing. Which makes sense, since they are not connected to any real output, but that also means there is no way for us to configure it within PipeWire ecosystem, if the error is again caused by missing mixer settings.
I played around in KDE and enabled Pro Audio. This indeed showed 3 sinks in wpctl status
. However, examining the properties showed that the other 2 sinks does not have alsa.id
defined, so I was still getting the error spam.
I also reinstalled PulseAudio with PipeWire entirely removed. This reverted the behavior back to that of Debian 11: no error spam.
Finally, as a sanity check, I also installed Armbian image (this is another popular ARM64 Debian based distro) to rule out misconfiguration on our part. With the following steps I was able to reproduce it. Although for Armbian they don't print the kmsg to console, so it is only viewable in dmesg
. Nonetheless, a misconfiguration exists on their system as well.
One thing I noticed was that on our CLI system, we did not include dbus-user-session
package, so when pipewire-audio
is installed the bug won't be triggered. Not sure if this info helps.
How Reproducible:
100%
Steps to Reproduce:
- Install
pipewire-audio
anddbus-user-session
on Armbian Debian 12 CLI - Log in
Actual Results:
kmsg and serial console are getting spammed with following error messages:
[ 19.429677] fe.dai-link-1: ASoC: no backend DAIs enabled for fe.dai-link-1
[ 19.429677] fe.dai-link-1: ASoC: no backend DAIs enabled for fe.dai-link-1
[ 19.443121] fe.dai-link-1: ASoC: error at dpcm_fe_dai_prepare on fe.dai-link-1: -22
[ 19.443121] fe.dai-link-1: ASoC: error at dpcm_fe_dai_prepare on fe.dai-link-1: -22
[ 19.459688] fe.dai-link-2: ASoC: no backend DAIs enabled for fe.dai-link-2
[ 19.459688] fe.dai-link-2: ASoC: no backend DAIs enabled for fe.dai-link-2
[ 19.472423] fe.dai-link-2: ASoC: error at dpcm_fe_dai_prepare on fe.dai-link-2: -22
[ 19.472423] fe.dai-link-2: ASoC: error at dpcm_fe_dai_prepare on fe.dai-link-2: -22
Expected Results:
No error messages.
Additional Info (as attachments):
-
pw-dump > pw-dump.log
: pw-dump.log
radxa@radxa-zero2:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: RADXAZERO2 [RADXA-ZERO2], device 0: fe.dai-link-0 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: RADXAZERO2 [RADXA-ZERO2], device 1: fe.dai-link-1 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: RADXAZERO2 [RADXA-ZERO2], device 2: fe.dai-link-2 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0