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.
