[alsa-devel] Softvol controls

[Jaroslav Kysela]

On Sat, 22 Dec 2007, Lennart Poettering wrote:

> On Tue, 04.12.07 16:42, Jaroslav Kysela (perex at perex.cz) wrote:
> 
> > > No, there is no API to get the id mapping.
> > > And I guess we can't do it because there is no 1:1 mapping between
> > > ctl_elem and mixer_selem.  It's N:1.
> > 
> > I don't think that application should know about this mapping.
> > 
> > I think that we have to provide API giving a mixer control element for 
> > opened PCM handle, otherwise applications might use hacks like 
> > suggested snd_ctl_elem_info_is_user() checks.
> 
> Wouldn't it be possible to just provide a snd_mixer_elem_is_user()
> function? Would be fine to solve my task, too...

User elements can be used for other purposes, too. So 
snd_mixer_elem_is_user() is not sufficient to give you enough information.

> > > > I figure there is no useful documentation or even example how this is
> > > > supposed to work? Hmm, is there any real documentation available which
> > > > describes the relation of ctl, hctl, mixer and smixer at all? For the
> > > > uninitated the whols structure looks overly complex and redundant.
> > > 
> > > Yes, it's overly complex.  The mixer abstracion is what I'd really
> > > love to clean up, maybe better to write from scratch.
> > 
> > I think that we might remove only 'mixer' and simplify initalization from 
> > the user side, but each time I tried to think about an optimal mixer 
> > interface, I ended with the current 'simple mixer API'.
> 
> Quite frankly, the whole structure of ctl, hctl, mixer and smixer is
> one of the weakest points in the ALSA API. While it might make sense
> to have these internally, I belive that exposing them all in the API was a
> bad idea. (But actually, I only understand ALSA in parts, so maybe I
> just am blind)

I'm not sure. I always recommended to use smixer API for standard 
applications, because it contains abstraction (at least some, but it will 
improve). hctl is just a cache for ctl (probably might be integrated to 
ctl layer) and I'm thinking to remove mixer layer (but I need some time to 
create a good proposal).

> > > I guess PA could use ctl API better than mixer API because it requires
> > > only certain elements like Master or PCM.  You can simply take
> > > "Master Playback Control" with MIXER iface for master volume and
> > > "Master Playback Switch" for master mute switch.  Of course, you'll
> > > take care of number of channels or value range, but it's also same for
> > > mixer API, too.
> > 
> > I don't agree here. The simple mixer layer should be used, because it 
> > covers at least some abstraction. In my recent changes, we have 
> > possibility to use python for fast prototyping of simple mixer backends 
> > (see alsa-lib/modules/mixer/simple/python directory how fast with minimal 
> > code can be backend implemented). Unfortunately, main problem will be
> > probably the work to cover all cards.
> 
> So, what does this mean for me? As long as I have some way to detect
> whether a mixer element is software-only I am happy. 
> 
> Should I now be following yours, or Takashi's advice? Should I wait
> for a new interface to be added to the ALSA API?

Please, wait. I suggested to add new function to PCM API to detect
which mixer element is related to a PCM stream.

						Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project