Discussion:
PowerTOP 1.97: Audio codec always showing usage of 100 %
(too old to reply)
Paul Menzel
2012-02-04 18:10:58 UTC
Permalink
Dear PowerTOP folks,


looking at the output of PowerTOP 1.97 on two laptops the usage of the
audio codec is always 100 % after the boot.

100,0% Device Audio codec hwC0D0: Realtek

The same is true with a Conexant codec.

This happens although power management in ALSA is set up and no sound is
played.

$ more /sys/module/snd_hda_intel/parameters/power_save_controller
Y
$ more /sys/module/snd_hda_intel/parameters/power_save
1

Most of the time I can get that behavior to change when I play some
audio and then stop it.

Could you confirm this issues? Then I could possibly send a report to
the ALSA folks.


Thanks,

Paul
Arjan van de Ven
2012-02-04 18:40:48 UTC
Permalink
On 2/4/2012 10:10 AM, Paul Menzel wrote:
> Dear PowerTOP folks,
>
>
> looking at the output of PowerTOP 1.97 on two laptops the usage of the
> audio codec is always 100 % after the boot.
>
> 100,0% Device Audio codec hwC0D0: Realtek
>
> The same is true with a Conexant codec.
>
> This happens although power management in ALSA is set up and no sound is
> played.
>
> $ more /sys/module/snd_hda_intel/parameters/power_save_controller
> Y
> $ more /sys/module/snd_hda_intel/parameters/power_save
> 1
>
> Most of the time I can get that behavior to change when I play some
> audio and then stop it.
>
> Could you confirm this issues? Then I could possibly send a report to
> the ALSA folks.
I've seen it a few times when pulse audio kept the guy busy...
you can check that by killing the pulseaudio daemon
(don't worry, it'll come back the next time you play a sound)
Paul Menzel
2012-02-09 13:14:35 UTC
Permalink
Am Samstag, den 04.02.2012, 10:40 -0800 schrieb Arjan van de Ven:
> On 2/4/2012 10:10 AM, Paul Menzel wrote:

> > looking at the output of PowerTOP 1.97 on two laptops the usage of the
> > audio codec is always 100 % after the boot.
> >
> > 100,0% Device Audio codec hwC0D0: Realtek
> >
> > The same is true with a Conexant codec.
> >
> > This happens although power management in ALSA is set up and no sound is
> > played.
> >
> > $ more /sys/module/snd_hda_intel/parameters/power_save_controller
> > Y
> > $ more /sys/module/snd_hda_intel/parameters/power_save
> > 1
> >
> > Most of the time I can get that behavior to change when I play some
> > audio and then stop it.
> >
> > Could you confirm this issues? Then I could possibly send a report to
> > the ALSA folks.
>
> I've seen it a few times when pulse audio kept the guy busy...
> you can check that by killing the pulseaudio daemon
> (don't worry, it'll come back the next time you play a sound)

Thank you for the suggestion. PulseAudio is not installed on the system
though. How can I find out which process is using an audio device?


Thanks,

Paul
Arjan van de Ven
2012-02-09 14:38:19 UTC
Permalink
On 2/9/2012 5:14 AM, Paul Menzel wrote:
> Am Samstag, den 04.02.2012, 10:40 -0800 schrieb Arjan van de Ven:
>> On 2/4/2012 10:10 AM, Paul Menzel wrote:
>
>>> looking at the output of PowerTOP 1.97 on two laptops the usage of the
>>> audio codec is always 100 % after the boot.
>>>
>>> 100,0% Device Audio codec hwC0D0: Realtek
>>>
>>> The same is true with a Conexant codec.
>>>
>>> This happens although power management in ALSA is set up and no sound is
>>> played.
>>>
>>> $ more /sys/module/snd_hda_intel/parameters/power_save_controller
>>> Y
>>> $ more /sys/module/snd_hda_intel/parameters/power_save
>>> 1
>>>
>>> Most of the time I can get that behavior to change when I play some
>>> audio and then stop it.
>>>
>>> Could you confirm this issues? Then I could possibly send a report to
>>> the ALSA folks.
>>
>> I've seen it a few times when pulse audio kept the guy busy...
>> you can check that by killing the pulseaudio daemon
>> (don't worry, it'll come back the next time you play a sound)
>
> Thank you for the suggestion. PulseAudio is not installed on the system
> though. How can I find out which process is using an audio device?

