| Summary: | Sound output using DisplayPort is NOT played during the first 3-5 seconds (on several audio hardware) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Etienne URBAH <eurbah> | ||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | c.anderso | ||||
| Version: | unspecified | ||||||
| Hardware: | x86-64 (AMD64) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Etienne URBAH
2015-11-10 14:32:38 UTC
I have the same problem. Also the audio is distorted in pitch when played via the display port (not HDMI). The issue is still the same with following Linux kernel versions : - From Ubuntu Xenial 16.04 Beta1 : - 4.4.0-10 - 4.4.0-11 - From http://kernel.ubuntu.com/~kernel-ppa/mainline : - 4.5.0-040500rc7 The issue is still the same with Linux kernel 4.5.0-040500 from http://kernel.ubuntu.com/~kernel-ppa/mainline With Linux kernel 4.6.0-040600rc1 from http://kernel.ubuntu.com/~kernel-ppa/mainline : - 'Line Out - Built-in Audio' provides correct sound, - 'HDMI / DisplayPort - Tahiti XT HDMI Audio [Radeon HD 7970 Series]' provides NO SOUND AT ALL. With Linux kernel 4.6.0-040600rc4 from http://kernel.ubuntu.com/~kernel-ppa/mainline : - 'Line Out - Built-in Audio' provides correct sound, - 'HDMI / DisplayPort - Tahiti XT HDMI Audio [Radeon HD 7970 Series]' provides NO SOUND AT ALL. With Linux kernel 4.6.0-040600 from http://kernel.ubuntu.com/~kernel-ppa/mainline : - 'Line Out - Built-in Audio' provides correct sound, - 'HDMI / DisplayPort - Tahiti XT HDMI Audio [Radeon HD 7970 Series]' provides some sound again, but LATE as originally described, and DISTORTED on DisplayPort. The issue is still the same with Linux kernel 4.7.2-040702 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.8.0-040800rc3 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.8.0-040800rc5 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.8.0-16 from Ubuntu 16.10 Yakkety Beta The issue is still the same with Linux kernel 4.9.0-040900rc1 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.9.0-040900rc2 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.9.0-040900rc3 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.9.0-040900rc5 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.9.0-040900 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.10.0-041000rc2 from http://kernel.ubuntu.com/~kernel-ppa/mainline The issue is still the same with Linux kernel 4.10.0-041000rc7 from http://kernel.ubuntu.com/~kernel-ppa/mainline Have the same problem on 17.04 (and Debian Stretch) with 280x 'AMD Tahiti XT'. Sound is played back slow, lower pitch through displayport. Youtube both video and audio are slowed down. All work well in Windows 10. The issue is still the same with Linux kernel 4.11.0-041100rc6 from http://kernel.ubuntu.com/~kernel-ppa/mainline From my experience with GCN audio it's slower to initialise than other audio devices, so what's likely happening here is that the test audio playback is waiting for the device to be fully ready before actually playing the audio event. This is not generally a bad thing, but can be handled better, window's for example plays everything in its software buffer in its own time, when the device is eventually ready it plays where the soft buffer is up to, resulting in the first second (or less) being cut out but no timing issues occur. @jdedraeck that seems to be a different issue entirely, by the sounds of it it's not being initialised correctly and the wrong format is being used, or the application is sending the wrong format (probably sending 96KHz when the device only allows 44.1 or 48). This issue seems to be NOT specific to AMD/ATI Tahiti XT : For example, it has been reported with NVIDIA GTX 970 at https://askubuntu.com/questions/874320/audio-starts-playing-3-5-seconds-after-video-does So, I change the title of this issue to a more accurate title. I also suggest to report this issue at https://www.alsa-project.org What do you think about it ? FWIW, the same thing happens with some receivers and various media devices (Roku, DVD player, etc.). I think it takes some receivers and displays a few seconds to detect and enable the audio stream. It might be dependent on the display or receiver. (In reply to Alex Deucher from comment #22) > FWIW, the same thing happens with some receivers and various media devices > (Roku, DVD player, etc.). I think it takes some receivers and displays a > few seconds to detect and enable the audio stream. It might be dependent on > the display or receiver. It _is_ in fact normal for there to be a significant delay in initialising HDMI and DP audio, it's because of the multiple handshakes that have to occur between the devices. For standard internal and USB devices, the only long part of the init is creating the buffers, but for HDMI and DP it's more like this; - check controller capability and init controller (mostly in-memory from POST) - check link status, collect audio endpoint data (slow-ish) - ensure controller and endpoint can use desired format - initialise audio endpoint (again, slow-ish, requires re-configuring the cable bitstream) - create buffers - wait for endpoint to be ready, then init buffer stream Usually this is all done within 250-500ms, but indeed for some endpoint devices it may take a lot longer and especially if they need to relay info between other connected devices (ie; a receiver or a de-embed switch), content protection protocols also increase the complexity. We'd need a _lot_ more info to know whether it's just the endpoint or if the driver could be optimised more, for example a basic test with basic formats between windows/OSX/both and the xorg drivers, ideally with multiple HDMI/DP controllers and endpoints. I will note as well; the HDMI DAC takes about 5 seconds for a full init to finish, however this includes the video init as well as audio, windows seems to collect all the info it needs from the get-go instead of requesting later. Lot of thank to Paul for his last comment :
Supposing that this 'sound not played during the first 3-5 seconds' issue comes from an initialization delay, I imagined following (heavy) keep-alive system, which succeeds !
Firstly, simple sound tests can be performed using shell commands with the WAV files from the '/usr/share/sounds/alsa' folder. For example :
$ aplay /usr/share/sounds/alsa/Noise.wav
$ speaker-test -D front -c 2 -l 1 -t wav -w Noise.wav
Secondly, after having set 'microphone level' = 1%, you can create a file containing 60 seconds silence using following command :
$ arecord -D default -f S16_LE -r 48000 -d 60 Silence-Mono-S16_LE-48kHz-60s.wav
The file size is 5.5 MB (which is enormous for silence), but it permits 'speaker-test' to play this file (if you want).
As 'root', you can create the '/usr/local/share/sounds' folder and copy the 'Silence-Mono-S16_LE-48kHz-60s.wav' inside.
Then you can start the 'keep-alive-hdmi-or-displayport-audio-output.sh' script below as a user session daemon.
After that, when playing any sound, the first 3-5 seconds are NOT lost anymore, but are really played.
I suggest that you test my workaround, then try to devise a much lighter workaround at a lower level (like Windows does).
#!/bin/sh -e
# keep-alive-hdmi-or-displayport-audio-output.sh
set -e
pactl --version > /dev/null
LANGUAGE=en_US:en
while true
do
if pactl info | grep -q -i "^ *Default *Sink *:.*\.hdmi"; then
aplay -q /usr/local/share/sounds/Silence-Mono-S16_LE-48kHz-60s.wav
else
sleep 10
fi
done
The issue is still the same with Linux kernel 4.13.0-11 from Ubuntu 17.10 Artful Beta The issue is still the same with Linux kernel 4.15.0-041500rc1 from http://kernel.ubuntu.com/~kernel-ppa/mainline I definitely confirm that this issue is NOT specific to AMD/ATI Tahiti XT, but also appears with following NVIDIA hardware : $ lspci -nn -v -s 1:0 01:00.0 3D controller [0302]: NVIDIA Corporation GP107M [GeForce GTX 1050 Ti Mobile] [10de:1c8c] (rev a1) Subsystem: Micro-Star International Co., Ltd. [MSI] GP107M [GeForce GTX 1050 Ti Mobile] [1462:11c8] Flags: bus master, fast devsel, latency 0, IRQ 134 Memory at de000000 (32-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] Memory at d0000000 (64-bit, prefetchable) [size=32M] I/O ports at e000 [size=128] Expansion ROM at df000000 [disabled] [size=512K] Capabilities: <access denied> Kernel driver in use: nouveau Kernel modules: nvidiafb, nouveau Therefore, the origin of this issue could be the ALSA driver, and I will try to report this issue at https://www.alsa-project.org (In reply to Etienne URBAH from comment #27) > > Therefore, the origin of this issue could be the ALSA driver, and I will try > to report this issue at https://www.alsa-project.org See comment 22. I can reproduce this with various non-PC devices (Roku, DVD plays, etc.). The issue is still the same with Linux kernel 4.16.0-041600rc5 from http://kernel.ubuntu.com/~kernel-ppa/mainline -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/143. |
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.