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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from Anssi Hannula <anssi at mageia.org> ---
(In reply to comment #6)
> I just meant to patch the table so that you end up using the pre-defined
> values for CTS and N rather than calculating them from the formula.
> 
> {  xxx, 11648, 210937, 17836, 234375, 11648, 140625 }, /*  74.25/1.001 MHz */
> 
> Replace xxx with whatever clock value the drm edid code gives you for
> 74.25/1.001 MHz.

Ah, OK.

> The's presumably a reason the predefined values are there rather just using
> the formula for everything.

Well my guess is that the table could be there just because the HDMI spec has
that table. Note how everything in the table except the three /1.001 rates
(that have differing N) just have the same N/CTS value that the manual
calculation would result in anyway.

The reason the table is in the spec is because using the "default" N for the
(exact, relative to audio) /1.001 rates results in a non-constant CTS - which
is not preferred though should still work.

> The actual clock generated by the PLL will not always be exact either.  It's
> limited by reference clock and the divider ranges.

Hence my preference for HW counted CTS if at all possible.

If HW CTS will not work and it is confirmed that the CTS value is indeed the
issue here, it might get a bit tricky to figure out the proper values in all
cases...

Of course it could be this is not CTS/N related at all and something else in
HDMI audio programming is wrong for these "unusual" pixel clocks.

Better not get too much ahead of ourselves until we know if the HW measured CTS
patch makes any difference, though... :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130925/9484af68/attachment-0001.html>