30.10.2013 01:12, Aaron Plattner kirjoitti:
On 10/24/2013 04:31 PM, Anssi Hannula wrote:
Hi!
I just noticed while testing the ALSA HDMI channel remapping code that my NVIDIA codec 0x10de0015 does not seem to follow the Audio Sample Packet (ASP) channel mapping (set by verb F34h as per HDA spec 7.3.3.41) when playing back stereo audio.
This can be reproduced by e.g.: $ speaker-test -c2 -Dhdmi:CARD=NVidia,DEV=0 -m FR,FL The channels are reversed compared to what the printout is (i.e. the codec plays the streams straight-through instead of swapping channels as instructed).
E.g. this works expectedly, however: $ speaker-test -c4 -Dhdmi:CARD=NVidia,DEV=1 -m FR,FL,RR,RL
(note that recent sound git master or for-next is needed for these kind of remappings to work properly at all)
On Intel HDMI codec 0x80862806 both work.
While stereo right-left swapping is admittedly a rather corner-case situation, I guess we should probably refuse such chmaps when they are not supported.
Aaron, do you have any information on whether this affects all NVIDIA HDMI codecs?
I don't know much about the audio side of things, I'm afraid. The more knowledgeable people I asked about this said that they would expect a L/R swap to work.
OK, well, it does not. But as noted, only on stereo playback. When there are more than 2 channels everything (including the FL/FR swap) works fine.
I also verified with "Get ASP Channel Mapping" (which was mentioned below) that the mapping is 0=>1 and 1=>0. It just doesn't seem to take effect on 2-channel playback (but works fine on an Intel codec).
My guess is that it may have got something to do with the fact that 2-channel playback can use a different layout where each HDMI Audio Sample Packet contains 4 samples for each channel, whereas in multichannel playback the ASP packet contains 1 sample for each channel, and the ASP channel mapping is somehow only affecting the latter multichannel layout mode.
In case you can't confirm if this issue exists on other codecs than 0x10de0015, I guess I can try to find a tester with one of the later codecs, and if the same issue happens there, just add a tweak to disallow 2-channel FR/FL map on all nvidia codecs. While it would be nice to fix it for later codec revisions (if it isn't already), it is not like it is a big feature loss :)
Thanks for looking into it anyway.
"In fact the CTR/LFE channels have their mappings swapped.
The default mapping is: Converter channel 0 mapped to ASP slot 0 Converter channel 1 mapped to ASP slot 1 Converter channel 2 mapped to ASP slot 3 Converter channel 3 mapped to ASP slot 2 Converter channel 4 mapped to ASP slot 4 Converter channel 5 mapped to ASP slot 5 Converter channel 6 mapped to ASP slot 6 Converter channel 7 mapped to ASP slot 7
In theory, you should be able to map any incoming channel, to any outgoing channel.
You can look at section7.3.3.41 of the HDA spec (Audio Sample Packet (ASP) Channel Mapping) for the information on this.
There is a way to manually send verbs and get their responses to see if the HW is programmed correctly.
To do this, you have to use the Immediate Command and response registers to issue a "Get ASP Channel Mapping" for each channel. The other parameters needed are the codec id and node id of the associated converter node.
It is a bit involved, but I can send you the info. If you have the codec and node ids already, it is actually relatively simple."