At Wed, 21 Nov 2007 16:52:20 +0100, Clemens Ladisch wrote: > > Jaroslav Kysela wrote: > > On Wed, 21 Nov 2007, Clemens Ladisch wrote: > > > Takashi Iwai wrote: > > > > Yes, querying channel mapping is another missing piece with popular > > > > demand. > > > > > > > > The implementation would be easy, I guess. But we have to define the > > > > way to inform this from kernel to user space: whether create a new > > > > ioctl or extend the existing ones (if possible)... > > > > > > It's just metadata that describes a PCM device, so I think we should use > > > TLV for this. > > > > > > The existing struct snd_ctl_tlv uses a single integer to identify > > > control elements. We could restrict control numid's to 31 bits and > > > use the upper bit to signal that this value includes device type and > > > device number in the lower bits, if we want to reuse the same TLV > > > ioctls. > > Using a ioctl on the ctl device is difficult if the information is > dependent on the hw_params, so this isn't a good idea. Yep. > > 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 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. BTW, what latency information do you have in mind? Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
