Sound problems and CPU stepping

Hi,
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:

Quote:

---

================================================== ======================
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.

---

This seems to describe my problem, including the part about stopping and restarting the playback, but it doesn't say whether there's already a solution or not. Has anyone had this problem before, and does anyone know how to fix it?

Thanks in advance,
-Hunter2

Very interesting indeed.

What is your exact CPU model?

Code:

---

cat /proc/cpuinfo

---

It may be possible that your CPU (specially if it is a desktop CPU) has a somehow bad latency when swithching frequencies.

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

---

Which version of alsa are you using? On which distro?

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:

Quote:

---

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 xtpr

---

Quote:

---

Originally Posted by lsmod

usbhid
ohci_hcd
ehci_hcd
usbcore (used by usbhid, ohci_hcd, ehci_hcd)
wlan_scan_sta
ath_pci
ath_rate_sample (used by ath_pci)
wlan (used by wlan_scan_sta, ath_pci, ath_rate_sample
ath_hal (used by ath_pci, ath_rate_sample)
p4_clockmod *NOTE: WAS acpi_cpufreq
speedstep_lib (used by p4_clockmod) *And this wasn't here

---

Alright, well a random thought hit me again shortly before typing up this post, and I tried changing the CPUFreq driver to p4-clockmod instead of acpi_cpufreq, as you can see from the lsmod output. There seems to be no problems when using this setup, but it means I can't scale my CPU frequency below 2.30ghz, and I don't get voltage scaling. I'm not sure if it's a placebo thing or not, but I'm thinking I can feel my laptop running hotter now -_-'... So, if possible I'd like to get acpi_cpufreq working again, just for peace of mind - especially because I get a warning message when booting that either acpi_cpufreq or ICH-M drivers should be used instead of p4-clockmod with the CPU that's detected. Of course, as luck would have it, the ICH-M drivers don't work for some reason.

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.

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.

Quote:

---

Originally Posted by Hunter2

changing the CPUFreq driver to p4-clockmod instead of acpi_cpufreq, as you can see from the lsmod output. There seems to be no problems when using this setup, but it means I can't scale my CPU frequency below 2.30ghz, and I don't get voltage scaling.

---

But I guess "p4-clockmod" doesn't work as well on a laptop.

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

Quote:

---

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

---

I guess that might explain why my lowest clock speed is 2.3Ghz under p4-clockmod.. The acpi_cpufreq driver allowed me to run at only 2 steps, 1.60ghz and 3.06ghz. Perhaps the 1.60ghz was causing the problem somehow.

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:

Quote:

---

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)
(...)

---

So, it seems that acpi_cpufreq had the correct frequencies, and p4-clockmod doesn't - unless the CPU can scale its frequency down to an intermediate frequency without entering the Battery Optimized Mode. I wonder if the reason I see no effects with p4-clockmod is because it isn't actually changing the frequency?

Quote:

---

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.

---

Maybe ALSA has some code that breaks somewhere in the transition steps.. i.e. in this link (ACPI docs):
http://acpi.sourceforge.net/document...processor.html

Quote:

---

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".

---

Maybe ordinarily the kernel would prevent the C3 state from being used when ALSA is in use, but acpi_cpufreq forces it due to the transition?.. Really just talking out of my *ss here, but I can't think of much else. Anyway, will still give the upgrading/downgrading a shot when I get home.

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?..

Quote:

---

Originally Posted by Hunter2

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?..

---

I wouldn't think so. At least it doesn't on P4 desktop processors.

Quote:

---

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.

---

This is interesting. I guess you could try the "centrino_speedstep" driver just in case. They seem to imply that it works with mobile P4.

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.

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...

>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 so ;) Last 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?