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 != volumes)â€¢
â†¦ printf ("volumes: %d volumes: %d\n",â€¢
â†¦ â†¦ volumes, volumes);â€¢
And saw this after dragging the sliders for a while:
volumes: 31 volumes: 21
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
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
Filed and attached a patch for GStreamer at:
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
(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:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Closing as WONTFIX.