[alsa-devel] Missing 4-channel support on older NVIDIA MCP HW
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 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.
Unfortunately, it doesn't look like it's possible for applications to query this information from ALSA, since a hw_params_t exposes just a min/max channel count rather than a mask.
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?
Unfortunately, it doesn't look like it's possible for applications to query this information from ALSA, since a hw_params_t exposes just a min/max channel count rather than a mask.
It can be also masked.
Takashi
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?
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?
Unfortunately, it doesn't look like it's possible for applications to query this information from ALSA, since a hw_params_t exposes just a min/max channel count rather than a mask.
It can be also masked.
Are you saying the APIs already support a mask for channel count, and I just didn't find it, or that the APIUs should be updated to report a mask?
Thanks.
2010/8/31 Stephen Warren swarren@nvidia.com
Takashi Iwai wrote:
Unfortunately, it doesn't look like it's possible for applications to
query
this information from ALSA, since a hw_params_t exposes just a min/max channel count rather than a mask.
It can be also masked.
Are you saying the APIs already support a mask for channel count, and I just didn't find it, or that the APIUs should be updated to report a mask?
Thanks.
you can find the examples in intel8x0.c
static unsigned int channels2and8[] = { 2, 8, };
static struct snd_pcm_hw_constraint_list hw_constraints_channels2and8 = { .count = ARRAY_SIZE(channels2and8), .list = channels8, .mask = 0, };
runtime->hw.channels_max = 8; snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS, &hw_constraints_channels2and8);
The ALSA application need to snd_pcm_hw_params_test_channels() to find the supported channel one by one
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?
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.
Unfortunately, it doesn't look like it's possible for applications to query this information from ALSA, since a hw_params_t exposes just a min/max channel count rather than a mask.
It can be also masked.
Are you saying the APIs already support a mask for channel count, and I just didn't find it, or that the APIUs should be updated to report a mask?
You can pass the list as hw_constraint. Look for drivers using struct snd_pcm_hw_constraint_list.
thanks,
Takashi
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.
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!
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?
Unfortunately, it doesn't look like it's possible for applications to query this information from ALSA, since a hw_params_t exposes just a min/max channel count rather than a mask.
It can be also masked.
Are you saying the APIs already support a mask for channel count, and I just didn't find it, or that the APIUs should be updated to report a mask?
You can pass the list as hw_constraint. Look for drivers using struct snd_pcm_hw_constraint_list.
Thanks, the intel8x0.c code looks pretty similar to what's required.
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
participants (3)
-
Raymond Yau -
Stephen Warren -
Takashi Iwai