Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Anssi Hannula <anssi.hannula@iki.fi>
To: Stephen Warren <swarren@nvidia.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Jean-Yves Avenard <jyavenard@gmail.com>
Subject: Re: [PATCH] ALSA: hda - Do not wrongly restrict min_channels based on ELD
Date: Wed, 08 Dec 2010 03:30:41 +0200	[thread overview]
Message-ID: <4CFEDFC1.90305@iki.fi> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF030E0701B8@HQMAIL01.nvidia.com>

On 07.12.2010 19:52, Stephen Warren wrote:
> Anssi Hannula wrote:
>>
>> On 07.12.2010 19:26, Stephen Warren wrote:
>>> Anssi Hannula wrote:
>>>>
>>>> On 07.12.2010 18:58, Stephen Warren wrote:
>>>>> Anssi Hannula wrote:
>>>>>> Commit bbbe33900d1f3c added functionality to restrict PCM parameters
>>>>>> based on ELD info (derived from EDID data) of the audio sink.
>>>>>>
>>>>>> However, it wrongly assumes that the bits 0-2 of the first byte of
>>>>>> CEA Short Audio Descriptors mean a supported number of channels. In
>>>>>> reality, they mean the maximum number of channels (as per CEA-861-D
>>>>>> 7.5.2). This means that the channel count can only be used to restrict
>>>>>> max_channels, not min_channels.
>>>>>>
>>>>>> Restricting min_channels causes us to deny opening the device in stereo
>>>>>> mode if the sink only has SADs that declare larger numbers of channels
>>>>>> (like Primare SP32 AV Processor does).
>>>>>>
>>>>>> Fix that by not restricting min_channels based on ELD information.
>> [...]
>>>>>> Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
>>>>>> Reported-by: Jean-Yves Avenard <jyavenard@gmail.com>
>>>>>> Tested-by: Jean-Yves Avenard <jyavenard@gmail.com>
>>>>>> Cc: stable@kernel.org
>> [...]
>>>>>>  	pcm->channels_max = min(pcm->channels_max, codec_pars->channels_max);
>>>>>>  	pcm->maxbps = min(pcm->maxbps, codec_pars->maxbps);
>>>>>>  }
>>>>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
>>>>>> index d3e49aa..31df774 100644
>>>>>> --- a/sound/pci/hda/patch_hdmi.c
>>>>>> +++ b/sound/pci/hda/patch_hdmi.c
>>>>>> @@ -834,7 +834,6 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
>>>>>>  			return -ENODEV;
>>>>>>  	} else {
>>>>>>  		/* fallback to the codec default */
>>>>>> -		hinfo->channels_min = codec_pars->channels_min;
>>>>>
>>>>> Isn't this still required to default the value?
>>>>
>>>> Not AFAICS. By default *hinfo has the codec provided parameters, and if
>>>> we never update it from the ELD info, we don't need to restore it either.
>>>
>>> OK. Doesn't the same argument apply to the following 3 lines too then?
>>
>> Nope. hinfo is persistent across open() calls, so we need to reset them
>> if they were ever updated from ELD earlier.
>>
>>>>>>  		hinfo->channels_max = codec_pars->channels_max;
>>>>>>  		hinfo->rates = codec_pars->rates;
>>>>>>  		hinfo->formats = codec_pars->formats;
> 
> OK. It seems a little risky to assume that hdmi_eld_update_pcm_info will
> never touch channels_min, but it's certainly true after this patch, so the
> patch will function correctly.
> 
> Sorry for the confusion/noise.

No problem, some noise is much more preferable than possible brokenness :)

-- 
Anssi Hannula

  reply	other threads:[~2010-12-08  1:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-07 16:58 [PATCH] ALSA: hda - Do not wrongly restrict min_channels based on ELD Stephen Warren
2010-12-07 17:09 ` Anssi Hannula
2010-12-07 17:26   ` Stephen Warren
2010-12-07 17:30     ` Anssi Hannula
2010-12-07 17:52       ` Stephen Warren
2010-12-08  1:30         ` Anssi Hannula [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-12-07 16:41 Anssi Hannula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CFEDFC1.90305@iki.fi \
    --to=anssi.hannula@iki.fi \
    --cc=alsa-devel@alsa-project.org \
    --cc=jyavenard@gmail.com \
    --cc=swarren@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox