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