Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156667 - Accessing sound functions causes prolonged 100% CPU usage
Summary: Accessing sound functions causes prolonged 100% CPU usage
Alias: None
Product: Fedora
Classification: Fedora
Component: alsa-lib
Version: rawhide
Hardware: powerpc
OS: Linux
Target Milestone: ---
Assignee: Martin Stransky
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-03 01:05 UTC by Gabriel Schulhof
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-10-05 10:03:39 UTC

Attachments (Terms of Use)

Description Gabriel Schulhof 2005-05-03 01:05:45 UTC
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

How reproducible:

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.

Additional info:

Comment 1 Martin Stransky 2005-05-03 13:37:17 UTC
Could you test the new version? Is here:

Comment 2 Gabriel Schulhof 2005-05-03 22:38:11 UTC
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.

Comment 3 Martin Stransky 2005-05-04 08:32:52 UTC
Which process eats 100% of CPU time?

Comment 4 Gabriel Schulhof 2005-05-04 16:51:58 UTC
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
described above.

Comment 5 Martin Stransky 2005-05-06 07:43:42 UTC
could you please try alsa-lib-1.0.9rc2-4 from FC4?

Comment 6 Gabriel Schulhof 2005-05-06 21:27:18 UTC
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
3. Reboot
4. No effect.

BTW: My kernel is kernel-2.6.11-1.1286_FC4

Comment 7 Valdis Kletnieks 2005-05-09 14:39:53 UTC
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.

Comment 8 Martin Stransky 2005-05-09 15:27:56 UTC
Here ( 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:

pcm.!default { 
   type hw 
   card 0 
ctl.!default { 
   type hw 
   card 0 

Comment 9 Valdis Kletnieks 2005-05-09 15:40:55 UTC
1.0.9rc2-4.test still has the same issues for my machine.

Comment 10 Martin Stransky 2005-05-09 15:49:01 UTC
Which kernel do you have?

Comment 11 Valdis Kletnieks 2005-05-09 16:23:49 UTC
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....

Note You need to log in before you can comment on or make changes to this bug.