No subject

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