Repeatedly tries to open and close ALSA devices in background forever, causing disk to fill up with errors

[miiichael]

Expected behaviour

To not run out of diskspace due to ~/.xsession-errors growing at nearly 1Kbyte/sec:

Actual behaviour

~/.xsession-errors gains these message once per second:

ALSA lib confmisc.c:855:(parse_card) cannot find card '0'
ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_card_inum returned error: No such file or directory
ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings
ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1334:(snd_func_refer) error evaluating name
ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5703:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib control.c:1528:(snd_ctl_open_noupdate) Invalid CTL default

Steps to reproduce the behaviour

Use MATE in a VM (LXD container in my case) lacking sound hardware.

MATE general version

1.26.0 I guess?

Package version

1.26.0-1+deb12u1

Linux Distribution

Debian 12

Link to bugreport of your Distribution (requirement)

#942082

[lukefromdc]

This looks like it is an issue with ALSA itself, unless it occurs only in MATE. Note that when there is no sound card on bare metal, mate-media and the libmatemixer backend normally fall back to a "dummy" output so the applet doesn't crash and also can be tested.

If this is MATE-only, then something that should fall back to the dummy device is failing to do so. I have never worked in VMs and don't have any working machines with no or only removable sound right now, so I cannot work on this one myself.

Will leave fixing this for other team members that can duplicate it

[miiichael]

I should mention that I didn't have mate-media installed (because why would I, I have no audio hardware here! :P ). Not that it helps:

Also note that libasound2 is the only ALSA package I have installed. Installing alsa-utils also doesn't help, as there's still no audio hardware (fake or otherwise):

What creates this fake ALSA "dummy" device?

[lukefromdc]

The dummy device was added a long time ago (I forget where in the code) so that the volume control applet would not crash when no audio device is present. What devices are constantly trying to open? This is definately a bug, and not one I've had when no audio device was recognized on a certain laptop that had unsupported sound hardware. We need to find out if this is a MATE issue or an ALSA issue.

[miiichael]

Actually, after a bunch of wading through source code, I think the problem is actually here, where libmatemixer noisily searches for ALSA devices once per second. Also note that the ALSA backend always opens successfully, a strategy that I feel is based on incorrect assumptions. 😛

[lukefromdc]

Since we need to respond to added and removed sound devices, this looks like we need to ensure that the dummy device is only added once-or if that doesn't work, we need to disable logging its creation more than once. Replacing this with an event-driven loop would be best of all, but that's not something I am up to coding and would require a lot of testing before release or we get folks who cannot get their USB sound recognized.

[lukefromdc]

As a workaround, consider writing a script to delete~/.xsession-errors at intervals, or setting the file to read-only and owned by root so it cannot be written to. Revert this when you need to debug your session.

Also: on a machine with no sound device that is NOT going to be used with a USB/removable sound device, you could uninstall mate-media and libmatemixer, if necessary creating an empty dummy package version of them to satisfy any dependencies on them.

[lukefromdc]

I ran git blame on that code, the code underneath the comments dates to 2014 and I've had machines with no usable sound that didn't spam the logs.