Multiple channels mapping

Multiple channels mapping

[Patrick Lai]

Hi,

The DSP I am working on supports channel assignments similar to ALSA
route plug-in described in this link http://drona.csa.iisc.ernet.in
/~uday/alsamch.shtml.
I am currently looking a way to pass channel/speaker mapping
information of PCM stream( i.c channel 0 -> Front Left speaker, channel
1 -> Front Right speaker) to ALSA driver. I looked at latest kernel
tree and don't think there is already provision for my purpose. Can
anyone confirm? If I were to improvise a way to pass channel/speaker
mapping information, should I follow the same approach similar to how
bits per sample and other hardware parameter is passed?

Thanks
Patrick

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Multiple channels mapping

[Takashi Iwai]

At Tue, 07 Feb 2012 17:02:00 -0800,
Patrick Lai wrote:
> 
> Hi,
> 
> The DSP I am working on supports channel assignments similar to ALSA
> route plug-in described in this link http://drona.csa.iisc.ernet.in
> /~uday/alsamch.shtml.
> I am currently looking a way to pass channel/speaker mapping
> information of PCM stream( i.c channel 0 -> Front Left speaker, channel
> 1 -> Front Right speaker) to ALSA driver. I looked at latest kernel
> tree and don't think there is already provision for my purpose. Can
> anyone confirm? If I were to improvise a way to pass channel/speaker
> mapping information, should I follow the same approach similar to how
> bits per sample and other hardware parameter is passed?

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.


thanks,

Takashi

Re: Multiple channels mapping

[Clemens Ladisch]

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.

I really should complete those patches ...


Regards,
Clemens

Re: Multiple channels mapping

[Takashi Iwai]

At Wed, 08 Feb 2012 10:18:29 +0100,
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?

BTW, the channel-mapping info can be useful for the automatic plug
layer, too.  It would re-route the channels when not following
ALSA-standard maps automatically, for example.  (Remember some old
AC97 chips.)

More question is whether this information should be available before
or after hw_params setup.


thanks,

Takashi

Re: Multiple channels mapping

[Clemens Ladisch]

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.

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

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


Regards,
Clemens

Re: Multiple channels mapping

[Mark Brown]

On Wed, Feb 08, 2012 at 10:23:45AM +0100, Takashi Iwai wrote:
> Clemens Ladisch wrote:
> > Takashi Iwai wrote:

> > 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?

It would be really good if it could support dynamic remapping of
channels - for example, with most of the devices I work on you just get
a bunch of audio channels presented to the mixing core of the device and
can send them wherever it amuses you to do so at runtime, there's no
fixed assignments.

Re: Multiple channels mapping

[Takashi Iwai]

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.


thanks,

Takashi