[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 2829 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=69675

--- Comment #5 from Anssi Hannula <anssi@mageia.org> ---
To expand a bit on my earlier comment that Alex pasted:

HDMI sends ACR packets in the stream that will allow the sink to recover the
audio clock. Two values are sent:

N: Divisor used on the audio reference clock (128 * samplerate).
CTS: Amount of TMDS clock cycles per one N-divided audio reference clock cycle.

AFAICS normally the source hardware is expected to measure the CTS in real-time
by counting the cycles. If the audio/video clocks are perfectly in sync and N
is selected optimally (if possible), CTS will of course stay constant. In other
cases it is expected to alternate between several values.

The HDMI specification has some recommended N values (and corresponding
expected CTS values) for common TMDS clocks. The recommended values result in a
constant CTS if the clocks are synchronous (constant CTS is "recommended
whenever possible").
The recommendation table does include TMDS clock 74.25/1.001, which is the one
used for 1080p23.976. However, the provided N will result in constant CTS only
if the clock is exactly 74.25/1.001 without rounding (and the modeline is of
course rounded, unless something in the driver or hw does something to try to
restore the fractional rate - I have no idea if that is the case).

The radeon driver contains the recommended table and hardwires N/CTS values. If
the TMDS clock is not found in the table, recommended N is selected and the CTS
is simply directly calculated and set as constant.

The table in question contains N/CTS 11648/140625 for 48kHz and 74.175 MHz
(74.175 is down-rounded 74.25/1.001). However, if the TMDS freq is actually
exactly 74.175 Mhz and not 74.25/1.001 (74175.824) (i.e. nothing corrects
74.175 => 74.25/1.001), the N/CTS values are already wrong
(74175000*11648/(48000*128) = 140623.4375 != 140625.

The driver calculated N/CTS (for clocks not in the table) are correct only if
the TMDS clock is exactly the value used (relative to audio clock). I have a
feeling that might not be the case (evidenced by e.g. this bug), though I
didn't look at the radeon driver internals that closely.


To me it would seem like using hardware measurement for CTS value would be
better than to deal with all this. According to header comments radeon hw seems
to support that, but for some reason that is not used and driver-wired values
are used instead.
Alex' attached patch should switch the ACR to hw measured CTS. If that actually
works, hopefully it fixes the audio synchronization issues...

(In reply to comment #4)
> Something like this:

Not really, the selection doesn't work like that - clock has to match exactly
to the table value, it is not an upper bound.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3681 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel