https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #44 from Anssi Hannula anssi@mageia.org --- (In reply to comment #43)
(In reply to comment #40)
- The 25175 clock at 44.1 kHz is out of spec. There are no correct values to
make it in spec. So either change the clock, rely on hw calculated values, or hope that sinks tolerate the large N.
4th alternative is to round CTS and leave the glitches in on those modes. I might even slightly prefer that than produce out-of-spec N, but that is just my preference and I don't really have any real-world data of course...
If we truncate the clock to 25274 instead instead of rounding it up, we can get sensible N/CTS. Is that something that's possible to do? I don't know how the code that generates the clock looks like.
I don't think it makes sense to massage the video clock to get integer CTS. After all, the clock can come from other sources as well (user modeline, EDID...).
However, there's a similar 6th alternative: Massage the target clock frequency that is used by r600_hdmi_acr() and r600_audio_set_dto() (and evergreen_audio_set_dto()) so that an integer CTS is achieved. This will cause the CTS to be correct and in-spec, but the audio speed will be on the order of ~0.004% slower/faster than video (remember that video+audio may not be this accurate otherwise either, as pll clock may not match target clock exactly).
Not sure without testing which is worse, rounted (wrong) CTS or very slightly slower/faster audio compared to video.