Public bug reported:
Steps to reproduce:
1. Open gnome-alsamixer
2. Open gnome-volume-control
3. Open alsamixer
Adjust PCM volume with text-mode alsamixer. The two channels get out of
sync very quickly.
Other example:
1. Open gnome-volume-control on an SMP system
2. Rapidly adjust PCM volume with the channels locked. The channels will
eventually loosen up or one will go to 0.
sudo sh -c "echo 0 > /sys/devices/system/cpu/cpu1/online"
This command actually fixes the GNOME volume control on one of my dual-
core systems (Intrepid/emu10k1). It is consistently reproducible and
directly related to that command. On the other system (Hardy custom
2.6.26/cmipci), the command seems to have no effect and the problem
remains.
Something is wrong with the locking or mutexing of the volume controls
in an underlying component of Ubuntu. For some people, that means even
rudimentary volume control with the keyboard is problematic.
Affected drivers:
- cmipci
- emu10k1
- possibly every audio driver
It happens on systems even with the 2nd cpu disabled, just a little
less.
The volume for the channels does not just shoot down to zero all the
time (possibly indicating a returned error). Sometimes it just goes
down by a little bit. So there is some sort of race condition problem.
Intrepid as of 7/24/2008 is affected.
I was not able to demonstrate any inconsistencies with the text-mode
alsamixer when GNOME or KDE was not open, but that does not mean the
race is not somewhere in the kernel either. Moving the volume controls
with keys is a lot less stressful on the drivers than using a smooth
slider or running apps that monitor the volume in real-time.
I have tried every fix I have seen, and none have fixed the problem.
Possibly related bugs:
- Bug 126333
>From my debugging, a zero is first being written to a volume channel for
some reason. I am not sure why or the source of it. Mixers then read
this zero and the mistake carries on from there.
I will attach some library call logs from my debugging, but I can not
say that they are reliable. "workinglog" is from adjusting it slowly up
and then slowly down in the text-mode alsamixer program with no desktop
environment loaded, only a TTY.
"brokenlog" shows what happens when I use my keyboard to do the same
thing. The volume is jumping down periodically or going to zero.
_snd_mixer_selem_set_volume s->str[0].vol[1] = 18
elem_write_volume s->str[0].vol[0] = 0
elem_write_volume s->str[0].vol[1] = 18
The second write command giving alsa a zero makes no sense, and
completely destroys the linearity of the adjustment. But I don't know
where it's coming from.
** Affects: ubuntu
Importance: Undecided
Status: New
** Tags: alsa applet cmipci control emu10k1 race volume
--
volume control races render control useless, worse on SMP
https://bugs.launchpad.net/bugs/252237
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
