[alsa-devel] Channel mapping

Takashi Iwai 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.

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


More information about the Alsa-devel mailing list