Bug 156667 - Accessing sound functions causes prolonged 100% CPU usage
Accessing sound functions causes prolonged 100% CPU usage
Product: Fedora
Classification: Fedora
Component: alsa-lib (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Stransky
Depends On:
  Show dependency treegraph
Reported: 2005-05-02 21:05 EDT by Gabriel Schulhof
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-05 06:03:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gabriel Schulhof 2005-05-02 21:05:45 EDT
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 09:37:17 EDT
Could you test the new version? Is here:

Comment 2 Gabriel Schulhof 2005-05-03 18:38:11 EDT
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 04:32:52 EDT
Which process eats 100% of CPU time?
Comment 4 Gabriel Schulhof 2005-05-04 12:51:58 EDT
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 03:43:42 EDT
could you please try alsa-lib-1.0.9rc2-4 from FC4?
Comment 6 Gabriel Schulhof 2005-05-06 17:27:18 EDT
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 10:39:53 EDT
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 11:27:56 EDT
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:

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

Comment 9 Valdis Kletnieks 2005-05-09 11:40:55 EDT
1.0.9rc2-4.test still has the same issues for my machine.
Comment 10 Martin Stransky 2005-05-09 11:49:01 EDT
Which kernel do you have?
Comment 11 Valdis Kletnieks 2005-05-09 12:23:49 EDT
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.