uhm


try the "lsof" tool

or you found a real kernel driver bug ;-)
Paul Menzel
2012-02-10 09:07:57 UTC
Permalink
Am Donnerstag, den 09.02.2012, 06:38 -0800 schrieb Arjan van de Ven:
> On 2/9/2012 5:14 AM, Paul Menzel wrote:
> > Am Samstag, den 04.02.2012, 10:40 -0800 schrieb Arjan van de Ven:
> >> On 2/4/2012 10:10 AM, Paul Menzel wrote:
> >
> >>> looking at the output of PowerTOP 1.97 on two laptops the usage of the
> >>> audio codec is always 100 % after the boot.
> >>>
> >>> 100,0% Device Audio codec hwC0D0: Realtek
> >>>
> >>> The same is true with a Conexant codec.

100,0% Device Audio codec alsa:hwC0D0: thinkpad (Conexant)

> >>> This happens although power management in ALSA is set up and no sound is
> >>> played.
> >>>
> >>> $ more /sys/module/snd_hda_intel/parameters/power_save_controller
> >>> Y
> >>> $ more /sys/module/snd_hda_intel/parameters/power_save
> >>> 1
> >>>
> >>> Most of the time I can get that behavior to change when I play some
> >>> audio and then stop it.
> >>>
> >>> Could you confirm this issues? Then I could possibly send a report to
> >>> the ALSA folks.
> >>
> >> I've seen it a few times when pulse audio kept the guy busy...
> >> you can check that by killing the pulseaudio daemon
> >> (don't worry, it'll come back the next time you play a sound)
> >
> > Thank you for the suggestion. PulseAudio is not installed on the system
> > though.

I also checked it on a system with PulseAudio installed but `pulseaudio
--check` returned that PulseAudio was not running.

$ pulseaudio --check
$ echo $?
1

> How can I find out which process is using an audio device?
>
> uhm
>
> try the "lsof" tool

Unfortunately neither `lsof` nor `fuser` returned any process using that
device.

$ sudo lsof /dev/snd/hwC0D0
$ sudo fuser -v /dev/snd/hwC0D0

> or you found a real kernel driver bug ;-)

Looks like it. I guess I will contact the ALSA list and asking what this
device is about and if they can fix it.

Could you answer a last question, please? What is PowerTOP actually
checking to figure out the usage.


Thanks,

Paul
Arjan van de Ven
2012-02-10 14:08:16 UTC
Permalink
On 2/10/2012 1:07 AM, Paul Menzel wrote:
> Unfortunately neither `lsof` nor `fuser` returned any process using that
> device.
>
> $ sudo lsof /dev/snd/hwC0D0
> $ sudo fuser -v /dev/snd/hwC0D0

also look for /dev/dsp or similar
>
>> > or you found a real kernel driver bug ;-)
> Looks like it. I guess I will contact the ALSA list and asking what this
> device is about and if they can fix it.
>
> Could you answer a last question, please? What is PowerTOP actually
> checking to figure out the usage.


the codec's directory in sysfs (say
/sys/devices/pci0000.00/0000:00:1b.0/sound/card0/hwC0D3) has 2 files,
power_on_acct and power_off_act
these count time that the codec is on or off respectively.
powertop calculates a delta of these two over the measurement interval
(20 seconds), and then since it knows how long it was on and off,
calculates the percentage.
Paul Menzel
2012-02-11 23:22:31 UTC
Permalink
Am Freitag, den 10.02.2012, 06:08 -0800 schrieb Arjan van de Ven:
> On 2/10/2012 1:07 AM, Paul Menzel wrote:
> > Unfortunately neither `lsof` nor `fuser` returned any process using that
> > device.
> >
> > $ sudo lsof /dev/snd/hwC0D0
> > $ sudo fuser -v /dev/snd/hwC0D0
>
> also look for /dev/dsp or similar

That was also to no avail.

