On Wed, Sep 22, 2010 at 11:48 AM, Mark Brown broonie@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