[alsa-devel] [RFC] Add scenario management
tiwai at suse.de
Fri Oct 2 12:12:51 CEST 2009
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
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.
More information about the Alsa-devel