> >> > or you found a real kernel driver bug ;-)
> > Looks like it. I guess I will contact the ALSA list and asking what this
> > device is about and if they can fix it.
> >
> > Could you answer a last question, please? What is PowerTOP actually
> > checking to figure out the usage.
>
> the codec's directory in sysfs (say
> /sys/devices/pci0000.00/0000:00:1b.0/sound/card0/hwC0D3) has 2 files,
> power_on_acct and power_off_act
> these count time that the codec is on or off respectively.
> powertop calculates a delta of these two over the measurement interval
> (20 seconds), and then since it knows how long it was on and off,
> calculates the percentage.

Thank you very much for that information. I brought that problem up to
the alsa-devel list [1].


Thanks,

Paul


[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049019.html
Paul Menzel
2012-02-15 09:31:48 UTC
Permalink
Am Sonntag, den 12.02.2012, 00:22 +0100 schrieb Paul Menzel:
> Am Freitag, den 10.02.2012, 06:08 -0800 schrieb Arjan van de Ven:
> > On 2/10/2012 1:07 AM, Paul Menzel wrote:
> > > Unfortunately neither `lsof` nor `fuser` returned any process using that
> > > device.
> > >
> > > $ sudo lsof /dev/snd/hwC0D0
> > > $ sudo fuser -v /dev/snd/hwC0D0
> >
> > also look for /dev/dsp or similar
>
> That was also to no avail.
>
> > >> > or you found a real kernel driver bug ;-)
> > > Looks like it. I guess I will contact the ALSA list and asking what this
> > > device is about and if they can fix it.
> > >
> > > Could you answer a last question, please? What is PowerTOP actually
> > > checking to figure out the usage.
> >
> > the codec's directory in sysfs (say
> > /sys/devices/pci0000.00/0000:00:1b.0/sound/card0/hwC0D3) has 2 files,
> > power_on_acct and power_off_act
> > these count time that the codec is on or off respectively.
> > powertop calculates a delta of these two over the measurement interval
> > (20 seconds), and then since it knows how long it was on and off,
> > calculates the percentage.
>
> Thank you very much for that information. I brought that problem up to
> the alsa-devel list [1].

According to Takashi Iwai this is a known missing feature nobody has yet
implemented. To get the power management enabled the audio device has to
be opened by for example `echo -n | aplay`.

Unfortunately I do not have any numbers how much “wasted” power we are
talking about here.


Thanks,

Paul


> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049019.html
[2] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049095.html
j
2012-02-15 09:36:19 UTC
Permalink
On 02/15/2012 01:31 AM, Paul Menzel wrote:
> Am Sonntag, den 12.02.2012, 00:22 +0100 schrieb Paul Menzel:
>> Am Freitag, den 10.02.2012, 06:08 -0800 schrieb Arjan van de Ven:
>>> On 2/10/2012 1:07 AM, Paul Menzel wrote:
>>>> Unfortunately neither `lsof` nor `fuser` returned any process using that
>>>> device.
>>>>
>>>> $ sudo lsof /dev/snd/hwC0D0
>>>> $ sudo fuser -v /dev/snd/hwC0D0
>>> also look for /dev/dsp or similar
>> That was also to no avail.
>>
>>>>>> or you found a real kernel driver bug ;-)
>>>> Looks like it. I guess I will contact the ALSA list and asking what this
>>>> device is about and if they can fix it.
>>>>
>>>> Could you answer a last question, please? What is PowerTOP actually
>>>> checking to figure out the usage.
>>> the codec's directory in sysfs (say
>>> /sys/devices/pci0000.00/0000:00:1b.0/sound/card0/hwC0D3) has 2 files,
>>> power_on_acct and power_off_act
>>> these count time that the codec is on or off respectively.
>>> powertop calculates a delta of these two over the measurement interval
>>> (20 seconds), and then since it knows how long it was on and off,
>>> calculates the percentage.
>> Thank you very much for that information. I brought that problem up to
>> the alsa-devel list [1].
> According to Takashi Iwai this is a known missing feature nobody has yet
> implemented. To get the power management enabled the audio device has to
> be opened by for example `echo -n | aplay`.
>
> Unfortunately I do not have any numbers how much "wasted" power we are
> talking about here.
>
>
> Thanks,
>
> Paul
>
>
>> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049019.html
> [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049095.html
>
>
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.lesswatts.org/listinfo/discuss
I see the same in my powertop2 results and have been searching for ways
to cut it down as it seems to be the only thing really that while lists
not actual wattage being drawn stays at a constant 100%. If there is any
useful info I can pass along let me know.

Thanks for all the great work on the powertop project
j
2012-02-15 09:38:54 UTC
Permalink
On 02/15/2012 01:31 AM, Paul Menzel wrote:
> Am Sonntag, den 12.02.2012, 00:22 +0100 schrieb Paul Menzel:
>> Am Freitag, den 10.02.2012, 06:08 -0800 schrieb Arjan van de Ven:
>>> On 2/10/2012 1:07 AM, Paul Menzel wrote:
>>>> Unfortunately neither `lsof` nor `fuser` returned any process using that
>>>> device.
>>>>
>>>> $ sudo lsof /dev/snd/hwC0D0
>>>> $ sudo fuser -v /dev/snd/hwC0D0
>>> also look for /dev/dsp or similar
>> That was also to no avail.
>>
>>>>>> or you found a real kernel driver bug ;-)
>>>> Looks like it. I guess I will contact the ALSA list and asking what this
>>>> device is about and if they can fix it.
>>>>
>>>> Could you answer a last question, please? What is PowerTOP actually
>>>> checking to figure out the usage.
>>> the codec's directory in sysfs (say
>>> /sys/devices/pci0000.00/0000:00:1b.0/sound/card0/hwC0D3) has 2 files,
>>> power_on_acct and power_off_act
>>> these count time that the codec is on or off respectively.
>>> powertop calculates a delta of these two over the measurement interval
>>> (20 seconds), and then since it knows how long it was on and off,
>>> calculates the percentage.
>> Thank you very much for that information. I brought that problem up to
>> the alsa-devel list [1].
> According to Takashi Iwai this is a known missing feature nobody has yet
> implemented. To get the power management enabled the audio device has to
> be opened by for example `echo -n | aplay`.
>
> Unfortunately I do not have any numbers how much "wasted" power we are
> talking about here.
>
>
> Thanks,
>
> Paul
>
>
>> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049019.html
> [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049095.html
>
>
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.lesswatts.org/listinfo/discuss
Sorry forgot to post it says its Audio codec hwC0D0: Conextant. When not
power saving (on ac) runs about 426mW 100% usage no results return with
the listed commands requested before. When I apply my battery power
savings nothing in mW but still stays at 100% usage
Arjan van de Ven
2012-02-15 14:24:04 UTC
Permalink
On 2/15/2012 1:38 AM, j wrote:
> Sorry forgot to post it says its Audio codec hwC0D0: Conextant. When not
> power saving (on ac) runs about 426mW 100% usage no results return with
> the listed commands requested before. When I apply my battery power
> savings nothing in mW but still stays at 100% usage
>
>


btw there is something fundamentally wrong with what you write ;-)

"battery powr saving settings" is a fundamentally flawed concept. Power
savings matter always, not just when on battery!
Any project that thinks that it wants to do some settings only when on
battery is broken by design in this regard....
Paul Menzel
2012-02-15 15:44:18 UTC
Permalink
Am Mittwoch, den 15.02.2012, 06:24 -0800 schrieb Arjan van de Ven:
> On 2/15/2012 1:38 AM, j wrote:
> > Sorry forgot to post it says its Audio codec hwC0D0: Conextant. When not
> > power saving (on ac) runs about 426mW 100% usage no results return with
> > the listed commands requested before. When I apply my battery power
> > savings nothing in mW but still stays at 100% usage
>
> btw there is something fundamentally wrong with what you write ;-)
>
> "battery powr saving settings" is a fundamentally flawed concept. Power
> savings matter always, not just when on battery!
> Any project that thinks that it wants to do some settings only when on
> battery is broken by design in this regard....

I totally agree. Unfortunately the pm-utils list seems inactive. I found
out, that I can run `sudo pm-powersave` to activate those power saving
settings even when running on AC power.


