1. Launch gnome-volume-control 2. Check that the master track's channels are locked 3. Change the volume quickly, the 2 channels will become unlocked (the 2 tracks end up with different volumes) I debugged this in gst-plugins-base's gstalsamixer.c: A quick succession of snd_mixer_selem_set_playback_volume and snd_mixer_selem_get_playback_volume will result in 2 slightly different results. I add those lines in gst_alsa_mixer_get_volume(): if (track->num_channels == 2 && volumes[0] != volumes[1])• ↦ printf ("volumes[0]: %d volumes[1]: %d\n",• ↦ ↦ volumes[0], volumes[1]);• And saw this after dragging the sliders for a while: volumes[0]: 31 volumes[1]: 21 etc.
Yes, I can reproduce it. But if the volume is locked why don't you use snd_mixer_selem_set_playback_volume_all instead of snd_mixer_selem_set_playback_volume?
Because we don't know that they're locked, it's a UI feature, which the backend (in this case the API used by the GStreamer mixer interface) doesn't know about.
We could check whether all the volumes are the same in gst_alsa_mixer_set_volume() and use snd_mixer_selem_set_playback_volume_all() if so...
Filed and attached a patch for GStreamer at: http://bugzilla.gnome.org/show_bug.cgi?id=486840
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Closing as WONTFIX.