[alsa-devel] Missing surround channels with Nvidia HDMI & snd-hda-intel driver

[VDR User]

Takashi,

Looks good! It's interesting to hear the final detailing of the exact
cause of the problem.

Many thanks,
Derek


On Fri, Nov 17, 2017 at 3:21 AM, Takashi Iwai <tiwai at suse.de> wrote:
> On Fri, 17 Nov 2017 09:28:55 +0100,
> VDR User wrote:
>>
>> Hi Takashi,
>>
>> I can confirm that your patch does fix the bug:
>>
>> [ao/alsa] trying to set ALSA channel map: FL FR FC LFE RL RR
>> [ao/alsa] channel map reported by ALSA: FL FR FC LFE RL RR
>> [ao/alsa] which we understand as: 5.1
>>
>> /usr/src/linux$ uname -r
>> 4.14.0-amd
>> /usr/src/linux$ speaker-test -c 6 -t wav
>>
>> speaker-test 1.1.3
>>
>> Playback device is default
>> Stream parameters are 48000Hz, S16_LE, 6 channels
>> WAV file(s)
>> Rate set to 48000Hz (requested 48000Hz)
>> Buffer size range from 64 to 5440
>> Period size range from 32 to 2720
>> Using max buffer size 5440
>> Periods = 4
>> was set period_size = 1088
>> was set buffer_size = 5440
>>  0 - Front Left
>>  4 - Front Center
>>  1 - Front Right
>>  3 - Rear Right
>>  2 - Rear Left
>>  5 - LFE
>> Time per period = 8.525875
>>
>> Thank you for all your help to resolve this bug!
>
> Great, thanks for your patient testing!
> FWIW, below is the patch I'm going to queue.
>
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai <tiwai at suse.de>
> Subject: [PATCH] ALSA: hda: Fix too short HDMI/DP chmap reporting
>
> We got a regression report about the HD-audio HDMI chmap, where some
> surround channels are reported as UNKNOWN.  The git bisection pointed
> the culprit at the commit 9b3dc8aa3fb1 ("ALSA: hda - Register chmap
> obj as priv data instead of codec").  The story behind scene is like
> this:
>
> - While moving the code out of the legacy HDA to the HDA common place,
>   the patch modifies the code to obtain the chmap array indirectly in
>   a byte array, and it expands it to kctl value array.
> - At the latter operation, the size of the array is wrongly passed by
>   sizeof() to the pointer.
> - It can be 4 on 32bit arch, thus too short for 6+ channels.
>   (And that's the reason why it didn't hit other persons; it's 8 on
>   64bit arch, thus it's usually enough.)
>
> The code was further changed meanwhile, but the problem persisted.
> Let's fix it by correctly evaluating the array size.
>
> Fixes: 9b3dc8aa3fb1 ("ALSA: hda - Register chmap obj as priv data instead of codec")
> Reported-by: VDR User <user.vdr at gmail.com>
> Cc: <stable at vger.kernel.org>
> Signed-off-by: Takashi Iwai <tiwai at suse.de>
> ---
>  sound/hda/hdmi_chmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/hda/hdmi_chmap.c b/sound/hda/hdmi_chmap.c
> index 81acc20c2535..f21633cd9b38 100644
> --- a/sound/hda/hdmi_chmap.c
> +++ b/sound/hda/hdmi_chmap.c
> @@ -746,7 +746,7 @@ static int hdmi_chmap_ctl_get(struct snd_kcontrol *kcontrol,
>         memset(pcm_chmap, 0, sizeof(pcm_chmap));
>         chmap->ops.get_chmap(chmap->hdac, pcm_idx, pcm_chmap);
>
> -       for (i = 0; i < sizeof(chmap); i++)
> +       for (i = 0; i < ARRAY_SIZE(pcm_chmap); i++)
>                 ucontrol->value.integer.value[i] = pcm_chmap[i];
>
>         return 0;
> --
> 2.15.0
>