Comment # 44 on bug 69675 from Anssi Hannula

(In reply to comment #43)
> (In reply to comment #40)
> > > 1. 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.