No subject

Fri Jul 31 19:24:53 CEST 2009

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.


Chris Winter

More information about the Alsa-devel mailing list