pm-utils AC/Battery policy requirement for Audio

Bug #1205263 reported by wangxingchao
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
intel
Won't Fix
Undecided
Unassigned
pm-utils (Ubuntu)
New
Undecided
Unassigned

Bug Description

On boards with charger connected, pm-utils disable *all* power-saving feture for PCI devices(include audio pci devices), the hooks is pci-devices under power.d.

This policy maybe too regressive.

 Here's our case:
On Intel's Harris beach baord, there're two HDA controller, one HDA in GPU side ,which powered by a area "power-well".
Harris Beach has only one eDP panel, if there's no HDMI/DP monitor connected, the audio function is not needed, and power-well should be shutdown. Otherwise some eDP feature will not be enabled.

When charger connected, the pm-utils policy let audio subsystem always active, which power-well always on and block eDP features.

So should we do some changing on the policy?

Revision history for this message
David Henningsson (diwic) wrote :

Here's an email with more information (reference: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-July/064462.html )

===
Hi Takashi,

In order to let audio power-save work even with charger connected, two parameters need be modified in userspace pm-utils scripts.
I tested the changes under Ubuntu 13.10 on Harris Beach, no matter charger connected or not, runtime power-saving works and power-well will
Be released as expected.

Here's my test under Ubuntu 13.04, the changes are:
1)
/usr/lib/pm-utils/power.d/intel-audio-powersave
case $1 in
    true) audio_powersave 1 ;;
+ false) audio_powersave 10 ;;
- false) audio_powersave 0 ;;
    help) help;;
    *) exit $NA
esac

Audio will enter power-save mode after 10s inactive period.
2) /usr/lib/pm-utils/power.d/pci_devices

     0x040300) # audio
        echo "Setting Audio device $id to $1"
+ echo "auto" > $dev/power/control
- echo $1 > $dev/power/control

This keep audio subsystem always on.

This way the user may not let audio subsystem always active, may bring some delay from codec/controllers, or harm some chips.
Do you think we should add an exception for Haswell only or just make it as a common solution for audio subsystem?

Thanks
--xingchao
===

Revision history for this message
XiongZhang (xiong-y-zhang) wrote :

hi, James:
      Could you help transform this issue to the ubuntu maintainer of pm-utils package, so that intel engineer can discuss this issue with him.

Revision history for this message
wangxingchao (xingchao-wang) wrote : RE: [Bug 1205263] Re: pm-utils AC/Battery policy requirement for Audio

Add audio team.

> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
> XiongZhang
> Sent: Thursday, August 1, 2013 9:36 AM
> To: Wang, Xingchao
> Subject: [Bug 1205263] Re: pm-utils AC/Battery policy requirement for Audio
>
> hi, James:
> Could you help transform this issue to the ubuntu maintainer of
> pm-utils package, so that intel engineer can discuss this issue with him.
>
> --
> You received this bug notification because you are subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1205263
>
> Title:
> pm-utils AC/Battery policy requirement for Audio
>
> Status in intel:
> New
>
> Bug description:
> On boards with charger connected, pm-utils disable *all* power-saving
> feture for PCI devices(include audio pci devices), the hooks is pci-
> devices under power.d.
>
> This policy maybe too regressive.
>
> Here's our case:
> On Intel's Harris beach baord, there're two HDA controller, one HDA in GPU
> side ,which powered by a area "power-well".
> Harris Beach has only one eDP panel, if there's no HDMI/DP monitor
> connected, the audio function is not needed, and power-well should be
> shutdown. Otherwise some eDP feature will not be enabled.
>
> When charger connected, the pm-utils policy let audio subsystem always
> active, which power-well always on and block eDP features.
>
> So should we do some changing on the policy?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/intel/+bug/1205263/+subscriptions

Revision history for this message
wangxingchao (xingchao-wang) wrote :

Hi zhangxiong,

Did you find owner of this bug? What's Ubuntu's feedback on our request?
Do you have anything to share with me?

Thanks
--xingchao

