[pulseaudio-discuss] [PATCH] module: new null-source module
lrg at slimlogic.co.uk
Wed Apr 27 12:04:06 PDT 2011
On Wed, 2011-04-27 at 20:29 +0200, David Henningsson wrote:
> The overall problem IMHO is that it is overly complex:
> 1) The kernel might set some basic volumes
> 2) Alsactl can store/restore volumes
> 3) Alsaucm can set volumes
> 4) PulseAudio (for the gdm user) can store/restore volumes
> 5) PulseAudio (for the logged on user) can store/restore volumes
> 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.
I agree on simplification, but UCM actually removes a layer of
complexity here as it abstracts numerous vendor/card specific Alsa mixer
controls into pre-defined use cases. i.e. we no longer have to guess
about whether device X has a control n1 or n2 or n2... to configure
audio playback on headphones etc.
Lets discuss this more in person next week !
> 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?
Yes, Maggies code is initial and basic support for UCM in pulseaudio.
It's not intended to be full UCM support (this would take a lot longer)
as it's really to get the ball rolling.
The patches basically provide the ability to :-
1) Store UCM verb and devices configuration in proplists.
2) Allow pulseaudio to change the UCM usecase verb and device.
3) Implement a jack sense module that listens for jack events.
4) Act on jack events to change UCM device.
We should probably get 1 and 2 upstream first. I know she is working on
something else atm and will probably be back to this in a few weeks
More information about the pulseaudio-discuss