"module-suspend-on-idle" should suspend the alsa devices when no clients are idle or not connected for 5 seconds by default. try loading that module and see if it actually closes the handle to the alsa devices. On Fri, Oct 7, 2011 at 10:21 AM, Paul Menzel < paulepanter at users.sourceforge.net> wrote: > Dear Andreas, > > > Am Freitag, den 07.10.2011, 17:03 +0200 schrieb Andreas Bauer: > > > First a big thank you for a quality piece of software. I am a first > > time user and am amazed at the flexiblity that PA provides. I > > installed PA because I wanted to have better integration of my > > Bluetooth headset and works perfectly. > > thank you for such positive feed back. I guess developers (not me) > should get that more often. > > > Running Debian Squeeze (stable) with Kernel 3.0.1 > > Is the PA version 0.9.21-3+squeeze1 [1]? I guess the ALSA version is > quite old then too. PA 1.0 was released recently. > > Could you somehow test a more recent version. I am not sure if there is > a live CD for that purpose or if you have a spare storage medium where > you can try Debian Sid/unstable. > > > Now I have three issues which I hope someone can point me to a > > possible solution. > > > > On my Lenovo X201 laptop with Intel HDA I do see a heavy increase in > > power consumption when I activate pulseaudio. The system is already > > optimised so without pulseaudio it will idle at 6-9W with wifi on, > > with pulseaudio started it will jump to 13W. No pulseaudio client > > connected (no sound played) > > > > Averaged battery reading every 5s > > > > 1267000 > > 1311000 > > 1330000 > > 1347000 <- here pa-suspender is started > > 1192000 > > 1091000 > > 986000 > > 952000 > > 943000 > > 988000 > > 970000 > > 943000 > > > > I have already optimised the PA setup for my needs (e.g. low quality > > resampling-method), so I investigated further: > > > > From top: > > > > 8816 ab 9 -11 211m 3832 2832 S 0 0.1 0:00.06 pulseaudio > > > > From powertop: > > > > 695,7 ?s/s 13,6 > > Process /usr/bin/pulseaudio --start --log-target=syslog > > > > So it is not about CPU consumption, pulseaudio is economical with CPU > > as is. > > > > The same thing (also drawing about the same amount of extra juice) > > happens with this: > > > > root at charly:~# mv /etc/asound.conf /etc/asound.pulse > > root at charly:~# aplay -d front /boot/vmlinuz-* > > Wiedergabe: Rohdaten '/boot/vmlinuz-3.0.1' : Unsigned 8 bit, Rate: > > 8000 Hz, mono > > > > So clearly, it is the power consumption of the sound chip. I suspect > > that pulseaudio activates the sound chip even when no sound is being > > played. Is there any way to have it only access the hardware when at > > minimum one client is connected (e.g. audio playing)? > > I am not sure. 4 W power consumption of a sound chip sounds quite a lot > to me. Additionally as written above please try a newer version. > > > I was not successful with this shot (old syntax?): > > > > add-autoload-sink alsa_sink module-alsa-sink device="hw:0" > > add-autoload-source alsa_source module-alsa-source device="hw:0" > > You can also take a look at the ALSA Wiki [2] and provide the output of > `alsa-info.sh` which should give a lot of useful information to the > developers. > > > Second issue: I have one application (Zoiper) which can only access > > ALSA at the moment (because it will not allow me to input non-hardware > > ALSA device names like pcm.pulse). Is there some hack/workaround to > > get such applications to talk to pulseaudio? > > Please open a new thread by sending a new message with an appropriate > subject line for this topic. > > > Thanks, > > Paul > > > [1] http://packages.debian.org/squeeze/pulseaudio > [2] http://alsa-project.org/main/index.php/Help_To_Debug > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > -- -baeksanchang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111007/96263909/attachment.htm>