> -----Original Message-----
> From: Wang, Xingchao
> Sent: Thursday, August 1, 2013 9:52 AM
> To: Bug 1205263; Zhang, Xiong Y
> Cc: Li, Jocelyn; Lin, Mengdong; Girdwood, Liam R
> Subject: RE: [Bug 1205263] Re: pm-utils AC/Battery policy requirement for
> Audio
>
> Add audio team.
>
> > -----Original Message-----
> > From: <email address hidden> [mailto:<email address hidden>] On Behalf
> > Of XiongZhang
> > Sent: Thursday, August 1, 2013 9:36 AM
> > To: Wang, Xingchao
> > Subject: [Bug 1205263] Re: pm-utils AC/Battery policy requirement for
> > Audio
> >
> > hi, James:
> > Could you help transform this issue to the ubuntu maintainer of
> > pm-utils package, so that intel engineer can discuss this issue with him.
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> report.
> > https://bugs.launchpad.net/bugs/1205263
> >
> > Title:
> > pm-utils AC/Battery policy requirement for Audio
> >
> > Status in intel:
> > New
> >
> > Bug description:
> > On boards with charger connected, pm-utils disable *all* power-saving
> > feture for PCI devices(include audio pci devices), the hooks is pci-
> > devices under power.d.
> >
> > This policy maybe too regressive.
> >
> > Here's our case:
> > On Intel's Harris beach baord, there're two HDA controller, one HDA
> > in GPU side ,which powered by a area "power-well".
> > Harris Beach has only one eDP panel, if there's no HDMI/DP monitor
> > connected, the audio function is not needed, and power-well should be
> > shutdown. Otherwise some eDP feature will not be enabled.
> >
> > When charger connected, the pm-utils policy let audio subsystem always
> > active, which power-well always on and block eDP features.
> >
> > So should we do some changing on the policy?
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/intel/+bug/1205263/+subscriptions

Revision history for this message
James M. Leddy (jm-leddy) wrote :

Hi Xiong,

I'll get feedback on this issue shortly.

information type: Proprietary → Private
Revision history for this message
James M. Leddy (jm-leddy) wrote :

This package is debian-maintained, so we have to take our request up there. I'll open a bug with Debian and work with Ubuntu Engineering to get this fixed.

Revision history for this message
James M. Leddy (jm-leddy) wrote :

Hi Wang, It makes sense, but we have to think about doing it more smartly. We can't set these values to hardcoded, since as you said, it'll affect all machines. I'll talk more with the developer, but I think we'll wind up adding a new enviroment variable for this class of haswell devices that will behave differently.

Revision history for this message
wangxingchao (xingchao-wang) wrote :

Hi,

Glad to hear that you're making progress on this issue.
The policy should be flexible according to different hardware, and Haswell really be particular on this policy.
So please help set up a proper policy setting for Haswell chipset.
Please keep us informed if you need support from us.

Thanks
--xingchao

> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
> James M. Leddy
> Sent: Thursday, August 15, 2013 6:45 AM
> To: Wang, Xingchao
> Subject: [Bug 1205263] Re: pm-utils AC/Battery policy requirement for Audio
>
> Hi Wang, It makes sense, but we have to think about doing it more smartly. We
> can't set these values to hardcoded, since as you said, it'll affect all machines.
> I'll talk more with the developer, but I think we'll wind up adding a new
> enviroment variable for this class of haswell devices that will behave differently.
>
> --
> You received this bug notification because you are subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1205263
>
> Title:
> pm-utils AC/Battery policy requirement for Audio
>
> Status in intel:
> New
> Status in “pm-utils” package in Ubuntu:
> New
>
> Bug description:
> On boards with charger connected, pm-utils disable *all* power-saving
> feture for PCI devices(include audio pci devices), the hooks is pci-
> devices under power.d.
>
> This policy maybe too regressive.
>
> Here's our case:
> On Intel's Harris beach baord, there're two HDA controller, one HDA in GPU
> side ,which powered by a area "power-well".
> Harris Beach has only one eDP panel, if there's no HDMI/DP monitor
> connected, the audio function is not needed, and power-well should be
> shutdown. Otherwise some eDP feature will not be enabled.
>
> When charger connected, the pm-utils policy let audio subsystem always
> active, which power-well always on and block eDP features.
>
> So should we do some changing on the policy?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/intel/+bug/1205263/+subscriptions

Revision history for this message
David Henningsson (diwic) wrote :

@jmleddy,

> We can't set these values to hardcoded, since as you said, it'll affect all machines.

It will, but I don't think this is a bad thing. We should at least be able to set it for all laptops, because they already set it when on battery. Desktop machines are far less tested though.

Revision history for this message
Martin Pitt (pitti) wrote :

