Results 1 to 10 of 12
Thread: Sound problems and CPU stepping
|
Enjoy an ad free experience by logging in. Not a member yet? Register.
|
|
-
06-13-2006 #1
- Join Date
- May 2005
- Posts
- 22
Sound problems and CPU stepping
I'm trying to figure out some sound problems I've been having on my laptop. I noticed that every time my CPU usage went up too high, my sound would 'skip' ahead by several seconds - and apps outputting to ALSA's dmix would just lose sound capabilities altogether. At first I thought this might be a buffering problem, but increasing various buffer sizes (3 second buffer in xmms, dmix plugin buffer 65536, etc.), didn't make any difference.
Then, after brainstorming for a while about what could possibly happen due to increased CPU usage (increasing CPU usage caused skipping momentarily, then sound continued normally even with CPU usage still at 100%), I thought about CPU frequency stepping; I had the OnDemand governor enabled. After doing some experimenting with the userspace, powersave and performance governors, I determined that the problem occurrs when increasing CPU clock rate, and that decreasing clock rate has no effect.
I did some searching and found this link:
http://n-dimensional.de/projects/cpufreq/algorithms.txt
It mentions:
================================================== ======================
Case Study 7: Audio/Video Playback
==============================
I know for a fact that switching CPU clock frequency while playing
back audio or video causes the sound to skip on my system. There are
two possible explanations for this:
a) the switching takes so long that something gets out of sync
b) the playback software has calibrated some internal loops for one
clock frequency, and running with another frequency makes the
code skip
My test cases are
- xmms with alsa backend
- rhythmbox/gstreamer/alsa.
The alsa driver used is snd_intel8x0.
So the problem may even be in the alsa part, n
Stopping the playback and continuing playing (which internally closes
and re-opens the sound device) adapts the sound software to the new
clock frequency, so after that the sound runs smoothly.
Possible solutions:
- fix alsa, if the problem is there
- notify audio software of frequency switch
- make the software tolerant of CPU frequency
- avoid switching CPU frequency while audio playback is in progress
The fact that it is only the audio skipping while playing back video,
and not the video, indicates that the problem may be somewhere within
the alsa subsystem or hardware driver.
Thanks in advance,
-Hunter2
-
06-14-2006 #2
Very interesting indeed.
What is your exact CPU model?
Code:cat /proc/cpuinfo
I use CPU frequency scaling on a few of my machines and I know for a fact that I am not experiencing this problem, and never had.
Which kernel do you have?
Code:uname -a
"To express yourself in freedom, you must die to everything of yesterday. From the 'old', you derive security; from the 'new', you gain the flow."
-Bruce Lee
-
06-14-2006 #3
- Join Date
- May 2005
- Posts
- 22
Kernel: 2.6.16.17.s2 [s2=my latest build] #1 PREEMPT (date) i686
ALSA 1.0.11rc2 (alsa-lib, alsa-utils and alsa-oss compiled from source to match new kernel), using Slackware 10.2.
CPU:
cpu family: 15
model: 2
name: Mobile Intel Pentium 4 CPU 3.06GHz
stepping: 9
fdiv_bug, hlt_bug, f00f_bug, coma_bug: no
fpu: yes
fpu_exception: yes
cpuid level: 2
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse32 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtprOriginally Posted by lsmod
I also found this bug report a couple minutes ago, following my p4-clockmod discovery, about a *very* similar problem:
http://lists.debian.org/debian-kerne.../msg00301.html
Unfortunately, I'm using the same model of laptop as they are (Toshiba A70-TS1, don't know which specific make of A70 theirs is), with sound card: ATI IXP150 AC'97 PCI sound card, using Realtek ALC250 chip, and I think it's connected to an ATI IXP modem. Fortunately though, I can reboot, and in fact most apps will run fine if I close them and restart them (or kill ESD if that's what they're running through).
Really hoping you can help.
-
06-14-2006 #4
I don't quite get this "p4-clockmod" issue as I have a 2.6.16 kernel myself (with the latest Con Kolivas' patch, ck12), and alsa 1.0.11 (final, not rc2) as well.
Using the "p4-clockmod" driver I don't have this issue.
Originally Posted by Hunter2
Seems this guy here had the same issue with the "p4-clockmod" driver, and "fixed" it using a 2.6.15 kernel :
http://www.linuxforums.org/forum/per...scaling-2.html"To express yourself in freedom, you must die to everything of yesterday. From the 'old', you derive security; from the 'new', you gain the flow."
-Bruce Lee
-
06-15-2006 #5
- Join Date
- May 2005
- Posts
- 22
Also, take a look at this, it seems the 2GHz lower limit could be a "feature" of "p4-clockmod" :
(...)
333325 666650 999975 1333300 1666625 1999950 2333275 2666600
Anyway, I'll try both upgrading and downgrading my kernel, and upgrading ALSA again.
***EDIT***
I did a bit of snooping around, and leafed through Intel's datasheet for my CPU:
ftp://download.intel.com/design/mobi...s/25302804.pdf
I found a few things of interest:
The processor FSB uses GTL+ signalling technology. The mobile Intel Pentium 4 processor with
533 MHz FSB is expected to be available at the following core frequencies:
• 3.20 GHz (in Maximum Performance Mode at 1.55 V). This processor runs at 1.60 GHz (in
Battery Optimized Mode at 1.20 V
• 3.06 GHz (in Maximum Performance Mode at 1.55 V). This processor runs at 1.60 GHz (in
Battery Optimized Mode at 1.20 V)
(...)
The mobile Intel Pentium 4 processor, when used in conjunction with the requisite Intel SpeedStep
technology applet or its equivalent, supports Enhanced Intel SpeedStep technology. Enhanced Intel
SpeedStep technology allows the processor to switch between two core frequencies automatically
based on CPU demand, without having to reset the processor or change the FSB frequency. The
processor has two bus ratios and voltages programmed into it instead of one and the GHI# signal
controls which bus ratio and voltage is used. After reset, the processor will start in the lower of its
two core frequencies, the Battery Optimized mode. An operating mode transition to the high core
frequency can be made by setting GHI# low, putting the processor into the Deep Sleep state,
regulating to the new VID output, and returning to the Normal state. This puts the processor into
the high core frequency, or Maximum Performance mode. Going through these steps with GHI# set
high, transitions the processor back to the low core frequency operating mode. The processor will
drive the VID[4:0] pins with the VID of the current operating mode and the system logic is
required to regulate the core voltage within specification for the driven VID.
http://acpi.sourceforge.net/document...processor.html
When the system is quite idle, the ACPI system may want to put the CPU in the C3 sleep state. In this state the CPU cannot detect if a bus master changes anything or reads from the system memory. In the case when the CPU holds copies of this memory in its "write-back cache" or even in its "inbound" cache, the bus master might read wrong values. This leads to data corruption, and probably to an instable system, if not a "crash".
-
06-17-2006 #6
- Join Date
- May 2005
- Posts
- 22
Mmpf. Upgraded to kernel 2.6.16.20 and ALSA 1.0.11 final, no dice. I guess I'll work my way around to trying a downgraded kernel eventually.
As another random thought, do you think having low-latency config options in the kernel (i.e. 'pre-emptible kernel' and 'pre-empt the big kernel lock', high timer frequency) might have an effect?..
-
06-17-2006 #7
Originally Posted by Hunter2
The mobile Intel Pentium 4 processor, when used in conjunction with the requisite Intel SpeedStep technology applet or its equivalent, supports Enhanced Intel SpeedStep technology."To express yourself in freedom, you must die to everything of yesterday. From the 'old', you derive security; from the 'new', you gain the flow."
-Bruce Lee
-
06-17-2006 #8
- Join Date
- May 2005
- Posts
- 22
I tried the centrino_speedstep already, unfortunately it doesn't work either, even with relaxed speedstep checking enabled. And I'm now running on a new kernel build without the heavier kernel preemption options, doesn't seem to make a difference either.
-
06-18-2006 #9
I meant "speedstep_centrino" for the driver.
Well, did you try the new 2.6.17 kernel with "Con Kolivas" patches?
http://members.optusnet.com.au/ckolivas/kernel/
Or maybe the "beyond" patches? They uses the latest Alsa for it.
http://iphitus.loudas.com/beyond.html
Using the latest drivers is always the thing to do when having such problems.
Keep on updating about this issue..."To express yourself in freedom, you must die to everything of yesterday. From the 'old', you derive security; from the 'new', you gain the flow."
-Bruce Lee
-
06-18-2006 #10
- Join Date
- May 2005
- Posts
- 22
>I meant "speedstep_centrino" for the driver.
Oops, yeah. That's the one I tried
>Well, did you try the new 2.6.17 kernel with "Con Kolivas" patches?
Frustrating how my kernel version goes out of date every couple days or soLast I checked, 2.6.17 wasn't final yet. I'll give it a shot, doing a quick search through the changelog shows oodles of CPUfreq and ACPI changes, maybe something will give.
I'm a little confused about the CK patches; it's always stated, 'apply to 2.6.x kernel, not 2.6.x.y'. Then are the latest official kernel updates (the .y minor revisions) already incorporated into each CK patch? Also, why aren't the CK patches incorporated into the kernel already?