[alsa-devel] [RFC] ALSA scenario API

Liam Girdwood lg at opensource.wolfsonmicro.com
Tue Oct 23 00:11:47 CEST 2007

On Fri, 2007-10-19 at 11:14 +0200, Takashi Iwai wrote:

> About PCM: if we implement again this kind of things in the driver, we
> may have a virtual PCM stream for the default use and other fixed PCM
> streams.  They can be opened exclusively, and the default stream opens
> different H/W stream according to the current scenario.  (BTW, still a
> question remains: when the scenario switch happens on the fly during a
> PCM stream being used, what should be done?)

This probably depends on the scenario change and probably wont matter
for most changes e.g. hifi playback then headphone insertion (same pcm)
or hifi playback then phone call (different PCM - stop hifi then start
voice). I suppose the PCM option was more for scenario audio type e.g.
all system sound use pcm:0.2, all voice use pcm:0.1, etc

> Or, simply alsa-lib checks the current scenario value and chooses the
> appropriate preset setup.  This would work well (at least for
> alsa-lib, not salsa-lib - such a complicated implementation is outside
> the scope of salsa-lib).  

This is what's working on the OpenZaurus atm. There is a daemon that
alsactl restores a scenario based upon events. i.e. there is an
asound.state for each anticipated use case (scenario). 

This works well for routing audio (and saving power) but cant tell apps
what scenarios are supported or the sink/source pcm.

> This user-space solution (for PCM) has
> another advantage that it's easier to handle PCM setups for multiple
> streams.  For example, suppose we use "scenario" for speaker setup.
> emu10k1 uses multiple PCM streams for 4.0/5.1 surrounds, and the
> driver-side implementation wouldn't work unless it reflects to
> alsa-lib setup.

Imho, the quickest way in user space (without using alsa-lib or salsa)
for route, alias and pcm would probably be to extend alsactl (or make a
new lib based on alsactl). This would easily give the scenario route
changing (already mostly done) and would need simple enough code to add
options to get aliases and PCM's. 


More information about the Alsa-devel mailing list