On Mon, Sep 20, 2010 at 11:26 AM, Colin Guthrie <gmane@xxxxxxxxxxxxxx> wrote: > Hi Jaroslav, > > 'Twas brillig, and Jaroslav Kysela at 07/09/10 15:42 did gyre and gimble: >> On Tue, 7 Sep 2010, Liam Girdwood wrote: >> >>> Hi Jaroslav, >>> >>> Any update on this ? I have someone scheduled to write new use case >>> files and someone else ready to add PA support. >> >> Hi, >> >> I'm working on this. Unfortunately, I have other things which interrupts >> this work. The actual code is at: >> >> http://git.alsa-project.org/?p=alsa-lib.git;a=shortlog;h=ucm > > Has there been any progress on the UCM stuff? I'm quite interested to > see how this will develop from a PA perspective. It does have some > impact on work that I've been wanting to do for a while in PA so the > sooner this is available in ALSA the sooner I can start thinking about > some of the knock on effects. I know Liam is intending to do some work > on PA too to integrate UCM once the API has stabilised, so I'm obviously > keen to encourage that too :D Since progress on UCM seems to have stalled, I'd also like to chip in and say that it would be great to see UCM pushed to mainline as soon as possible. I'm a software engineer at Garmin, responsible for system-level audio support on Linux-based personal navigation devices, and UCM would *really* help to simplify the management of audio state on those devices. In fact, I've been hurting for something like UCM for so long that I'm already developing against the version that Liam has posted to the list. I not entirely convinced that Jaroslav's proposed changes to UCM will add much value to overall functionality. The reworked API seems more clumsy and confusing to me, and I think it's a bad idea to make UCM responsible for coordinating audio state management throughout userspace -- as Mark B. said, that responsibility would seem to be better left to some other entity who would be the sole consumer of UCM API in the system (e.g., pulseaudio), which is really no different from the current situation for basic playback or capture through Alsa, i.e., if multiple processes want to playback/capture PCM data at the same time, then some other entity must coordinate access (e.g., dmix, pulseaudio). >From the PND perspective, there is often a complex intermix of business logic and asynchronous system events (from both hardware and software) driving the audio hardware state changes. I can tell you from experience that it is a nightmare to have to pass such arbitrary information between processes for the purposes of making even the simplest of policy decisions for system-wide audio state. If it is truly desired to turn UCM into userspace's central manager and coordinator for audio state, then it absolutely must provide a clear and flexible way to pass arbitrary state variables through the system, and also a generic mechanism for specifying how the audio policy must change based on those state variables. A superb and worthy ideal, perhaps, but it's a tall order, and I don't see it becoming a viable reality any time soon. I think the proposed switch to using alsa-lib's present conf file parser code may be worth doing (even though I find the syntax to be uglier). Otherwise, the only thing I would really like to see added to UCM (after it gets mainlined!) is a more generic mechanism for aliasing mixer control names, instead of how it is currently limited to aliasing master playback/capture volumes and master playback/capture switches. On PNDs at least, it is often necessary to read/write some mixer controls directly, e.g., for mic gain, and so it's a pain when mixer control names differ across codecs. It would be great if Alsa provided for such aliasing, instead of leaving developers to rely on custom solutions. Regards, Chris Winter _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
