At Fri, 2 Oct 2009 11:58:47 +0200 (CEST), Jaroslav Kysela wrote: > > On Fri, 2 Oct 2009, Takashi Iwai wrote: > > > At Thu, 1 Oct 2009 11:47:14 +0200, > > Stefan Schmidt wrote: > >> > >> Hello. > >> > >> This patchset add support for scenario management, aka use cases, in alsa-lib > >> and example programs in alsa-utils. It allows to adjust the current audio kcontrol > >> settings from a prespective of a changed use case like the switch from listening > >> to music on your phone to an incoming phone call and back. > > > > Great, I've been waiting for this :) > > > >> To achieve this it offers control aliasing for playback, capture master and > >> switch as well as the option to post- and prefix a sequence of control changes > >> avoiding pops and other unwanted noise. > >> > >> This is of course not meant to replace gstreamer, PulseAudio or a sound server, > >> but is meant to work in tandem with such audio software. We think alsa-lib is > >> the best place for this as it will be used on small embedded system which only > >> use alsa from the full stack of audio libs in linux. We see potential for > >> desktop usage as well though. > > > > Agreed. If any need, I can merge it to salsa-lib, too. > > I'm not very persuaded to merge such thing to alsa-lib (at least not to > alsa-lib.so file - I may accept another library in the alsa-lib package). Hm, I don't find it so problematic to merge it since the scenario stuff is pretty clean and doesn't drag any other dependency into it. I understand that merging to alsa-lib would bring less hustle for developers. It's simply there. OTOH, if scenario is supposed to be expanded fast, it'd be safer to stay as a separate library. And, another bonus is that it can be re-used for salsa-lib without changes. So, the biggest question is how stable scenario is, especially from API viewpoint. Merging into alsa-lib means that the stuff could be considered as a part of LSB in future, too. > My comments: > > 1) configuration syntax > > - I know, simple text files are fine, but there are some structured > things - we have already configuration parsers in alsa-lib for > structured texts which can be migrated to XML some day This is always a question. IMO, a simple text file parser is OK as long as it's really simple. Reusing alsa-lib parser wouldn't save much code. If more structural configuration is required, we should reconsider what to use. But, this means anyway a major API change, and this shouldn't happen so much. > 2) mixing high-level and low-level things > > - the idea is to "hide" some hardware details introducing some > abstraction, but the scenario API ended with "ctl interface" instead > using a mixer API for apps? Take a look at ASoC drivers. Many (most?) of them are not suited well for mixer abstraction at all. Accessing directly ctl interface is far easier for them. > - I would like to see handling all "virtual card" stuff in the scenario > API, so user chooses one scenario and gets mixer controls, > preconfigured pcm devices for playback and capture, rawmidi devices, > timer devices etc.; it means that user can divide - for example - one > physical card to more virtual ones with a custom configuration This would be a nice extension. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
