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.
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...
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.
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
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
Any updates on this?
I thought this one might be the fix: http://lists.freedesktop.org/archives/intel-gfx/2015-September/076650.html
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
AFAIK everything is upstream now, closing. Thanks for the report.
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.