On Wed, 21 Nov 2007, Takashi Iwai wrote: > > > We can also encode PCM device / subdevice numbers to data structure. > > > But I think that best way is to extend channel_info PCM ioctl > > > (create new version and emulate old one - it should be quite easy to > > > implement). > > > The channel_info ioctl returns only information about one channel. > > OTOH, it's simple and easy to parse. But, certainly TLV is more > flexible for additional metadata. I also think that it's easy to iterate over all channels to get a map. > > I think we should have a more flexible ioctl that also allows us to > > describe the PCM device itself (such as volume controls that affect > > all channels, or latency information). > > Indeed, the mixer <-> PCM mapping can be useful. For such > information, the fixed size struct isn't suitable as multiple mixer > elements correspond to a single PCM channel. I think that we have already such interface, but maybe not well described and used. I would propose to use SNDRV_CTL_ELEM_IFACE_PCM for PCM mixer related controls and device & subdevice from control_id structure. In this way, we can easy group and assign all control elements to PCM substream. We may have only one problem - to identify which elements are mixer related and which are not. Maybe, we can use one bit from access flags to determine, if it's a mixer control element if interface != MIXER. 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
