[alsa-devel] NVIDIA HDMI: Channel remapping does not work for stereo?

[Anssi Hannula]

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."


-- 
Anssi Hannula