[Bug 92889] Sound output using DisplayPort is NOT played during the first 3-5 seconds (on several audio hardware)
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Apr 14 21:52:11 UTC 2017
https://bugs.freedesktop.org/show_bug.cgi?id=92889
--- Comment #23 from Paul <Paul.Hancock.17041993 at live.com> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-driver-ati/attachments/20170414/2631b01a/attachment.html>
More information about the xorg-driver-ati
mailing list