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? - are common, playback and capture exclusive? - 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 - 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?
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.
Takashi