On Sat, 22 Dec 2007, Lennart Poettering wrote: > On Tue, 04.12.07 16:42, Jaroslav Kysela (perex@xxxxxxxx) 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@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