I'm afraid I'm the wrong person to ask about this, I don't know about audio hardware power management. Just some thoughts:

 * If it's safe to turn on power saving on battery mode after 1 (or 10, as in above suggestion) seconds, why isn't it safe to do it on AC as well? Are there some drawbacks like a long wakeup time, or anything else which causes a noticeable regression in that mode? Or is that still the potential click/pop problem as pointed out in http://www.mjmwired.net/kernel/Documentation/sound/alsa/powersave.txt ?

 * We don't want click/pop noises on battery either. Are we actually aware of that happening, from bug reports etc? It seems to me that we should enable audio power saving on hardware where it's safe to do so, not depending on battery mode.

 * Thirdly, above documentation actually suggests that "1" is a bad default, so in the powersaving case we should change that to 10.

So perhaps we could start with changing the hook to ignore the $1 argument (i. e. whether on powersave mode or not), and instead enable power_save = 10 on known-good devices/drivers at least for an SRU? For the development series we could actually set it to 10 always and send a call for testing to watch out for click/pop noises?

Revision history for this message
Martin Pitt (pitti) wrote :

Please note that in case you decide for "always set this to 10", this ought to happen in our kernel config, not in pm-utils.

Revision history for this message
David Henningsson (diwic) wrote :

> * If it's safe to turn on power saving on battery mode after 1 (or 10,
> as in above suggestion) seconds, why isn't it safe to do it on AC as
> well? Are there some drawbacks like a long wakeup time, or anything else
> which causes a noticeable regression in that mode? Or is that still the
> potential click/pop problem as pointed out in
> http://www.mjmwired.net/kernel/Documentation/sound/alsa/powersave.txt ?

Well, all of that has happened in the past - most commonly pop/clicks, wakeup times (hardly more than a few 100 ms though), and in worst case, controller or codec wakeup failure (leading to no audio at all).
The vast majority of these problems have been resolved (seen over a five year period or so), but it's difficult to know how many problems remain.

However, most laptops have been on battery, so I assume the issues there have been resolved to a very large degree. Desktop machines are always AC connected, so it's more risky for those. I'd say that at least for laptops, I'd vote for taking the risk. For desktops, not so sure.

> * We don't want click/pop noises on battery either. Are we actually
> aware of that happening, from bug reports etc? It seems to me that we
> should enable audio power saving on hardware where it's safe to do so,
> not depending on battery mode.

Click/pop noises are not commonly reported today, but it happens. However, I kind of understand the intention too - given non-perfect drivers, on battery you might prefer having a few extra minutes of battery and live with the pop, whereas on AC, you don't have to make that consideration.

> * Thirdly, above documentation actually suggests that "1" is a bad
> default, so in the powersaving case we should change that to 10.

PulseAudio keeps the device open for 5 seconds after the last client has stopped accessing the sound card, so even if set to "1", it's 5+1 = 6 seconds for the most common use cases. However, 5 here seems to be a reasonable compromise, then we end up with 5+5 = 10.

Revision history for this message
Martin Pitt (pitti) wrote :

So to be conservative, the hook could apply "10" in all cases for known-good devices or models (you could check /sys/class/dmi/id/* or /sys/class/sound/*), and otherwise keep the existing logic (but change "1" to "10").

Revision history for this message
David Henningsson (diwic) wrote :

Well, we don't have a good list of "Known-good devices or models". Could we perhaps just look in /sys/class/power_supply to see if there is a battery, if there isn't, it's a desktop, and then it's too risky to enable?

Revision history for this message
Martin Pitt (pitti) wrote :

Sure, you can do that. This won't catch docked laptops with the battery taken out though, but this might be a corner case.

Revision history for this message
Martin Pitt (pitti) wrote :

FTR, there's also "if laptop-detect; then [do laptop stuff".

Revision history for this message
David Henningsson (diwic) wrote :

laptop-detect is probably a better tool, if it's working. I tried it on saucy, and it failed: bug 1213922

Revision history for this message
Martin Pitt (pitti) wrote :

Try running it as root :) (I updated bug 1213922)

information type: Private → Public
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Thanks for filing this bug. This project is being shut down as it’s not actively monitored by any team or individual. This bug will not be deleted but will be closed as <<Won’t Fix?>>. If this bug is something that is still affecting a product in Ubuntu, you can take one of the following steps to report this bug correctly:

File a new bug on the right distribution/package (‘ubuntu/linux’ for example).

Or

Set the visibility on this bug as public, and then affect the right distribution/package. Keep in mind at that point all information would become public on this particular bug report.

Changed in intel:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.