On Tue, Sep 07, 2010 at 08:17:19PM +0200, Jaroslav Kysela wrote:
On Tue, 7 Sep 2010, Mark Brown wrote:
SectionDefaults [ exec "amixer cset name='Master Playback Switch',index=2 1,1"
My idea is to have the most used commands working with the ALSA API built directly into the ucm code to not use fork/exec so much in embedded environments. But I can imagine that some system
I'm not sure how this follows on from what you're proposing above? You appear to be proposing the replacement of the lists of control settings with shell commands, then later on optimising those forks busybox style by building the relevant binaries into the library.
Currently outside of the explict sequences provided to override the default transitions the use case manager configurations are declarative rather than ordering based. This lets the user specify end states and lets the use case manager code work out the best way to accomplish those configurations which seems like a valuable property.
configurations can use this API to send events to another manager which can control another parts of the system like video, input devices, network devices and so on according the sound setup.
I do agree that this may be useful but I don't see that we need to rewrite the ALSA control management bit of things for that, the declarative style seems like a win there. I also feel that it may make more sense to do this externally to this library in a higher level tool which controls both this and other things.
Also, the possibility to generate the alsa-lib's configuration files at run-time might be a nice feature for future. I take UCM like a
This might be useful, though I'd expect that Pulse might be more useful for a lot of systems.
way to integrate all things regarding PCM streams and mixer controls together and let users / system administrators / distribution makers create the abstract layers depending their requirements.
That's my understanding of what the idea is.
It's about flexibility.
As I said above I'm concerned that you're trying to move this into something which is much more of a system level use case manager than an audio specific one, and limiting the audio domain as part of that. If we're doing too much of that then we're into the domain of the system level software that would be driving the UCM.