[alsa-devel] [PATCH 0/3] alsa-lib: UCM - Use Case Manager

[Niels Mayer]

On Wed, Sep 22, 2010 at 11:48 AM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> Having looked at the implementation briefly I also note that you've
> kept the procedural specification of the control settings in your
> configuration file format.  As I outlined previously I do have serious
> concerns about this as a model for users to work with (orthogonally to
> the actual implementation which must come down to a procedure at present
> due to the ALSA API, something I hope to provide features to avoid in
> the future).
>
> If we make everything procedural now it will become much harder to back
> out of it later, and I would hope that one of the things that use case
> management can do is ensure that users only need to specify their goal
> states and don't need to deal with the mechanics of how to achieve them
> except in exceptional circumstances.

I completely agree. This problem seems best solved by "logic
programming" and ontologies describing both hardware capabilities,
constraints, as well as the applications needs and requirements. Such
problems tend to have multiple solutions and often require a way for
constraints to be loosely, or multiply satisfied -- including asking
the user after narrowing down the search space to just a few equally
weighted choices (e.g. do i match the channel count of the source to
the device by duplicating channels or sending blank channels?).

There is much literature and many industry solutions employing such
simple "AI" techniques, and there's no reason why declarative
programming capabilities couldn't be built into any C-based library --
e.g. http://clipsrules.sourceforge.net http://www.gprolog.org etc.
Certainly, there is no need to "reinvent the wheel" hacking language
constructs and concepts that already exist and have some formalisms
behind them.

Example literature from a slightly different domain that could be
applied here include:
http://ebiquity.umbc.edu/get/a/publication/466.pdf ("Towards a
Declarative Framework for Managing Application and Network
Adaptations")
..................
Abstract—Cross layer optimizations are increasingly being
used in a variety of applications to improve application perfor-
mance. However most of these implementations are ad hoc and
performed on a per application basis. In this paper we propose
a declarative framework for managing application and network
adaptations. The declarative paradigm provides a much needed
clean line of separation between the high level goals and the
low level implementations. Our framework exposes the tunable
features of both the application and the network across layers of
the network stack which can then be jointly optimized. We allow
operators to control the adaptation process through operator
specified policies. [...] To support evolution, we pursue
an ontological approach and use semantic web languages such as
OWL and RDF in our framework for the policy and declarative
specifications, thereby also leveraging the inherent reasoning and
conflict resolution features of these languages. ...
.....................

Nepomuk Desktop ontologies are relevant here as well:
http://library.gnome.org/devel/ontology/unstable/nmm-ontology.html
http://library.gnome.org/devel/ontology/unstable/nfo-ontology.html
... what's needed is similar ontologies abstractly describing hardware
and providing the semantics of constraints on using the hardware --
whether it be locking semantics for concurrent or multiple access, bit
depth or sample rate matching, etc. Thus the application constraints
would need to match up against constraints posed by a "media hardware
ontology." Solving the constraint problem between application and
hardware may thus dynamically invoke sample-rate conversion, bit-depth
conversion, channel duplication or reduction, stream mixing, etc.

IMHO, such a layer could obviate the need for pulseaudio and instead
dynamically  invoke the appropriate ALSA constructs (dmix, dsnoop,
plug, etc) needed to satisfy application constraints against hardware
limitations.

-- Niels
http://nielsmayer.com