[alsa-devel] Required/preferred multichannel order for ALSA
ricardo.neri at ti.com
Sun Apr 29 05:23:36 CEST 2012
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 . It was also mentioned that an API to set/get the channel
>>> mapping was going to be implemented ; I tried to find it without
>>> success. As  and  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.
>> 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.
More information about the Alsa-devel