Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 12
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2005
    Posts
    22

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

  2. #2
    Linux Guru antidrugue's Avatar
    Join Date
    Oct 2005
    Location
    Montreal, Canada
    Posts
    3,211
    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?
    "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

  3. #3
    Just Joined!
    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 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.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru antidrugue's Avatar
    Join Date
    Oct 2005
    Location
    Montreal, Canada
    Posts
    3,211
    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
    "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

  6. #5
    Just Joined!
    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
    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:
    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?
    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
    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.

  7. #6
    Just Joined!
    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?..

  8. #7
    Linux Guru antidrugue's Avatar
    Join Date
    Oct 2005
    Location
    Montreal, Canada
    Posts
    3,211
    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.

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

  9. #8
    Just Joined!
    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.

  10. #9
    Linux Guru antidrugue's Avatar
    Join Date
    Oct 2005
    Location
    Montreal, Canada
    Posts
    3,211
    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

  11. #10
    Just Joined!
    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 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?

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •