[alsa-devel] Only one element for multichannel mixer controls please!
perex at perex.cz
Mon Oct 27 11:12:59 CET 2008
On Mon, 27 Oct 2008, Takashi Iwai wrote:
> At Mon, 27 Oct 2008 10:20:48 +0100 (CET),
> Jaroslav Kysela wrote:
> > On Mon, 27 Oct 2008, Takashi Iwai wrote:
> > > IMHO, a big part of the problem is its overly complex layers and
> > I agree. Some layers should be merged and simplified.
> > > old-style mixer API (in addition to complete lack of documentation).
> > I don't understand what you mean old-style API. API inside alsa-lib or
> > smixer API for applications? If it's the second case, what you imagine as
> > right mixer API for apps?
> In my mind, mostly about the external API:
> - what if an element has 2 switches but 4 volumes?
Do we need to handle such situation? If we start to describe the exact
routes we end in more deep hell. I would propose to leave mapping 1:1 and
join requests for 2 switches together (with eventual value change event
returned back to app). Eventually, we can return a volume/switch map to
application which controls are joined.
> - are common, playback and capture exclusive?
It's just about to add one function returning this information.
> - exclusive switch is often messy; whether it's a radio button or a list,
> it's a question of UI, not about API - a list is more appropriate
We need to add this to documentation.
> - why attach/deteach/load ops needed in addition to open/close?
> - why hctl?
> - what is mixer class and why necessary?
> - why both snd_mixer_elem and snd_mixer_selem exist?
It's exactly what I meant by simplification and merging. Anyway, all
mentioned things are mostly cosmetic. They imply no dramatic changes for
> But, about internal API, too:
> - the abstraction concept is nowhere documented
> - the internal API is nowhere documented
> - simple_none.c is still buggy (the common elements aren't handled
> properly any existing mixer apps including alsamixer)
> > > The plugin solution doesn't work well because you are tring to graft
> > > orange and apple.
> > Please, explain.
> Well, in your scenario, each driver writer is supposed to create a new
> C smixer plugin. But, providing both is a hard work because they are
> really two different things. In the current situation without any
> good information how and what to do, grafting two different things
> doesn't work well.
> The plugin framework is pretty simple. But, this means that you owe
> so many things (almost everything) in the plugin itself. That's why
> no one can start on it. At least, we need good examples codes and a
> good helper library for that.
I agree, it's time to create a helper library and some documentation (or
better documented code example).
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel