| 2008-07-27 03:32:23 |
xtknight |
bug |
|
|
added bug |
| 2008-07-27 03:39:42 |
xtknight |
description |
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 |
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. |
|
| 2008-07-27 03:41:03 |
xtknight |
bug |
|
|
added attachment 'brokenlogs.tar.gz' (brokenlogs.tar.gz) |
| 2008-07-27 03:41:41 |
xtknight |
bug |
|
|
added attachment 'workinglogs.tar.gz' (workinglogs.tar.gz) |
| 2008-07-27 03:43:24 |
xtknight |
description |
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. |
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down teh line in the sound system. |
|
| 2008-07-27 03:44:19 |
xtknight |
description |
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down teh line in the sound system. |
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down teh line in the sound system. |
|
| 2008-07-27 04:14:49 |
xtknight |
description |
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down teh line in the sound system. |
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. |
|
| 2008-07-27 04:16:24 |
xtknight |
description |
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. |
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
|
| 2008-07-28 02:57:56 |
xtknight |
description |
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
Primary example (only GNOME affected)
1. Open gnome-volume-control
2. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
|
| 2008-07-28 02:57:56 |
xtknight |
title |
volume control races render control useless, worse on SMP |
[gnome] normal volume control useless, various races |
|
| 2008-07-28 02:59:01 |
xtknight |
description |
Primary example (only GNOME affected)
1. Open gnome-volume-control
2. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
Primary example (only GNOME affected)
1. Open gnome-volume-control
2. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
|
| 2008-07-28 03:00:40 |
xtknight |
description |
Primary example (only GNOME affected)
1. Open gnome-volume-control
2. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
Primary example (only GNOME affected)
1. Open gnome-volume-control
2. option a. Use keyboard to control volume. It is immediately messed up and the progress bar on the volume control disappears. You can see with alsamixer that one channel is randomly muted now and then.
2. option b. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
|
| 2008-07-28 03:01:23 |
xtknight |
title |
[gnome] normal volume control useless, various races |
[gnome] normal volume control useless, various race conditions |
|
| 2008-07-28 08:00:22 |
Sebastien Bacher |
gst-plugins-base0.10: status |
New |
Incomplete |
|
| 2008-07-28 08:00:22 |
Sebastien Bacher |
gst-plugins-base0.10: importance |
Undecided |
Low |
|
| 2008-07-28 09:14:05 |
xtknight |
gst-plugins-base0.10: status |
Incomplete |
New |
|
| 2008-07-28 09:14:18 |
xtknight |
gst-plugins-base0.10: status |
New |
Incomplete |
|
| 2008-08-01 23:56:39 |
xtknight |
gst-plugins-base0.10: status |
Incomplete |
New |
|
| 2008-08-01 23:56:54 |
xtknight |
bug |
|
|
assigned to gst-plugins-base |
| 2008-08-02 01:12:44 |
xtknight |
bug |
|
|
added attachment 'gst-plugins-base0.10_0.10.18-3ubuntu1.debdiff' (hardy patch) |
| 2008-08-02 01:21:53 |
xtknight |
description |
Primary example (only GNOME affected)
1. Open gnome-volume-control
2. option a. Use keyboard to control volume. It is immediately messed up and the progress bar on the volume control disappears. You can see with alsamixer that one channel is randomly muted now and then.
2. option b. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
Primary example (only GNOME affected, focus of this bug, prelim. patch for it below)
1. Open gnome-volume-control
2. option a. Use keyboard to control volume. It is immediately messed up and the progress bar on the volume control disappears. You can see with alsamixer that one channel is randomly muted now and then.
2. option b. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
|
| 2008-08-02 01:21:53 |
xtknight |
title |
[gnome] normal volume control useless, various race conditions |
gstreamer alsa mixer renders gnome volume controls useless |
|
| 2008-08-02 03:34:47 |
Bug Watch Updater |
gst-plugins-base: status |
Unknown |
New |
|
| 2008-08-02 09:17:51 |
Sebastien Bacher |
gst-plugins-base0.10: status |
New |
Triaged |
|
| 2008-11-21 20:32:09 |
xtknight |
bug |
|
|
added attachment 'gst-plugins-base0.10_0.10.21-3ubuntu1.debdiff' (intrepid fix) |
| 2008-11-23 08:45:06 |
xtknight |
bug |
|
|
added subscriber Ubuntu Sponsors for main |
| 2008-12-23 06:45:25 |
xtknight |
description |
Primary example (only GNOME affected, focus of this bug, prelim. patch for it below)
1. Open gnome-volume-control
2. option a. Use keyboard to control volume. It is immediately messed up and the progress bar on the volume control disappears. You can see with alsamixer that one channel is randomly muted now and then.
2. option b. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
SRU Info
1. This bug is persistent and annoying because users cannot control the volume without it randomly going to zero. They may be unable to use their keyboard volume controls and/or the display for the volume popup that appears through gnome-settings-daemon may appear incorrect.
2. It hasn't been addressed upstream yet, but was reported a while ago.
3. Patch is available below.
4. Not everyone can reproduce it; that's why it's tricky. The bug is sneaky. For a lot of us, simply using the keyboard volume controls will reveal a blank volume popup and not the actual volume. Or, adjusting the volume slider in the mixer will uncover the problem in a very short time.
TEST CASE:
-open gnome-volume-control
-Adjust master or PCM mixers with the left/right channels locked. Watch the sliders desynchronize as you move at a slow speed or really fast speed.
-OR-
-use keyboard volume controls and observe that the volume popup reports incorrect or no volume-
5. I could not see possible regressions. This patch reverts a commit which seemed to make controlling volume an asynchronous operation or something of the matter, but introduced issues with multiprocessor CPUs. It used to work fine for everyone (to my knowledge) before the commit. So really, a regression is being reversed. I wasn't able to pinpoint exactly why that commit was added in to the gstreamer code.
---------------------------------------------------------------------------------------------------------
Primary example (only GNOME affected, focus of this bug, prelim. patch for it below)
1. Open gnome-volume-control
2. option a. Use keyboard to control volume. It is immediately messed up and the progress bar on the volume control disappears. You can see with alsamixer that one channel is randomly muted now and then.
2. option b. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
|
| 2008-12-23 06:47:46 |
xtknight |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2008-12-23 06:50:27 |
xtknight |
description |
SRU Info
1. This bug is persistent and annoying because users cannot control the volume without it randomly going to zero. They may be unable to use their keyboard volume controls and/or the display for the volume popup that appears through gnome-settings-daemon may appear incorrect.
2. It hasn't been addressed upstream yet, but was reported a while ago.
3. Patch is available below.
4. Not everyone can reproduce it; that's why it's tricky. The bug is sneaky. For a lot of us, simply using the keyboard volume controls will reveal a blank volume popup and not the actual volume. Or, adjusting the volume slider in the mixer will uncover the problem in a very short time.
TEST CASE:
-open gnome-volume-control
-Adjust master or PCM mixers with the left/right channels locked. Watch the sliders desynchronize as you move at a slow speed or really fast speed.
-OR-
-use keyboard volume controls and observe that the volume popup reports incorrect or no volume-
5. I could not see possible regressions. This patch reverts a commit which seemed to make controlling volume an asynchronous operation or something of the matter, but introduced issues with multiprocessor CPUs. It used to work fine for everyone (to my knowledge) before the commit. So really, a regression is being reversed. I wasn't able to pinpoint exactly why that commit was added in to the gstreamer code.
---------------------------------------------------------------------------------------------------------
Primary example (only GNOME affected, focus of this bug, prelim. patch for it below)
1. Open gnome-volume-control
2. option a. Use keyboard to control volume. It is immediately messed up and the progress bar on the volume control disappears. You can see with alsamixer that one channel is randomly muted now and then.
2. option b. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
SRU Info
1. This bug is persistent and annoying because users cannot control the volume without it randomly going to zero. They may be unable to use their keyboard volume controls and/or the display for the volume popup that appears through gnome-settings-daemon may appear incorrect.
2. It hasn't been addressed upstream yet, but was reported a while ago.
3. Patch is available below.
4. Not everyone can reproduce it; that's why it's tricky. The bug is sneaky. For a lot of us, simply using the keyboard volume controls will reveal a blank volume popup and not the actual volume. Or, adjusting the volume slider in the mixer will uncover the problem in a very short time.
TEST CASE:
-open gnome-volume-control
-Adjust master or PCM mixers with the left/right channels locked. Watch the sliders desynchronize as you move at a slow speed or really fast speed.
-OR-
-use keyboard volume controls and observe that the volume popup reports incorrect or no volume-
5. I could not see possible regressions. This patch reverts a commit which seemed to make controlling volume an asynchronous operation or something of the matter, but introduced issues on many systems. It used to work fine for everyone (to my knowledge) before the commit. So really, a regression is being reversed. I wasn't able to pinpoint exactly why that commit was added in to the gstreamer code.
---------------------------------------------------------------------------------------------------------
Primary example (only GNOME affected, focus of this bug, prelim. patch for it below)
1. Open gnome-volume-control
2. option a. Use keyboard to control volume. It is immediately messed up and the progress bar on the volume control disappears. You can see with alsamixer that one channel is randomly muted now and then.
2. option b. Rapidly adjust PCM volume with the channels locked. The channels will eventually loosen up or one will go to 0.
GNOME without pulseaudio and without software mixing still has the problem. The problem seems DIRECTLY related to GNOME, but it's also possible this bug is similar to the one below. The first problem is MUCH worse and ruins daily, practical use of the OS. The second is an observation and not intended to be the focal point of this bug report. I didn't see random muting with the second bug (that I can remember) but I saw a ton with the first.
--------------------------
Secondary example (all desktops):
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.
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
The second example happens on systems even with the 2nd cpu disabled, just a little less. With the first example it doesn't seem to matter.
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. "workinglogs" is from adjusting it slowly up and then slowly down in the text-mode alsamixer program with no desktop environment loaded, only a TTY.
"brokenlogs" 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. I don't know if it's adjusting the same track number even or if it is the cause of the problem, but it seems to correlate.
Each log file (mylogn) in the archives is tracking a different part of the sound control subsystem. mylog5 is the lowest level and mylog1/mylog2(gstreamer) are the highest. text-mode didn't use mylog1/mylog2, only 3-5 which are farther down the line in the sound system.
Both machines were dual-core Intel Core 2 running x86_64 architecture Ubuntu with 4GB of RAM. All tracing was done on the first system (cmipci). |
|
| 2009-02-22 09:13:44 |
xtknight |
bug |
|
|
added attachment 'gst-plugins-base0.10_0.10.22-1ubuntu1.debdiff' (debdiff for gst-plugins-base commit fc23037a9aaf0beca99f9494948b2fb1169a03db backport) |
| 2009-02-22 09:15:24 |
xtknight |
bug |
|
|
added subscriber Ubuntu Sponsors for main |
| 2009-02-26 21:36:20 |
Sebastien Bacher |
gst-plugins-base0.10: status |
Triaged |
Fix Released |
|
| 2009-02-26 21:36:20 |
Sebastien Bacher |
gst-plugins-base0.10: statusexplanation |
|
gst-plugins-base0.10 (0.10.22-3) unstable; urgency=low
* debian/patches/01_alsamixer-race-condition.patch:
+ Fix race condition in alsamixer which made the volume controls
useless in many situations (Closes: #514685).
Patch from upstream GIT.
|
|
| 2009-08-27 07:40:21 |
xtknight |
gst-plugins-base: importance |
Unknown |
Undecided |
|
| 2009-08-27 07:40:21 |
xtknight |
gst-plugins-base: remote watch |
GNOME Bug Tracker #545932 |
|
|
| 2009-08-27 07:40:33 |
xtknight |
gst-plugins-base: status |
New |
Fix Released |
|
