[pulseaudio-discuss] [PATCH] module: new null-source module

[Mark Brown]

On Wed, Apr 27, 2011 at 08:29:34PM +0200, David Henningsson wrote:
> On 2011-04-27 20:06, Mark Brown wrote:

>> You're not really supposed to use alsaucm directly except for testing
>> and developing new configurations,

> That's reason enough to have a man page and some documentation, if you  
> ask me. (Not claiming you're the only one missing documentation though.)

Meh, there's a reason I don't write userspace code :)

> The overall problem IMHO is that it is overly complex:

> 1) The kernel might set some basic volumes

This is clearly going to happen if only as a function of the device
having power on defaults - there's no might about it, there *will* be an
initial state from the hardware but this should be consistent for every
boot so not really any issue here.

> 2) Alsactl can store/restore volumes

With UCM this shouldn't really happen (and if it does it should happen
before UCM gets into play so the UCM configuration can just overwrite
anything that happens).

> 3) Alsaucm can set volumes

Not exactly, this should (unless I've gravely misunderstood the
implementation, which is possible) be done by PulseAudio setting a use
case with UCM.

> 4) PulseAudio (for the gdm user) can store/restore volumes
> 5) PulseAudio (for the logged on user) can store/restore volumes

Presumably PulseAudio already gets the interface between these two
right.  The theory with UCM (again, assuming no massive misunderstandings 
of the final implementation on my part) is that when UCM is in play
these volumes should be set using the volume controls that the UCM
config told PulseAudio to use for the current use case and that
PulseAudio should just ignore anything else.  Setting the use case will
both set most of the controls and tell PulseAudio which controls it
should play with for runtime control, and whoever writes the use case
configuration for a given system needs to make sure that those don't
interfere with each other.

> As UCM adds yet another complexity to the equation, we need to get it  
> right, avoid races and so on. If possible, I'd like to cut away a layer  
> or two for simplicity and optimisation.

Hopefully the above clarifies; like I say, UCM configurations do have
provision for telling the system audio daemon which controls it can play
with.  Only one thing, PulseAudio, should ever be applying configuration
so there shouldn't be much problem with races.

> Btw, as I understand it, the code in PA for controlling hardware volumes  
> through UCM is not yet a part of Maggie's patches. Is that correct?

Dunno, not checked.