At Mon, 27 Oct 2008 09:53:30 +0100 (CET), Jaroslav Kysela wrote: > > On Mon, 27 Oct 2008, Takashi Iwai wrote: > > > And, the current smixer abstraction sucks. Really. > > Because we do not have any abstraction available at this moment. The > smixer API is not bad itself, it's just about internal alsa-lib code and > how to implement abstraction layers. Also, for applications using PCM > devices we need to add two functions handling all used channels like this: > > /* for PCM stream volume control */ > int snd_pcm_mixer_element(snd_pcm_t *pcm, snd_mixer_t *mixer, snd_mixer_elem_t **elem); > /* for Master volume control - will not be available for recording */ > int snd_pcm_mixer_master(snd_pcm_t *pcm, snd_mixer_t *mixer, snd_mixer_elem_t **elem); > > My idea is to describe the correlations between PCM and mixer in the > standard .conf files defining PCM devices. > > The internal smixer interface can be extended using dynamic C library now, > but the question is, who will write C modules for all cards. I also > prepared python interface to allow fast smixer prototyping. Another > possibility is to create a C module which will parse a text configuration > file describing the abstaction. Yes, I know these. Still, nothing is there over years. And I'm afraid of being so forever. IMHO, a big part of the problem is its overly complex layers and old-style mixer API (in addition to complete lack of documentation). The plugin solution doesn't work well because you are tring to graft orange and apple. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
