[alsa-devel] HDMI audio: TV vs. codec supported sample rates

[Takashi Iwai]

At Thu, 5 Aug 2010 13:57:18 +0300,
Anssi Hannula wrote:
> 
> Takashi Iwai kirjoitti torstai, 5. elokuuta 2010 13:46:39:
> > At Thu, 5 Aug 2010 12:49:07 +0300,
> > 
> > Anssi Hannula wrote:
> > > Anssi Hannula kirjoitti tiistai, 3. elokuuta 2010 20:39:20:
> > > > Stephen Warren kirjoitti tiistai, 3. elokuuta 2010 19:20:24:
> > > > > I don't see anything in patch_intelhdmi.c that relates to sample rate
> > > > > support at all. However, I see that patch_nvhdmi.c contains e.g.:
> > > > > 
> > > > > static struct hda_pcm_stream nvhdmi_pcm_digital_playback_8ch_89 = {
> > > > > 
> > > > >         .substreams = 1,
> > > > >         .channels_min = 2,
> > > > >         .rates = SUPPORTED_RATES,
> > > > > 
> > > > > Should .rates not be initialized here,
> > > > 
> > > > When .rates is not initialized, they are automatically read from the
> > > > codec, i.e. exactly the values you referenced above from
> > > > "/proc/asound/card1/codec#1".
> > > > 
> > > > The values seem to differ (32000 vs 22050 is reported as supported),
> > > > though. If the codec reported values are wrong, the .rates should be
> > > > kept. Otherwise the rates set in .rates should be fixed or the
> > > > override just removed.
> > > 
> > > As AFAICS HDMI specification allows 32000Hz but not 22050Hz, I'd say it
> > > is likely that the override is wrong and the codec reported rates are
> > > right.
> > > 
> > > (my receiver doesn't support 32000Hz so I can't confirm).
> > 
> > So, the codec reports correct values based on EDID?
> 
> No. The codec reports all the values it supports, regardless if the attached 
> HDMI sink supports them or not.

OK.  Then setting a static value was still needed.

> > IIRC, the static values there were needed for old Nvidia codecs that
> > don't give the actual values.  Maybe newer chips work correctly.
> > If so, rates, maxbps and formats in *_89 (also *_7x, too?) can be
> > removed, indeed.
> > 
> > Can any confirm?
> 
> I have an older MCP7A codec as well and can confirm that it reports wrong 
> values (only 48000/88200, while I can confirm in reality 192000 works with 
> it). Though I guess the nonsensical 22050 should probably be 32000 (but I 
> can't test since my receiver doesn't support 32000).

What actually show in eld#* proc file?
If this shows the correct values, we can add the code to take over
rates & formats from ELD at hotplug.


Takashi