Thanks,

Paul
j
2012-02-15 21:34:37 UTC
Permalink
On 02/15/2012 07:44 AM, Paul Menzel wrote:
> Am Mittwoch, den 15.02.2012, 06:24 -0800 schrieb Arjan van de Ven:
>> On 2/15/2012 1:38 AM, j wrote:
>>> Sorry forgot to post it says its Audio codec hwC0D0: Conextant. When not
>>> power saving (on ac) runs about 426mW 100% usage no results return with
>>> the listed commands requested before. When I apply my battery power
>>> savings nothing in mW but still stays at 100% usage
>> btw there is something fundamentally wrong with what you write ;-)
>>
>> "battery powr saving settings" is a fundamentally flawed concept. Power
>> savings matter always, not just when on battery!
>> Any project that thinks that it wants to do some settings only when on
>> battery is broken by design in this regard....
> I totally agree. Unfortunately the pm-utils list seems inactive. I found
> out, that I can run `sudo pm-powersave` to activate those power saving
> settings even when running on AC power.
>
>
> Thanks,
>
> Paul
>
>
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.lesswatts.org/listinfo/discuss
Why if you are on AC power does it matter, if the user chooses to not
worry about consumption while on AC and only cares about saving power
once switching to battery? I do not think I get what you are trying to
tell me. I do not use pm-powersave or anything like that I just use a
simple handler.sh with acpi. Doing it the way I said and only caring
about power on battery since that is when I need it to last, I have gone
from a simple 1.5hrs to well over 3.5 hrs on battery. Again why does
what the wattage on AC really matter.

Thanks
Arjan van de Ven
2012-02-15 22:16:04 UTC
Permalink
> Why if you are on AC power does it matter, if the user chooses to not
> worry about consumption while on AC and only cares about saving power
> once switching to battery? I do not think I get what you are trying to
> tell me. I do not use pm-powersave or anything like that I just use a
> simple handler.sh with acpi. Doing it the way I said and only caring
> about power on battery since that is when I need it to last, I have gone
> from a simple 1.5hrs to well over 3.5 hrs on battery. Again why does
> what the wattage on AC really matter.

first of all, if you're acting as a server in a datacenter it really
matters.
second... burning power in once place will reduce performance in other
places; more and more things in systems are now thermally limited; for
example, the CPU turbo mode is limited if the system gets warmer.
likewise, things like that are current supply limited. Also, your
battery will charge slower if system power consumption is higher...


and.. if you burn a few more watts, that's CO2 you're generating for no
good reason.

anything that you tune either should be always tuned (e.g. free)
or involves a tradeoff, for which the question pretty much never is "am
I on AC", but "can the user tolerate X right now". Once you ask that
right question, and solve that, then "on AC" will turn out never be in
that picture.
j
2012-02-15 22:30:43 UTC
Permalink
On 02/15/2012 02:16 PM, Arjan van de Ven wrote:
>> Why if you are on AC power does it matter, if the user chooses to not
>> worry about consumption while on AC and only cares about saving power
>> once switching to battery? I do not think I get what you are trying to
>> tell me. I do not use pm-powersave or anything like that I just use a
>> simple handler.sh with acpi. Doing it the way I said and only caring
>> about power on battery since that is when I need it to last, I have gone
>> from a simple 1.5hrs to well over 3.5 hrs on battery. Again why does
>> what the wattage on AC really matter.
> first of all, if you're acting as a server in a datacenter it really
> matters.
> second... burning power in once place will reduce performance in other
> places; more and more things in systems are now thermally limited; for
> example, the CPU turbo mode is limited if the system gets warmer.
> likewise, things like that are current supply limited. Also, your
> battery will charge slower if system power consumption is higher...
>
>
> and.. if you burn a few more watts, that's CO2 you're generating for no
> good reason.
>
> anything that you tune either should be always tuned (e.g. free)
> or involves a tradeoff, for which the question pretty much never is "am
> I on AC", but "can the user tolerate X right now". Once you ask that
> right question, and solve that, then "on AC" will turn out never be in
> that picture.
>
And me being the user choosing to do it the way I have stated on a
laptop is incorrect then you're saying? I am not one to be concerned
with CO2 or any of the crap. I am not an eco conscious person nor do I
care to take the time/effort/knowledge to do it properly. I have
everything set to default program values or OS default values on AC and
then on battery go into a more strict policy and go about it in the
manner you state. Again I see no way I am really "wasting" power or
"adding to CO2". Plus how do you know me as the user does not live
rurally and relies on solar power only? (which I actually do)

