[alsa-devel] Channel mapping
tiwai at suse.de
Wed Nov 21 16:36:54 CET 2007
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.
> > 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?
More information about the Alsa-devel