On 13.11.2010 02:26, Dan Christensen wrote:
Anssi Hannula anssi.hannula@iki.fi writes:
This is a known issue, the NVIDIA MCP79/7A HDMI hardware has incorrect channel mapping.
I reported this several months ago as "Wrong channel order with multichannel HDMI on MCP7A": http://www.spinics.net/lists/alsa-devel/msg35948.html (there are some earlier reports from 2009 as well)
Great, thanks for confirming it's not just me.
I'm using this workaround at the moment: pcm.!hdmi { type route slave.pcm "cards.HDA-Intel.pcm.hdmi.0:CARD=NVidia,AES0=0x4,AES1=0x82,AES2=0x0,AES3=0x2" ttable.0.0 1 ttable.1.1 1 ttable.2.4 1 ttable.3.5 1 ttable.4.2 1 ttable.5.3 1 ttable.6.6 1 ttable.7.7 1 }
I can confirm that this fixes things for me.
(not a perfect workaround as I'm hardcoding AESx instead of using the ones provided as arguments, but at least you get the idea)
I don't understand this comment, but hopefully if I just put the above in my asound.conf, all should be fine, right?
Yes, it is just that programs can't specify their own AES parameters. If everything works with your receiver, it is ok.
As for the preferred solution to this problem, as far as I understand, that would be for the driver to have some ioctl that would provide alsa-lib information about the unusual channel mapping, and alsa-lib could then remap the channels using a channel remapping plugin.
Alternatively, can the fix just be hardcoded for this audio card?
Unfortunately I don't see a way of doing that, as all HDA-Intel codecs use the same HDA-Intel.conf... Maybe someone more knowledged knows a way, though.