Steps to reproduce: 1. aplay -D hw:0,7 /home/$USER/Music/1_WAV_PCM_48000Hz_stereo_16bit.wav 2. rtcwake -m mem -s 10 3. aplay -D hw:0,7 /home/$USER/Music/1_WAV_PCM_48000Hz_stereo_16bit.wav Phenomenon: at step 1: music cat be played successful at step 3: music was be playing, but no sound output Note: The test steps have been run both on ASUS and DELL monitor, but the bug only appears on ASUS PA238Q monitor, not on DELL. This issue only happens to ASUS PA238Q monitor's DisplayPort for 48KHz audio. Reproduced on both Haswell and Broadwell.
So this doesn't happen with other sample rates on the same monitor? There's really not a lot of information to go on here. Can you provide a dmesg log with drm.debug=0xe set? -T
And which kernel version? Did you try current drm-intel-nightly? Also, intel_reg_dumper output before suspend and after resume might prove useful.
Note that this problem has been seen on one brand of DP monitor when using 48KHz audio. When the problem happens and audio is not heard, if the monitor is power cycled, the audio is heard. Todd: could one vendor's monitor have a FW bug that would cause such a unique issue? Or, when power cycles, does the monitor reset audio parameters in the OS vis the AUX channel? Note that for anyone exploring the bug, the exact ASUS DP monitor must be used.
Created attachment 101720 [details] dmesg with drm.debug=0xe This is all the dmesg of init, playback, rtcwake, and playback again
Hi all, It only happens with 48KHz. I'm working on drm-intel-nightly, 3.15.0-rc3. I will test on the latest drm-intel-nightly later. Today I find another interesting clue: WHen there is no sound, if I reload the audio driver, the sound comes back. Based on all the symptom, I think this may be the asynchronous issue between audio driver and video driver. As other monitor is OK, is there any possibility that gfx driver delays while audio driver setup with the wrong information for the special monitor. Thanks, Libin
Created attachment 101721 [details] before suspend
Created attachment 101722 [details] after resume
We've fixed some HDMI/DP audio suspend/resume problems a while back. Please re-test with current upstream v3.17-rc's or drm-intel-nightly.
Hi Jani Nikula, Our QA has tested and found this issue is fixed on the latest kernel. Do you have any idea which patches may fix this issue? Thanks, Libin
(In reply to comment #9) > Our QA has tested and found this issue is fixed on the latest kernel. > > Do you have any idea which patches may fix this issue? My best guess is commit e4d9e513dedb5ac4e166c1053314fa935ddecc8c Author: Mengdong Lin <mengdong.lin@intel.com> Date: Thu Jul 3 17:02:23 2014 +0800 ALSA: hda - restore BCLK M/N value as per CDCLK for HSW/BDW display HDA controller and its dependency commit c149dcb5c60bfea8871f16dfcc0690255eeb825f Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Jul 4 10:00:37 2014 +0800 drm/i915: provide interface for audio driver to query cdclk
(In reply to comment #10) > (In reply to comment #9) > > Our QA has tested and found this issue is fixed on the latest kernel. > > > > Do you have any idea which patches may fix this issue? > > My best guess is > commit e4d9e513dedb5ac4e166c1053314fa935ddecc8c > Author: Mengdong Lin <mengdong.lin@intel.com> > Date: Thu Jul 3 17:02:23 2014 +0800 > > ALSA: hda - restore BCLK M/N value as per CDCLK for HSW/BDW display HDA > controller > > and its dependency > commit c149dcb5c60bfea8871f16dfcc0690255eeb825f > Author: Jani Nikula <jani.nikula@intel.com> > Date: Fri Jul 4 10:00:37 2014 +0800 > > drm/i915: provide interface for audio driver to query cdclk got it. Thanks.
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.