[pulseaudio-discuss] Configuring alsa mixers in the "off" profile.

[Tanu Kaskinen]

On Mon, 2011-10-03 at 22:13 +0300, David Henningsson wrote:
> On 10/03/2011 06:12 PM, Tanu Kaskinen wrote:
> > Hi,
> >
> > I have some hardware that needs some mixer configuration when selecting
> > the "off" profile for the alsa card in order to save power. Now that I
> > think about it, I'm not sure why the driver can't turn off the power
> > when nobody's using the device... I'll have to ask from the driver
> > developer.
> >
> > Anyway, if we assume that there's a valid reason for keeping the device
> > powered whenever the mixer element isn't in the "Off" position, how
> > should we handle this in Pulseaudio? My suggestion is to add an "off
> > path" to profile sets. That is, the profile set configuration file would
> > have an option in the [General] section called "off-path", which would
> > have a path name as its value. Whenever the "off" profile is activated,
> > the "off path" is activated too.
> >
> > Does that sound ok?
> 
> Just as an alternative, without having thought through which one is 
> better, what if this is deduced by the paths?
> 
> E g, when switching from path A to path B, that would mute everything 
> not specified in path B. Switching to the "Off" profile would then 
> implicitly mute everything. Would that be reasonable?

I'm not sure that would work in this case. The mixer element is an
enumeration with states "Off", "Rx" and "Tx". I've been told that it
controls whether the FM radio is powered on (and whether it's in the
reception or transmission mode). Of course, the logic could also include
a rule that if one of the options for an enumeration is "Off", that will
be used unless something else is specified.

I'm not sure that such logic would be safe in the desktop environment -
currently Pulseaudio won't touch any mixer elements that it doesn't know
about. With this logic, however, all switches would be set to off,
without knowing what the effect will be.

The "off-path" solution should be also much simpler to implement than
the "auto-mute" logic that you suggested, but of course, if the
"auto-mute" is deemed a clearly superior solution, then I guess such
"off-path" feature would not have a chance of getting merged to
upstream.

> As a side note, you seem to do more of the embedded side of things. What 
> is your take on UCM and would using that solve / pose a third solution 
> to this problem in this case?

Yes, UCM would most likely be a fine solution for this and other
problems with alsa mixers. Adopting it at this point for the product
would be too much work, however...

-- 
Tanu