Required/preferred multichannel order for ALSA

Required/preferred multichannel order for ALSA

[Ricardo Neri]

Hi Takashi, list,

I am implementing multichannel support for HDMI on Texas Instruments' 
OMAP4. I would like to know if ALSA mandates a specific channel order or 
has a preferred one.

I tried to find some guidance in alsa-lib or in the alsa driver. All I 
could find is the order described in speaker-test: 
FL/FR/RL/RR/C/LFE/SL/SR. This order seems to be in use due to historical 
reasons [1]. It was also mentioned that an API to set/get the channel 
mapping was going to be implemented [2]; I tried to find it without 
success. As [1] and [2] are very old posts, I was wondering if the 
situation has changed.

My question arises from the fact that HDMI audio uses the channel 
ordering defined in CEA-861 section 6.6.2, which is different from what 
speaker-test expects. This also different from the order that SMPTE 320M 
specifies. OMAP4 is able to alter the channel mapping, so I could match 
what ALSA expects if such required/preferred order exists.

Thanks in advance for your comments.

Ricardo


[1].http://www.spinics.net/lists/alsa-devel/msg24444.html
[2].http://www.spinics.net/lists/alsa-devel/msg24495.html

Re: Required/preferred multichannel order for ALSA

[Liam Girdwood]

On Thu, 2012-04-26 at 16:33 -0500, Ricardo Neri wrote:
> Hi Takashi, list,
> 
> I am implementing multichannel support for HDMI on Texas Instruments' 
> OMAP4. I would like to know if ALSA mandates a specific channel order or 
> has a preferred one.
> 
> I tried to find some guidance in alsa-lib or in the alsa driver. All I 
> could find is the order described in speaker-test: 
> FL/FR/RL/RR/C/LFE/SL/SR. This order seems to be in use due to historical 
> reasons [1]. It was also mentioned that an API to set/get the channel 
> mapping was going to be implemented [2]; I tried to find it without 
> success. As [1] and [2] are very old posts, I was wondering if the 
> situation has changed.
> 
> My question arises from the fact that HDMI audio uses the channel 
> ordering defined in CEA-861 section 6.6.2, which is different from what 
> speaker-test expects. This also different from the order that SMPTE 320M 
> specifies. OMAP4 is able to alter the channel mapping, so I could match 
> what ALSA expects if such required/preferred order exists.
> 
> Thanks in advance for your comments.
> 
> Ricardo
> 
> 
> [1].http://www.spinics.net/lists/alsa-devel/msg24444.html
> [2].http://www.spinics.net/lists/alsa-devel/msg24495.html

A lot of hardware now can remap channels to suit the use case so it
would probably be good to have an ALSA API to get/set the mappings.

This seems like it would be a good subject for the BoF.

Liam

Re: Required/preferred multichannel order for ALSA

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 458 bytes --]

On Fri, Apr 27, 2012 at 10:21:37AM +0100, Liam Girdwood wrote:

> A lot of hardware now can remap channels to suit the use case so it
> would probably be good to have an ALSA API to get/set the mappings.

As well as being able to reorder things there's also the cases where a
multi-channel link can be assigned to send several independant streams
rather than actually be a multi-channel link.

> This seems like it would be a good subject for the BoF.

Yes.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Required/preferred multichannel order for ALSA

[Takashi Iwai]

At Fri, 27 Apr 2012 10:57:34 +0100,
Mark Brown wrote:
> 
> On Fri, Apr 27, 2012 at 10:21:37AM +0100, Liam Girdwood wrote:
> 
> > A lot of hardware now can remap channels to suit the use case so it
> > would probably be good to have an ALSA API to get/set the mappings.
> 
> As well as being able to reorder things there's also the cases where a
> multi-channel link can be assigned to send several independant streams
> rather than actually be a multi-channel link.

True.  OTOH, separating to different streams can be done mostly
without extra configuration.  The driver may neeed to handle the
open/close race, but basically splitting can be done uniquely just by
the number of channels.  Of course, there might be other excpetions
and corner cases, though.


Takashi

Re: Required/preferred multichannel order for ALSA

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 700 bytes --]

On Fri, Apr 27, 2012 at 02:15:57PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > As well as being able to reorder things there's also the cases where a
> > multi-channel link can be assigned to send several independant streams
> > rather than actually be a multi-channel link.

> True.  OTOH, separating to different streams can be done mostly
> without extra configuration.  The driver may neeed to handle the
> open/close race, but basically splitting can be done uniquely just by
> the number of channels.  Of course, there might be other excpetions
> and corner cases, though.

Yes, I think it's mostly just a slight generalisation of the same
problem from an implementation point of view.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Required/preferred multichannel order for ALSA

[Takashi Iwai]

