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@perex.cz Linux Kernel Sound Maintainer ALSA Project