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 time. Liam
