[alsa-devel] Multiple channels mapping

Takashi Iwai tiwai at suse.de
Fri Feb 10 12:05:53 CET 2012

At Wed, 08 Feb 2012 12:32:17 +0100,
Clemens Ladisch wrote:
> Takashi Iwai wrote:
> > Clemens Ladisch wrote:
> >> Takashi Iwai wrote:
> >>> Currently the channel-mapping information is a missing piece in ALSA
> >>> framework, and it's a very long-standing item on my TODO list.
> >>>
> >>> The implementation itself should be easy, but the only question is the
> >>> API design.  If you have a good proposal, please speak up.
> >>
> >> TLVs on media controller entities.
> >
> > Well, my concern is that it might be too far from the other PCM
> > stuff.  How the implementation would look like?
> There is one media controller device node per device (= ALSA card),
> containing multiple entities (similar to how a ctl device contains
> multiple controls).  /dev/media42 _is_ separate, but the entity that
> represents a PCM device is handled by the PCM code, so it would be
> possible to have a shortcut to get a PCM device's TLVs directly.

My concern is that accessing to different device files via yet another
API in alsa-lib would be unnecessary overhead.  (Since such
information is demanded to be accessed through the normal ALSA API, we
need a support in alsa-lib, anyway.

> > More question is whether this information should be available before
> > or after hw_params setup.
> This is pretty much static information, which is available even when the
> PCM device isn't opened.

If it's a static information that can be represented in TLV, we can
provide it via the existing control API?

Meanwhile, the channel-mapping isn't always static.  As Mark
suggested, the channel mapping can be changed dynamically later.  Some
HD-audio codec allows it, and HD-audio controller allows the arbitrary
stereo-wise mapping, too.

So, how flexible should it be -- it's a big question.  If it's
completely free-mappable, a style like TLV doesn't fit at all.  In
that case, we may need some mechanism like hw_constraint, too.
OTOH, If it's something to select, providing a list of available modes
would be feasible.

> > BTW, the channel-mapping info can be useful for the automatic plug
> > layer, too.
> And if there is a need for channel mapping information of ALSA plugins,
> there needs to be a userspace library for the media controller API.

I believe we need the alsa-lib, especially plugin access.



More information about the Alsa-devel mailing list