[alsa-devel] Wrong channel order with multichannel HDMI on MCP7A

[Takashi Iwai]

At Mon, 30 Aug 2010 09:20:06 -0700,
Stephen Warren wrote:
> 
> [Sorry for breaking threading by pasting the previous email into a new
> one, but I wasn't subscribed to the list then, so can't just reply...]
> 
> Anssi Hannula wrote:
> > Anssi Hannula kirjoitti keskiviikko, 28. heinkuuta 2010 05:42:09:
> > > Wei Ni kirjoitti tiistai, 27. heinkuuta 2010 10:14:37:
> > > > Hi, Takashi
> > > > MCP7x use old HW design in HDMI, they don't support channel mapping like
> > > > MCP89. It use nvhdmi_dig_playback_pcm_prepare_8ch() to prepare channel
> > > > mapping and steam id,format.
> > > > 
> > > > Anssi Hannula
> > > > Please try the following changes in patch_nvhdmi.c
> > > > static hda_nid_t nvhdmi_con_nids_7x[4] = {
> > > > 
> > > > 	/*front, rear, clfe, rear_surr */
> > > > 
> > > > -	0x6, 0x8, 0xa, 0xc,
> > > > +	0x6, 0xa, 0x8, 0xc,
> > > > };
> > > 
> > > I actually tried that already, but for some reason changing the order in
> > > nvhdmi_con_nids_7x doesn't have any effect.
> > > 
> > > Actually, disabling the whole for loop that assigns the channels in
> > > nvhdmi_dig_playback_pcm_prepare_8ch() has no effect, leading me to believe
> > > that the commands are not reaching the hardware or they are being
> > > overridden.
> > 
> > Well, I confirmed with AC_VERB_GET_CONV that they are getting through, and 
> > they are still the same in nvhdmi_dig_playback_pcm_close_8ch_7x().
> > 
> > Any idea why they are having no effect?
> 
> Anssi, As Wei mentioned above, the older MCP7x HW doesn't support this
> feature. Wei pointed out offline that this was discussed about a year ago.
> See for example:
> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2009-June/018156.html
> 
> In that message, Takashi mentioned something about fixing this in alsa-lib.
> However, I guess this didn't ever get resolved.
> 
> A couple messages later, it appears that Wu Fengguang confirmed that various
> Intel chipsets also don't support channel mapping, and have a different
> fixed mapping.
> 
> Takashi, is this still something that can/should be solved in alsa-lib?

Sure, it can be done in alsa-lib if we implement the channel-mapping API
first in the driver side :)

Basically, the driver just needs to give the channel-mapping via some
ioctl.  Then you can write an alsa-lib plugin just to convert the
channel map based on that information.  Or, eventually PulseAudio may
take that role.


thanks,

Takashi


> > > I also just noticed that the HDMI output is the only detected output, even
> > > though this board has analog audio and S/PDIF outputs as well. I'm not sure
> > > if this is related or not.
> > 
> > This was not related, updating to latest git fixed it.
> > 
> > > > -----Original Message-----
> > > > From: Takashi Iwai [mailto:tiwai at suse.de]
> > > > Sent: Monday, July 26, 2010 5:35 PM
> > > > To: Anssi Hannula
> > > > Cc: alsa-devel at alsa-project.org; Wei Ni
> > > > Subject: Re: [alsa-devel] Wrong channel order with multichannel HDMI on
> > > > MCP7A
> > > > 
> > > > At Mon, 26 Jul 2010 11:14:17 +0200,
> > > > 
> > > > \u79c1 wrote:
> > > > > At Sun, 25 Jul 2010 19:51:39 +0300,
> > > > > 
> > > > > Anssi Hannula wrote:
> > > > > > Hi all!
> > > > > > 
> > > > > > I have a motherboard with NVIDIA MCP7A HDMI audio.
> > > > > > However, multichannel audio is not mapped properly into the HDMI
> > > > > > order.
> > > > > > 
> > > > > > On 5.1, I get RL in FC, RR in LFE, FC in RL, LFE in RR.
> > > > > > 
> > > > > > Interestingly, this is not consistent with the ALSA channel order (FL
> > > > > > FR RL RR FC LFE) being passed directly to HDMI (FL FR LFE FC RL RR).
> > > > > > Instead it looks like there has been a waveformatex (FL FR FC LFE RL
> > > > > > RR; windows?) => HDMI conversion instead of ALSA => HDMI.
> > > > > > 
> > > > > > Same happens for 7.1.
> > > > > > 
> > > > > > Is it possible to set the hardware to do an ALSA => HDMI conversion
> > > > > > instead? If not, we should manually compensate for this somewhere,
> > > > > > right?
> > > > > 
> > > > > Does the patch below change anything?
> > > > 
> > > > Ah crap, it should be irrelevant.
> > > > Wei, don't MCP 7x chips support the channel mapping as MCP 89?
> > > > 
> > > > 
> > > > thanks,
> > > > 
> > > > Takashi
> > > > 
> > > > > > Somewhat relatedly, trying to output 4 channels results in silence
> > > > > > only.
> > > > > 
> > > > > Although 5.1/7.1 work?
> > > > > 
> > > > > > Trying to output 3 or 5 channels triggers a timeout with I/O error,
> > > > > > with the following in the kernel log: "ALSA pcm_lib.c:1757: playback
> > > > > > write error (DMA or IRQ trouble?)"
> > > > > 
> > > > > HD-audio doesn't support the odd number of channels in general, so
> > > > > they should be played as 4 or 6 channels.  But, it looks like
> > > > > something wrong in the setup...
> > > > > 
> > > > > 
> > > > > thanks,
> > > > > 
> > > > > Takashi
> > > > > 
> > > > > ---
> > > > > diff --git a/sound/pci/hda/patch_nvhdmi.c
> > > > > b/sound/pci/hda/patch_nvhdmi.c index 3c10c0b..7355c60 100644
> > > > > --- a/sound/pci/hda/patch_nvhdmi.c
> > > > > +++ b/sound/pci/hda/patch_nvhdmi.c
> > > > > @@ -511,6 +511,8 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec
> > > > > *codec)
> > > > > 
> > > > >  	codec->patch_ops = nvhdmi_patch_ops_8ch_7x;
> > > > > 
> > > > > +	init_channel_allocations();
> > > > > +
> > > > > 
> > > > >  	return 0;
> > > > >  
> > > > >  }
> 
> -- 
> nvpublic
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>