Also why have I not seen an increase in charge time for my battery if
this is the case as well? My charge time has not increased any, and I
feel its VERY reasonable in the charge time for the battery capacity.
You state that performance will drop if I am wasting power on AC, well
where is this said performance loss? In relation to? I have never
noticed a performance loss on AC power by leaving default values, also
when on AC power most would tend to do a more intense use of the
computer as they do not have to worry about power usage then. Also I
think adding in many "power" related run time programs defeats the
purpose of trying to save power hence me only using a handler.sh with
acpi and nothing else.

It is my electricity so I feel its my choice in how I use it and still
do not see how any of this stuff relates to me offering info about the
CODEC that the OP is talking about. If I am OK with the amount of time
it takes to charge then there is no effect to me as the user, which of
course in the Linux way, may not be compatible for you or to your
liking. I am just concerned with lower wattage usage on my battery and
that CODEC is running in the manner the OP stated and how I stated.
Would be nice to get info pertaining to that.
Kok, Auke-jan H
2012-02-15 23:04:46 UTC
Permalink
On Wed, Feb 15, 2012 at 2:30 PM, j <vwyodapink-***@public.gmane.org> wrote:
> And me being the user choosing to do it the way I have stated on a laptop is
> incorrect then you're saying? I am not one to be concerned with CO2 or any
> of the crap. I am not an eco conscious person nor do I care to take the
> time/effort/knowledge to do it properly.

Troll much?

If you design every system to be only power efficient on battery,
you'd have a lot of melted myphones, and laptop batteries leaking
after a year of usage, and people complaining their electricity bills
are too high after they installed a new appliance at home.

It matters. Even if *you* don't care. Even if *you* don't understand it either.

Auke
Paul Fox
2012-02-15 22:46:13 UTC
Permalink
arjan van de ven wrote:
>
> > Why if you are on AC power does it matter, if the user chooses to not
> > worry about consumption while on AC and only cares about saving power
> > once switching to battery? I do not think I get what you are trying to
> > tell me. I do not use pm-powersave or anything like that I just use a
> > simple handler.sh with acpi. Doing it the way I said and only caring
> > about power on battery since that is when I need it to last, I have gone
> > from a simple 1.5hrs to well over 3.5 hrs on battery. Again why does
> > what the wattage on AC really matter.
>
> first of all, if you're acting as a server in a datacenter it really
> matters.
> second... burning power in once place will reduce performance in other
> places; more and more things in systems are now thermally limited; for
> example, the CPU turbo mode is limited if the system gets warmer.
> likewise, things like that are current supply limited. Also, your
> battery will charge slower if system power consumption is higher...
>
>
> and.. if you burn a few more watts, that's CO2 you're generating for no
> good reason.
>
> anything that you tune either should be always tuned (e.g. free)
> or involves a tradeoff, for which the question pretty much never is "am
> I on AC", but "can the user tolerate X right now". Once you ask that
> right question, and solve that, then "on AC" will turn out never be in
> that picture.

exactly! well said.

this discussion comes up often at OLPC (though less often than it used
to). it's very tempting to be casual about using power when connected
to an external source -- but when the external power is coming from a
solar panel, or from a very expensive utility company, it's just as
valuable as when it comes from the laptop's battery. here's an
example, which coincidentally was published just today:
http://www.olpcnews.com/hardware/power_supply/power_education_in_remote_papua_new_guinea_technology.html

paul

>
> _______________________________________________
> Discuss mailing list
> Discuss-***@public.gmane.org
> http://lists.lesswatts.org/listinfo/discuss