At Fri, 27 Apr 2012 10:21:37 +0100,
Liam Girdwood wrote:
> 
> On Thu, 2012-04-26 at 16:33 -0500, Ricardo Neri wrote:
> > Hi Takashi, list,
> > 
> > I am implementing multichannel support for HDMI on Texas Instruments' 
> > OMAP4. I would like to know if ALSA mandates a specific channel order or 
> > has a preferred one.
> > 
> > I tried to find some guidance in alsa-lib or in the alsa driver. All I 
> > could find is the order described in speaker-test: 
> > FL/FR/RL/RR/C/LFE/SL/SR. This order seems to be in use due to historical 
> > reasons [1]. It was also mentioned that an API to set/get the channel 
> > mapping was going to be implemented [2]; I tried to find it without 
> > success. As [1] and [2] are very old posts, I was wondering if the 
> > situation has changed.
> > 
> > My question arises from the fact that HDMI audio uses the channel 
> > ordering defined in CEA-861 section 6.6.2, which is different from what 
> > speaker-test expects. This also different from the order that SMPTE 320M 
> > specifies. OMAP4 is able to alter the channel mapping, so I could match 
> > what ALSA expects if such required/preferred order exists.
> > 
> > Thanks in advance for your comments.
> > 
> > Ricardo
> > 
> > 
> > [1].http://www.spinics.net/lists/alsa-devel/msg24444.html
> > [2].http://www.spinics.net/lists/alsa-devel/msg24495.html
> 
> A lot of hardware now can remap channels to suit the use case so it
> would probably be good to have an ALSA API to get/set the mappings.
> 
> This seems like it would be a good subject for the BoF.

Yes.  As I added to LPC 2012 wiki page, it's a topic I'd like to
discuss in the audio microconf, too.  It's a long-standing issue,
not only for embedded devices but also PCs, especially with HDMI/DP.

Actually I've had a few different (partial) implementations, but
nothing was so convincing yet.

BTW, for the time being, the remapping itself is done in alsa-lib
route plugin.  This works when the driver is unique and supports
only a single configuration.  Then you can define the routing table
beforehand.  Take a look at alsa-lib/src/conf/cards/*.conf based on
old AC97 codecs.

OTOH, if the driver is generic (e.g. HD-audio) and supports different
configurations, it doesn't work so easily.  A more generic API is
mandatory in such a case.


Takashi

Re: Required/preferred multichannel order for ALSA

[Ricardo Neri]

Thanks to everyone for replying!
On 04/27/2012 07:12 AM, Takashi Iwai wrote:
> At Fri, 27 Apr 2012 10:21:37 +0100,
> Liam Girdwood wrote:
>>
>> On Thu, 2012-04-26 at 16:33 -0500, Ricardo Neri wrote:
>>> Hi Takashi, list,
>>>
>>> I am implementing multichannel support for HDMI on Texas Instruments'
>>> OMAP4. I would like to know if ALSA mandates a specific channel order or
>>> has a preferred one.
>>>
>>> I tried to find some guidance in alsa-lib or in the alsa driver. All I
>>> could find is the order described in speaker-test:
>>> FL/FR/RL/RR/C/LFE/SL/SR. This order seems to be in use due to historical
>>> reasons [1]. It was also mentioned that an API to set/get the channel
>>> mapping was going to be implemented [2]; I tried to find it without
>>> success. As [1] and [2] are very old posts, I was wondering if the
>>> situation has changed.
>>>
>>> My question arises from the fact that HDMI audio uses the channel
>>> ordering defined in CEA-861 section 6.6.2, which is different from what
>>> speaker-test expects. This also different from the order that SMPTE 320M
>>> specifies. OMAP4 is able to alter the channel mapping, so I could match
>>> what ALSA expects if such required/preferred order exists.
>>>
>>> Thanks in advance for your comments.
>>>
>>> Ricardo
>>>
>>>
>>> [1].http://www.spinics.net/lists/alsa-devel/msg24444.html
>>> [2].http://www.spinics.net/lists/alsa-devel/msg24495.html
>>
>> A lot of hardware now can remap channels to suit the use case so it
>> would probably be good to have an ALSA API to get/set the mappings.
>>
>> This seems like it would be a good subject for the BoF.
>
> Yes.  As I added to LPC 2012 wiki page, it's a topic I'd like to
> discuss in the audio microconf, too.  It's a long-standing issue,
> not only for embedded devices but also PCs, especially with HDMI/DP.
>
> Actually I've had a few different (partial) implementations, but
> nothing was so convincing yet.
>
> BTW, for the time being, the remapping itself is done in alsa-lib
> route plugin.  This works when the driver is unique and supports
> only a single configuration.  Then you can define the routing table
> beforehand.  Take a look at alsa-lib/src/conf/cards/*.conf based on
> old AC97 codecs.

Thanks for the advice! I could remap the channels succesfully with the 
alsa-lib route plugin. It increased the CPU usage when using 
speaker-test, though; from 2% to ~5%, according to top. I guess this is 
acceptable for now.
>
> OTOH, if the driver is generic (e.g. HD-audio) and supports different
> configurations, it doesn't work so easily.  A more generic API is
> mandatory in such a case.

Maybe I can statically remap the channels in the driver to align with 
speaker-test and post in omappedia how to remap if someone needs to. 
This in case their HDMI sinks supports a different HDMI layout.

Thanks!

Ricardo
>
>
> Takashi