Hi folks! When playing any kind of audio on a Thinkpad X201 the total power consumption rises from ~11W to ~17W. powertop 1.97 reveals that the C3 and C6 sleep states of the “Package” in the “Idle Stats”-tab completly drop to 0%. This problem seems to occur with any kernel. I’ve tried various Fedora, Debian and vanilla kernels since v2.6.38. The Notebook uses a Intel Core i5 540M, so other Notebooks might be affected too. The problem does not occur under WindowsXP, so it has to be some kind of driver issue. To reproduce: • Take a Thinkpad X201 (the Core i5 model) with any Linux distro and kernel • Play any kind of audio with any application, pulseaudio or alsa, speakers or headphones, it does not matter. • Look at power consumption and powertop’s “Idle States” • Notice an increase of power by ~5W and 0% C3 and C6 states. This bug has been annoying me for a long time since it cuts battery time by ⅓ as soon as one plugs in headphones and listens to music on the train. I’ve searched the internet for a solution or at least a bugreport for hours and found nothing.
Created attachment 72552 [details] Powertop with music. Notice the 0% C3 and C6 in “Package”
Created attachment 72553 [details] Powertop while not playing any music. Everything’s fine. Don’t ask me why powertop does not display power consumption on my Notebook. And no, the AC is not connected.
Are you sure that you've tested with ALSA raw access? Usually when PulseAudio is installed, alsa-lib pulse plugin is also enabled so that all audio goes through PulseAudio even from ALSA-native apps unless a proper device option is specified. Try "aplay -Dplughw somefile.wav" to see whether it really happens the same problem with ALSA raw access.
Created attachment 72554 [details] lspci, for completeness
(In reply to comment #3) > Are you sure that you've tested with ALSA raw access? Usually when > PulseAudio > is installed, alsa-lib pulse plugin is also enabled so that all audio goes > through PulseAudio even from ALSA-native apps unless a proper device option > is > specified. > > Try "aplay -Dplughw somefile.wav" to see whether it really happens the same > problem with ALSA raw access. Yes. Just tried your command and it’s behaving just the same.
Then try position_fix=1 or position_fix=2 option for snd-hda-intel module.
Also, check whether model=auto option (again for snd-hda-intel) changes anything. In anyway, run alsa-info.sh with --no-upload option and attach the output to bugzilla.
Created attachment 72558 [details] alsa-info.sh
Comment on attachment 72558 [details] alsa-info.sh Tried all three parameters for snd_hda_intel … they unfortunatly didn’t change anything.
Then try bdl_pos_adj=0 option.
Still 0% C3 or C6 state when playing sound with that aplay command. The module parameters are correctly applied, according to /sys/module/snd_hda_intel/parameters/.
Well, how large buffer are you using? The max buffer size is limited in CONFIG_SND_HDA_PREALLOC_SIZE. As default, it's set relatively small. Set to 2048 or such would help much for power-saving. As mentioned in Kconfig help, it can be changed via proc file, too. Other than that, I have no idea. The driver itself is proven to be very power-aware. On an HP machine here, the power consumption is really small even during playback.
I’ve allready played around with the buffer size. It has no effect on the sleep behaviour and very little effect on power consumption.
Hi Takashi, I can confirm this bug. It is still present in recent kernels such as 3.2.30 and 3.4.10. On a Thinkpad X201s with the Conexant CX20585 codec power consumption increases by about 7 Watt (from 7 to 14(!) Watt) when playing some audio, no matter if pulseaudio is involved or not. This shortens the battery running time by 50%. On a Thinkpad X200s with Conexant CX20561 this problem does not exist. With the exactly same kernels the power just increases by about 1-2 Watt when playing mp3. Both tested on Ubuntu 12.04 and OpenSUSE 12.1/12.2 The be sure it is no hardware problem I tested the X201s with windows 7. No Problem there, power increase of ~1 Watt when playing a mp3. There are other users with X201 Thinkpads reporting the same problem. Not sure if it is a X201s only problem or all notebooks with CX20585 are affected. As Michael said, neither an increase of the buffer size nor playing with the module parameters changes the situation. Greetings, Ralf
I booted with 'nohz=off' to test whether it is the cpu or the sound card using so much power when playing sound. With disabling dynamic ticks, the X201s uses ~ 16.5 Watt when idle. When playing audio it goes to ~ 17.5-18 Watt, a slight increase of less than 2 Watts. So it looks like the problem is indeed a result of cpu wake-ups caused by alsa. Since this bug reduces the battery running time by 50% and increases the temperature of the cpu I would be very, very happy if it could be fixed. What additional information do you need? Please let me know how I can help to track this down.
OK, then it must be something in the driver spinning CPU. IIRC, there are two possible places where the things can go bad: 1. The workaround for position reporting 2. The unstable unsol events or other controller-codec mis-communication. The former should be disabled by passing bdl_pos_adj=0. But it seems not helping in this case. (And if the workaround was activated, you should have seen a kernel message.) For checking the latter, the easiest way would be enable tracing for hda_codec. A brief description is found in Documentation/alsa/HD-Audio.txt.
I rechecked to be sure, bdl_pos_adj=0 does not help. But I found that setting position_fix=1 saves about 0.5-1 Watts. Nevertheless the overall power consumption of 6 Watts is still too much. Tracing the hda_codec does not show any unsol events or anything else that points to a mis-communication. Since the root of the high power consumption is the cpu leaving the deep package c-states on active audio I tested the acpi_idle driver instead of intel_idle. No luck, same results. May be Len Brown should have a look at this? Ralf
If the codec communication looks OK and bdl_pos_adj doesn't change, there should be no wild things driver does. Did you already try to profile by perf? Maybe you can find something there if it's really any CPU task spinning.
I can confirm Ralf’s findings. I was too shy to report them myself because I wasn’t sure if I’d done everything correct. Let me try this perf thing …
Created attachment 84971 [details] perf record -a -g sleep 10 while playing audio with mocp Soooooo, I’ve done a perf record -a -g sleep 10. Unfortunately I don’t really know what to look for in perf report. Maybe someone else can take a look at my recorded file(s).
Created attachment 84981 [details] perf record -a -g sleep 10 while idling – just for comparison
The record files are almost useless without symbols on your machine :) But at least we can see that the issue isn't in kernel but it's wasted in libasound.so.2. You can take a deeper look via perf report -i perf.data.music
Created attachment 85281 [details] perf record with debug symbols for libasound Well, I guess that means we close the bug here and I have to go to the alsa guys (and girls)? I’ve attached the perf record with debug symbols, maybe you can still give me a hint what’s going wrong. Thank you for everything anyways!
Closed, as it's a user-space alsa-lib issue, if any.