=---------------------
paul fox, pgf-2X9k7bc8m7Mdnm+***@public.gmane.org
Paul Menzel
2012-02-16 09:14:12 UTC
Permalink
Am Mittwoch, den 15.02.2012, 01:38 -0800 schrieb j:
> On 02/15/2012 01:31 AM, Paul Menzel wrote:
> > Am Sonntag, den 12.02.2012, 00:22 +0100 schrieb Paul Menzel:
> >> Am Freitag, den 10.02.2012, 06:08 -0800 schrieb Arjan van de Ven:
> >>> On 2/10/2012 1:07 AM, Paul Menzel wrote:
> >>>> Unfortunately neither `lsof` nor `fuser` returned any process using that
> >>>> device.
> >>>>
> >>>> $ sudo lsof /dev/snd/hwC0D0
> >>>> $ sudo fuser -v /dev/snd/hwC0D0
> >>> also look for /dev/dsp or similar
> >> That was also to no avail.
> >>
> >>>>>> or you found a real kernel driver bug ;-)
> >>>> Looks like it. I guess I will contact the ALSA list and asking what this
> >>>> device is about and if they can fix it.
> >>>>
> >>>> Could you answer a last question, please? What is PowerTOP actually
> >>>> checking to figure out the usage.
> >>> the codec's directory in sysfs (say
> >>> /sys/devices/pci0000.00/0000:00:1b.0/sound/card0/hwC0D3) has 2 files,
> >>> power_on_acct and power_off_act
> >>> these count time that the codec is on or off respectively.
> >>> powertop calculates a delta of these two over the measurement interval
> >>> (20 seconds), and then since it knows how long it was on and off,
> >>> calculates the percentage.
> >> Thank you very much for that information. I brought that problem up to
> >> the alsa-devel list [1].
> > According to Takashi Iwai this is a known missing feature nobody has yet
> > implemented. To get the power management enabled the audio device has to
> > be opened by for example `echo -n | aplay`.
> >
> > Unfortunately I do not have any numbers how much "wasted" power we are
> > talking about here.

