Red Hat Bugzilla – Bug 156667
Accessing sound functions causes prolonged 100% CPU usage
Last modified: 2007-11-30 17:11:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.7.7-2
Description of problem:
- When logging in, there's a prolonged period of 100% user CPU activity before the splash screen shows up
- When right-clicking the volume control to "Open Volume Control" the same period of intense CPU activity ensues, followed by "No volume control elements and/or devices found."
- When gaim tries to make a sound for the first time, before it does so, the same period of 100% user CPU usage ensues.
I had gnomemeeting working perfectly on this iBook G4 before, but now the mic doesn't work and I cannot access the mixer to make the mic work again.
This happens with both the snd_powermac and dmasound_pmac drivers.
Version-Release number of selected component (if applicable):
alsa-lib-1.0.9rc2-1 , kernel-2.6.11-1.1276_FC4
Steps to Reproduce:
1. Log in
2. Right-click on the volume control applet and choose "Open Volume Control"
3. Watch the CPU go on a 100% user binge followed by a message box indicating that there are no volume control elements and/or devices.
Actual Results: Step 3 as described above.
Expected Results: The volume control should've opened promptly, and I should've been able to adjust the various volume controls.
Could you test the new version? Is here:
Since there was no .ppc.rpm on your Web site, I grabbed the .src.rpm and rebuilt
it. I upgraded alsa-lib and alsa-lib-devel from the binary RPM, but sound
continues to be broken in the above-described fashion, even after a reboot.
Which process eats 100% of CPU time?
When I right-click on the volume applet and click "Open Volume Control", the
process using 100% CPU is "gnome-volume-control".
When gaim has to make a sound after having made no sounds for a long time or
when making the first sound after launch, /it/ becomes the process using 100% CPU.
Also, when I log in, normally the FC splash screen comes up almost immediately
after the gdm login screen disappears. Not so since this problem surfaced,
though! Now, there's a break before the splash screen appears, a break whose
length is about the same as the 100% CPU periods present in the 2 situations
could you please try alsa-lib-1.0.9rc2-4 from FC4?
1. rpm -e --nodeps alsa-lib alsa-lib-devel
2. rpm -ivh alsa-lib-1.0.9rc2-4.ppc.rpm alsa-lib-devel-1.0.9rc2-4.ppc.rpm
4. No effect.
BTW: My kernel is kernel-2.6.11-1.1286_FC4
This may not be a powerPC-only issue. I'm seeing similar issue(s) on a Dell
Latitude C840 laptop - the alsa 1.0.6 that's in Core 3 Updates works fine,
1.0.9rc2-4 from the devel tree breaks stuff as follows:
1) xmms talking directly to alsa tends to just "hang" (usually at the end of a
song, but sometimes in the middle). 'ps ax' reports the status as 'SLsl'. After
some small amount of time (anywhere from 5 secs to a minute), it goes into a
100% CPU loop, with a high (60%+ system component). Smells like a thread
locking/mutex issue, but I haven't been able to prove it yet.
2) 'esd' and everything piped through it sounds fine with 1.0.6, but with 1.0.9
the sound is broken up - there's a repeated transient "click" at about 10-20Hz,
and the sound comes out sounding like it's gone through a ring modulator.
Here (http://people.redhat.com/stransky/alsa-test/) is a new test
version, please try it, I removed the patch for mixer.
Also remove the ~/.asoundrc file (if you have it) and create
/etc/asound.conf file with this content:
1.0.9rc2-4.test still has the same issues for my machine.
Which kernel do you have?
I am currently on 2.6.12-rc3-mm3, but could give the Fedora -1287
kernel a try if there is a reason to suspect that there exists some
Fedora patch that makes a difference. A look in the 1287 src.rpm
fails to show any patches in the alsa sound tree that should make any
difference on my system....