[alsa-devel] Required/preferred multichannel order for ALSA
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
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
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.
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
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.
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
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
participants (4)
-
Liam Girdwood -
Mark Brown -
Ricardo Neri -
Takashi Iwai