[Intel-gfx] [RFC 2/3] drm/i915/display: Configure and initialize HDMI audio capabilities

[Kai Vehmanen]

Hey,

On Tue, 20 Jun 2023, Borah, Chaitanya Kumar wrote:

> > -----Original Message-----
> > From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf Of Kai
> > Vehmanen
> > On Fri, 9 Jun 2023, Mitul Golani wrote:
[...]
> > This will hit a problem if we have a case where bandwidth is not enough for 5.1
> > at 192kHz, but it is enough for 2ch 192kHz audio. This approach forces us to
> > give preference to either channel acount or sampling rate.
> > 
> > What if we just store the 'max audio samples per second' into pipe config:
> > 
> >  - have "int max_audio_samples_per_second;" in pipe_config
> >  - pipe_config->audio.max_audio_samples_per_second =
> > available_blank_bandwidth / 32;
> > 
> > Then when filtering SADs, the invidial channels+rate combination of each SAD
> > is compared to the max_audio_samples_per_second and based on that, the
> > SAD is either filter or passed on. What do you think?
[...]> 
> This has been one my concern as well and we have thought about a similar 
> approach as you suggest. One disadvantage of this approach that I can 
> see, would be that if there are hardware limitations on channels (as was 
> in GLK) or frequencies independently. It will be become tricky with this 
> approach. However, one can argue that these limitations arise from 
> bandwidth itself.
[...]
> Regarding the bits per sample, Is using 32bit for all audio formats fair 
> or should we take into account different audio formats and their bit 
> depth?

hmm, I see the point. This is indeed trickier than it first seems. The 
32bit is a good worst-case bound, but in practise actual bandwidth needed 
will be less. And problem is, we don't really know which bit depth the 
application will choose, so again we need to limit based on the 
highest value in SAD.

And then you have the problem that this calculation assumes LPCM encoding.
If the audio is compressed, e.g. a 8ch DTS stream, the bandwidth 
calculation needs to be done differently (see 
linux/sound/pci/hda/hda_eld.c:hdmi_update_short_audio_desc()):

So I think there are (at least) two ways to go about this:
  1) reduce the scope and make the channel/rate limit more 
     limited, and only cover cases (like) GLK where a specific limitation
     is known -> max values not set for other platforms

  2) go for more generic description and expose the raw 
     bandwidth (in bits per second) available for audio
	-> then SAD filtering can be done based on raw bandwidth
	-> can be done only to LPCM at first, extended to compressed 
	formats later 
	-> still the problem that code needs to prioritze 
	   between channels/srate/bitdepth when filtering

Br, Kai