Bug 90776

Summary: [hdmi audio] spec violation for >=uhd-4k TMDS clock frequencies, no audio out in worst case
Product: DRI Reporter: Joe Konno <joe.konno>
Component: DRM/IntelAssignee: Jim Bish <jim.bish>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: critical    
Priority: highest CC: intel-gfx-bugs, matthew.e.hiltner, rodrigo.vivi, tprevite, ullysses.a.eoff
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: BDW, BSW/CHT, HSW, IVB, SKL i915 features: display/audio

Description Joe Konno 2015-05-29 20:50:33 UTC
It is believed that Intel GPUs which support uhd-4k/3840x2160 resolutions over HDMI are not setting N/CTS values correctly during audio(-over-hdmi) playback. This can result in no audio being played back over the display's speakers.

The HDMI >=1.4 spec specifies audio sampling rate, TMDS clock frequencies, and N/CTS values for uhd-4k displays. The N/CTS values are not being supported for the TMDS clock frequencies associated with uhd-4k displays.

In the i915 display code there needs to be a mechanism for kernel audio drivers (e.g. HDA) to signal the display driver when the audio sampling rate changes, which will trigger a lookup within the display driver to ensure correct N/CTS values are set.
Comment 1 Jani Nikula 2015-06-01 08:40:18 UTC
At a glance, looks like the spec has been clarified, and what we currently do (let the hardware figure out the N/CTS values based on the HDMI pixel clock) might only work reliably for CEA modes.

At the second glance, looks like we got ourselves a nice little catch-22 here. When we enable an audio capable output, we notify the audio driver about this (through hardware). At this point we don't know or care what the audio driver does about it. We go on enabling the output. However if the audio driver is in control of the sampling rate, and the N/CTS values need to be adjusted based on that, we'd need to disable the transcoder to make the change...
Comment 2 Joe Konno 2015-06-10 20:57:42 UTC
With a HDMI Protocol Analyzer and a bunch of audio files sampled at different rates, a bug can be seen--

Setup:
  * latest drm-intel-nightly
  * ideally a test sink HDMI Protocol Analyzer (or Acer B286HK 4K display)
  * Intel platform with HDA audio and Intel Graphics hardware (HSW or newer)

Steps:
  1. Boot system
  2. If not plugged already, plug HDMI display
  3. Set HDMI display resolution to 3840x2160
  4. Configure audio to play back over HDMI
  5. Play an audio file sampled at 48kHz, note N/CTS values in Analyzer or dump relevant registers-- they may not match spec; may not play back over stated display
  6. Play an audio file sampled at 44.1kHz, note N/CTS values in Analyzer or dump relevant registers-- they *will not* match spec; likely will not hear audio over stated display

Mileage varies substantially display to display. As of writing, Acer B286HK 4K display is especially sensitive to HDMI audio being out-of-spec.
Comment 3 Joe Konno 2015-06-11 18:50:34 UTC
Some audio examples:
* 44.1kHz: "Maroon 5 - 'Sugar'": https://www.youtube.com/watch?v=09R8_2nJtjg
* 48kHz seems to be the dominant sampling rate on high-profile youtube vids
Comment 4 Joe Konno 2015-06-12 00:36:15 UTC
I'll attempt to distill several discussions I've had with colleagues over the past week or so.

The take-away is, there needs to be a callback mechanism within the i915 driver to properly program N/CTS for all pixel clock rates-- those commonly associated with UHD-4K being one example, and the one I've personally tested with a HDMI protocol analyzer.

One of my colleagues floated the following interface additions to i915_audio_component to provide necessary communication between sound drivers and i915:

  /* set correct N/CTS values as specified in HDMI specification */
  void (*set_audio_rate)(struct device *, enum port port, int rate);

and

  /* the same, but in DP MST usage scenarios */
  void (*set_audio_rate)(struct device *, enum port port, int dev, int rate);

There are questions, of course:

  - surrounding the particulars of S/W programming the N/CTS registers on-the-fly at runtime while the user is using their audio player or watching a video;

  - about tackling this problem on a conditional basis (targeting the trouble spots), or if we want the i915 kernel driver to be the N/CTS S/W programmer 100% of the time;

  - whether buggy behavior is seen also with non-CEA modes at high pixel rates, not necessarily at the resolution cited in this ticket;

  - what to do about very low sampling rates defined in the HDMI spec, such as 32kHz and multiples thereof; and

  - how best to handle DP MST usage scenarios
Comment 5 U. Artie Eoff 2015-07-24 16:52:07 UTC
Any updates on this?
Comment 6 Jesse Barnes 2015-10-01 15:27:29 UTC
I thought this one might be the fix:
http://lists.freedesktop.org/archives/intel-gfx/2015-September/076650.html
Comment 7 Jani Nikula 2015-10-02 07:04:40 UTC
It's also in drm-intel-nightly via Takashi's sound tree [1]:

commit 7e8275c2f2bbb384e18af37066b8b2f32b7d092f
Author: Libin Yang <libin.yang@intel.com>
Date:   Fri Sep 25 09:36:12 2015 +0800

    drm/i915: set proper N/CTS in modeset

I am currently not sure if it's still to be merged to v4.3, or whether Takashi decided to postpone it until v4.4.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
Comment 8 Jani Nikula 2015-10-07 13:27:57 UTC
AFAIK everything is upstream now, closing. Thanks for the report.
Comment 9 U. Artie Eoff 2015-10-08 04:21:00 UTC
This patch is also needed:
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077476.html

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.