New sound problems

MNT Reform
1

Mysterious new sound behavior on my MNT Reform classic!

Currently, gnome is “stuck” on Analog Output - Built-in Audio selection. It still shows Speakers - Built-in Audio and Headphones - Built-in Audio as available, and I can click on them, but the selection never changes from the Analog Output option, and no sound is coming from either the built in speakers or the headphone jack. I CAN use a bluetooth dongle and speaker or headphones with zero issues.

This coincided with the upgrade to kernel 6.17.11-1+reform20251126T085426Z, but it may have nothing to do with that, specifically.

I am not seeing anything particularly weird in the output of things like aplay -l, pw-dump, or under /proc/asound. Output from dmesg has a bunch of this:

[   37.451884] hdmi-audio-codec hdmi-audio-codec.6.auto: HDMI: Unknown ELD version 0

which could be related? I don’t have an external monitor connected, and I’ve got an RCORE-DSI module, which I don’t think uses HDMI.

Also probably not related, dmesg is showing this, which seems new, but I could have just not noticed it before

[   67.030228] panthor fb000000.gpu: [drm] *ERROR* Unhandled Page fault in AS2 at VA 0x0000800000015040
               raw fault status: 0x7CD002C3
               decoded fault status: SLAVE FAULT
               exception type 0xC3: TRANSLATION_FAULT_3
               access type 0x2: READ
               source id 0x7CD0

One more thing in dmesg, which seems more likely to be relevant, since I believe this is referencing the wm8960 audio system of the rk3588:

$ sudo dmesg | grep wm8960
[   23.094014] wm8960 6-001a: supply DCVDD not found, using dummy regulator
[   23.107795] wm8960 6-001a: supply DBVDD not found, using dummy regulator
[   23.113794] wm8960 6-001a: supply AVDD not found, using dummy regulator
[   23.116255] wm8960 6-001a: supply SPKVDD1 not found, using dummy regulator
[   23.118284] wm8960 6-001a: supply SPKVDD2 not found, using dummy regulator

Any ideas? reform-check shows no issues (just [I] output).

2

So, this appears to be “standard” pipewire brittleness.

I have a workaround – when I first log in, I have three pipewire processes running:

/usr/bin/pipewire
/usr/bin/pipewire -c filter-chain.conf
/usr/bin/pipewire-pulse

If I kill the first one (/usr/bin/pipewire) both it and the -c filter-chain.conf processes exit, and are respawned by systemd (as part of what I guess is called the “user slice”). This respawned instance does not include the -c filter-chain.conf process, and functions normally.

Killing the -c filter-chain.conf process does not fix things, it has to be the parent process.

I don’t know enough about pipewire to know why this is happening, but I’ll keep poking at it. It feels like some kind of initialization order/access issue – like maybe the pipewire process is inherited from the gdm3 process and can’t be configured by the user process? I’ll see what I can figure out.

3

Unfortunately I cannot tell you much about pipewire either but when I am facing this sort of issues I usually first try to figure out whether the problem is due to my local configuration or because some software changed. You can either do this by flashing a fresh system image to an sd-card, boot that and see if you still have the sound issues (this is the sledgehammer method as it gives you a completely clean slate). Or, less intrusive, you find out which directories in your $HOME contain the pipewire configuration and state (probably in ~/.config and ~/.cache and maybe even in ~/.local/share?) and then you move these directories elsewhere. Next time you boot, pipewire will start with a vanilla configuration. If the audio problems are gone, then it was your config and then you can diff the configuration in your backup config directories against the one in the new vanilla directories. If the issue still persists even with a clean slate, then it must’ve indeed been a package upgrade issue and then you can file a bug either in the Debian BTS (preferred) or against pipewire upstream if you know what you are doing (i do not). Good luck!

1 Like
4

You have an RK3588 classic Reform?

I just tried this (flashed fresh system image from MNT gitlab CI on sd-card) on an RK3588 classic Reform and the gnome output selection properly selects between speakers and headphones. Both settings work as expected.

1 Like
5

I had this problem once and it fixed itself by upgrading pipewire, wireplumber, pipewire-pulse etc packages. Did you already try that?

1 Like
6

I do already have things upgraded to most current, including those packages.

Deleting the various state files seems to have helped fix things, but I’m not convinced I have it actually working normally. It feels pretty clear that this is a “local” problem, though, not caused by a simple upgrade. It’s possible it’s a replicatable bug, but my guess is it’s some corner case of behavior or software versions.

7

Nope, still showing the same behavior. :stuck_out_tongue:

8

Aha!

dpkg-reconfigure on pipewire, pipewire-bin, pipewire-alsa, pipewire-pulse, and wireplumber seems to have fixed it for real.

Thanks for rubber-ducking this with me!

9

I spoke too soon! The behavior persists!

Additional troubleshooting – when I first boot, I can modify the inputs manually. First login, nope, stuck. On one occasion, they were not even visible. Logging out and logging back in, now they work as expected!

Debugging continues apace!