[alsa-devel] [RFC] Add scenario management

[Takashi Iwai]

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