Comment 60 for bug 126333

lomion: I appreciate your interest in it. I opened a new report here. I have spent longer but still no idea what the issue is. But I suspect very much it is a race condition between different mixers or applications reading the mixer.

See Bug 252237

gnome-settings-daemon controls the keyboard volume keys, and is affected severely sometimes (I don't know what circumstances affect 'sometimes').

gnome-alsamixer seems not to mess its own GUI up like the other programs, but it quickly messes up at least when text-mode alsamixer is open.

gnome-volume-control is the normal GNOME mixer GUI and its most common symptom is random muting, and jumping to 0 without notice. It loses control of both channels quickly sometimes when they are locked, and starts adjusting them independently/incorrectly.

alsamixer, when run only in a TTY with no desktop environment, seems to have no issues. When run under GNOME or KDE, it can experience problems.

Disabling the second CPU on one of my computers fixes the problem for that computer, with gnome-volume-control. (Opening three mixer apps concurrently still shows a problem.) Disabling the second CPU on the other computer doesn't fix the problem with gnome-volume-control ONLY open.

So, I can only assume this is some sort of condition in which two applications (maybe hidden desktop environment daemons) or threads are reading from the volume at the same time, one is failing a read, getting a zero and writing it back somehow. But I am not sure. A kernel/sound developer that knows how to properly debug it really needs to look at the problem because laypeople shouldn't have to reverse engineer the several layers of abstraction that go into the sound system. I hope to get the proper people involved to see what's going on but this seems to affect many users and configurations. I don't feel I can do any more at this point in terms of adding hooks and debugs and printfs in the code of gstreamer,alsa and gnome-volume-control as it has proven futile.

I traced some library calls by recompiling the source packages and incorporating code to save the pertinent calls to a file. ltrace wasn't too reliable.

I tried tracing some calls within and/or looking at the following files from the following source packages for Ubuntu Hardy 8.04.1.

gnome-media: gst-mixer/src/volume.c
gstreamer-0.10-plugins-base: ext/alsa/gstalsamixer.c
alsa-lib: src/mixer/simple.c
alsa-lib: src/mixer/simple_none.c
alsa-lib: src/mixer/mixer.c
gnome-applets: mixer/applet.c
gnome-settings-daemon: plugins/media-keys/actions/acme-volume.c

And tried disabling pulseaudio. The gnome-settings-daemon keyboard controls were also disabled temporarily for a test but this didn't help.

No closure has been reached by me yet on what the real problem is. A couple proposed patches for the problem (a patch for cards with similar capture/playback volume controls [15_alsa_p_c_volume.patch] or [gnome-applets-2.20.0-mixer-out-of-sync.patch]) were either applied already or had no effect on the issue that I could tell. It's possible I made an error in testing like not rebooting, doing ldconfig or letting the apps reload the new libraries.