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:
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.
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