[alsa-devel] Missing 4-channel support on older NVIDIA MCP HW

[Takashi Iwai]

At Wed, 1 Sep 2010 12:03:09 -0700,
Stephen Warren wrote:
> 
> Takashi Iwai wrote:
> > 
> > At Tue, 31 Aug 2010 08:41:53 -0700,
> > Stephen Warren wrote:
> > >
> > > Takashi Iwai wrote:
> > > >
> > > > At Mon, 30 Aug 2010 10:11:09 -0700,
> > > > Stephen Warren wrote:
> > > > >
> > > > > It looks like even though some NVIDIA MCPs have min/max channel of 2/8, not
> > > > > all HW supports the intermediate # channels (4 and 6) over HDMI. Various
> > > > > combinations are supported on various HW: 2, 2/8, 2/6/8, 2/4/6/8.
> > > > >
> > > > > At present, when an application uses an unsupported number of channels,
> > > > > playback appears to operate correctly, but the HW doesn't actually send the
> > > > > audio data over HDMI.
> > > > >
> > > > > Is it possible for patch_nvhdmi.c to simply program codec the HW in 8-channel
> > > > > mode even though the controller is only sending 4-/6-channel data?
> > > >
> > > > I'm not sure whether HD-audio codec can have a /dev/zero-kind of stream.
> > > > It's possible to set up but I don't think it's worth.
> > > > It'd be far easier to omit 4 and 6-channels for such a case.
> > > >
> > > > > I'm not
> > > > > sure if this would cause the codec to get out of sync with the controller's
> > > > > data stream. Would the controller end up grabbing 8 channels worth of data
> > > > > from the stream at a time, have no way to synchronize to the start of each
> > > > > sample, and hence end up packing e.g. 2 complete 4 channel samples into a
> > > > > single 8 channel sample?
> > > > >
> > > > > If not, it seems that patch_nvhdmi.c should be modified so that each codec's
> > > > > _open() function returns an error for unsupported rates. I can code that up
> > > > > if we need.
> > > >
> > > > Do you mean for unsupported channels?
> n >
> > > Oops, yes.
> > >
> > > Do you think that's the correct fix?
> > >
> > > If the driver errors out the open, will a plug: (or other non hw:) ALSA device
> > > dynamically "upsample" a 4-channel stream to the next supported (8-channel), or
> > > will the user application have to handle this?
> > 
> > alsa-lib can do make working (e.g. via upmix plugin).  But other audio
> > backend can do it by itself.
> > IMO, telling the truth is a better approach.  It is 4-channel, after
> > all.
> 
> Sorry to be dense, but when you say "audio backend", I'm not sure what you're
> referring to; the ALSA driver, the HW itself, or something else.

Think of PulseAudio, SDL, libao, whatever...

> Are you saying that I should modify patch_nvhdmi.c to somehow reformat the
> data before sending it to the device?
> Or, are you saying it'd be best if the HW handled it. That's true, but
> unfortunately, there's no way to fix that now!

No for both.  What I meant was that if the hardware doesn't support
it, we just need to show to user-space that it's not supported (i.e.
setting up hw_constraints appropriately via list).

> Finally, you mentioned the alsa-lib's upmix plugin. Will that automatically be
> used for a 4-channel stream when the HW only supports 8-channel, or will the
> application (or a config file) have to specifically activate this?

The latter, so far.  This plugin isn't in the standard automatic plug
conversion and it belongs to the extra alsa-plugins package.


thanks,

Takashi