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 applications. > 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 ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
