UCM/DAPM - saving power when idle?

UCM/DAPM - saving power when idle?

[David Henningsson]

I don't deal much with ASoC, so sorry if I'm missing something obvious 
here...

When a certain use case is activated, that would then activate some DAPM 
widgets, causing the codec to consume more power. So, we should 
essentially avoid this unless we're actually playing back/recording. 
But, why isn't there a "disable all use cases" command, or possibly an 
"idle" command? (That, essentially, e g pulseaudio should set whenever 
playback/recording stops)

Or; the option would be that the codec is actually powered down, but 
only activates itself when there is a stream; but this looks like it 
could cause problem with loopback paths (e g listening to FM radio, 
where there are no streams passing through CPU/main memory).

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: UCM/DAPM - saving power when idle?

[Liam Girdwood]

+ Mark and Arun,

On 01/11/12 10:39, David Henningsson wrote:
> I don't deal much with ASoC, so sorry if I'm missing something obvious here...
>
> When a certain use case is activated, that would then activate some DAPM
> widgets, causing the codec to consume more power. So, we should essentially
> avoid this unless we're actually playing back/recording. But, why isn't there
> a "disable all use cases" command, or possibly an "idle" command? (That,
> essentially, e g pulseaudio should set whenever playback/recording stops)
>

> Or; the option would be that the codec is actually powered down, but only
> activates itself when there is a stream; but this looks like it could cause
> problem with loopback paths (e g listening to FM radio, where there are no
> streams passing through CPU/main memory).
>

DAPM will only power on the associated widgets if there is a valid source -> 
sink path and the stream is active (e.g. we set a path and perform a playback 
or capture). So if pulseaudio sets a playback use case and then keeps the 
playback open (even when playing silence) DAPM will keep the widgets enabled.

DAPM also handles the sidetone or FM radio task as described above too by 
detecting the source -> sink between two widgets that are not enabled by the 
CPU PCM devices (e.g. not DACs or ADCs, etc) and will then power this path.

Fwiw, There is nothing stopping us adding a low power idle UCM modifiers for 
each use case atm with the current UCM code base. I would imagine a single 
"idle" modifier could be used by most of the devices on a UCM verb, but there 
may need to be additional idle modifiers to deal with any audio artifacts 
generated by some devices when powering ON/OFF.

Liam

Re: UCM/DAPM - saving power when idle?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 681 bytes --]

On Thu, Nov 01, 2012 at 03:26:16PM +0000, Liam Girdwood wrote:

> + Mark and Arun,

David, *ALWAYS* CC maintainers.

> DAPM also handles the sidetone or FM radio task as described above
> too by detecting the source -> sink between two widgets that are not
> enabled by the CPU PCM devices (e.g. not DACs or ADCs, etc) and will
> then power this path.

...and of course if the driver for whatever device is provding the
analogue input is able to update the state of the source then that will
integrate nicely with ASoC and we can do the automatic power up/down in
the same way as we do for DACs and ADCs.  There's a standard helper for
integrating with accessory detect like this.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]