[alsa-devel] NVIDIA HDMI: Channel remapping does not work for stereo?
tiwai at suse.de
Wed Oct 30 07:34:13 CET 2013
At Wed, 30 Oct 2013 01:39:16 +0200,
Anssi Hannula wrote:
> 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 126.96.36.199)
> >> 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.
Thanks for intensive tests. I agree that disabling FL/FR for 2
channels would be a good enough fix.
> > "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 section188.8.131.52 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
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
More information about the Alsa-devel