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