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@xxxxxxx> 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@xxxxxxx>
> 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@xxxxxxxxx>
> Cc: <stable@xxxxxxxxxxxxxxx>
> Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
> ---
> 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
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