> >> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049019.html
> > [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049095.html

Am Mittwoch, den 15.02.2012, 01:36 -0800 schrieb j:
> I see the same in my powertop2 results and have been searching for ways
> to cut it down as it seems to be the only thing really that while lists
> not actual wattage being drawn stays at a constant 100%. If there is any
> useful info I can pass along let me know.
>
> Thanks for all the great work on the powertop project

> Sorry forgot to post it says its Audio codec hwC0D0: Conextant. When not
> power saving (on ac) runs about 426mW 100% usage no results return with
> the listed commands requested before. When I apply my battery power
> savings nothing in mW but still stays at 100% usage

Please post the output of the `/sys/*` files I also posted.

$
more /sys/module/snd_hda_intel/parameters/power_save_controller
$ more /sys/module/snd_hda_intel/parameters/power_save

And the following in the beginning with some pause in between.

$ /sys/devices/pci0000.00/0000:00:
/sound/card0/hwC0D0/power_{on,off}_acct

Then `echo -n | aplay` and the above again.

$ /sys/devices/pci0000.00/0000:00:
/sound/card0/hwC0D0/power_{on,off}_acct

Then `aplay some_wave_file.wav`.

$ /sys/devices/pci0000.00/0000:00:
/sound/card0/hwC0D0/power_{on,off}_acct

Then play some music using your favorite music player (MPlayer, Totem, 
).

$ /sys/devices/pci0000.00/0000:00:
/sound/card0/hwC0D0/power_{on,off}_acct


Thanks,

Paul


PS: To keep threading, please also answer to your messages if you add
something. If you do not get messages sent by you delivered to you again
you can go to your sent folder and answer to the message their. Also
please only send plain text messages which you already did in your later
messages. [3] Thanks for that!


[3] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
Paul Menzel
2012-02-23 09:53:41 UTC
Permalink
Am Donnerstag, den 16.02.2012, 10:14 +0100 schrieb Paul Menzel:
> Am Mittwoch, den 15.02.2012, 01:38 -0800 schrieb j:
> > On 02/15/2012 01:31 AM, Paul Menzel wrote:
> > > Am Sonntag, den 12.02.2012, 00:22 +0100 schrieb Paul Menzel:
> > >> Am Freitag, den 10.02.2012, 06:08 -0800 schrieb Arjan van de Ven:
> > >>> On 2/10/2012 1:07 AM, Paul Menzel wrote:
> > >>>> Unfortunately neither `lsof` nor `fuser` returned any process using that
> > >>>> device.
> > >>>>
> > >>>> $ sudo lsof /dev/snd/hwC0D0
> > >>>> $ sudo fuser -v /dev/snd/hwC0D0
> > >>> also look for /dev/dsp or similar
> > >> That was also to no avail.
> > >>
> > >>>>>> or you found a real kernel driver bug ;-)
> > >>>> Looks like it. I guess I will contact the ALSA list and asking what this
> > >>>> device is about and if they can fix it.
> > >>>>
> > >>>> Could you answer a last question, please? What is PowerTOP actually
> > >>>> checking to figure out the usage.
> > >>> the codec's directory in sysfs (say
> > >>> /sys/devices/pci0000.00/0000:00:1b.0/sound/card0/hwC0D3) has 2 files,
> > >>> power_on_acct and power_off_act
> > >>> these count time that the codec is on or off respectively.
> > >>> powertop calculates a delta of these two over the measurement interval
> > >>> (20 seconds), and then since it knows how long it was on and off,
> > >>> calculates the percentage.
> > >> Thank you very much for that information. I brought that problem up to
> > >> the alsa-devel list [1].
> > > According to Takashi Iwai this is a known missing feature nobody has yet
> > > implemented. To get the power management enabled the audio device has to
> > > be opened by for example `echo -n | aplay`.
> > >
> > > Unfortunately I do not have any numbers how much "wasted" power we are
> > > talking about here.
>
> > >> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049019.html
> > > [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049095.html
>
> Am Mittwoch, den 15.02.2012, 01:36 -0800 schrieb j:
> > I see the same in my powertop2 results and have been searching for ways
> > to cut it down as it seems to be the only thing really that while lists
> > not actual wattage being drawn stays at a constant 100%. If there is any
> > useful info I can pass along let me know.
> >
> > Thanks for all the great work on the powertop project
>
> > Sorry forgot to post it says its Audio codec hwC0D0: Conextant. When not
> > power saving (on ac) runs about 426mW 100% usage no results return with
> > the listed commands requested before. When I apply my battery power
> > savings nothing in mW but still stays at 100% usage
>
> Please post the output of the `/sys/*` files I also posted.
>
> $
> more /sys/module/snd_hda_intel/parameters/power_save_controller
> $ more /sys/module/snd_hda_intel/parameters/power_save
>
> And the following in the beginning with some pause in between.
>
> $ /sys/devices/pci0000.00/0000:00:
/sound/card0/hwC0D0/power_{on,off}_acct
>
> Then `echo -n | aplay` and the above again.
>
> $ /sys/devices/pci0000.00/0000:00:
/sound/card0/hwC0D0/power_{on,off}_acct
>
> Then `aplay some_wave_file.wav`.
>
> $ /sys/devices/pci0000.00/0000:00:
/sound/card0/hwC0D0/power_{on,off}_acct
>
> Then play some music using your favorite music player (MPlayer, Totem, 
).
>
> $ /sys/devices/pci0000.00/0000:00:
/sound/card0/hwC0D0/power_{on,off}_acct

j, did that work for you?

> PS: To keep threading, please also answer to your messages if you add
> something. If you do not get messages sent by you delivered to you again
> you can go to your sent folder and answer to the message their. Also
> please only send plain text messages which you already did in your later
> messages. [3] Thanks for that!


Thanks,

Paul


> [3] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
Arjan van de Ven
2012-02-15 14:22:00 UTC
Permalink
On 2/15/2012 1:31 AM, Paul Menzel wrote:
> According to Takashi Iwai this is a known missing feature nobody has yet
> implemented. To get the power management enabled the audio device has to
> be opened by for example `echo -n | aplay`.
>
> Unfortunately I do not have any numbers how much “wasted” power we are
> talking about here.

depending on the exact chip, you can easily be talking about 0.5 to 1
Watts (this is the analog component.. those tend to suck power)
Loading...