<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED --- - audio broken in 24Hz/24p since 3.11 (regression)" href="https://bugs.freedesktop.org/show_bug.cgi?id=69675#c40">Comment # 40</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED --- - audio broken in 24Hz/24p since 3.11 (regression)" href="https://bugs.freedesktop.org/show_bug.cgi?id=69675">bug 69675</a> from <a class="email" href="mailto:anssi@mageia.org" title="Anssi Hannula <anssi@mageia.org>"> Anssi Hannula</a> <pre>The changes look sound to me. I had already forgotten that the table values were off for the rounded clocks (even though I had mentioned it in <a href="show_bug.cgi?id=69675#c5">comment #5</a>). Also, I see now that as the DTO is also set according to the target clock (instead of pll clock), this compensates for possible difference between target/pll clocks when calculating CTS. So the CTS/N values need to be selected as if the clock was exactly the rounded clock (e.g. 74176), instead of using the spec values (that are correct only for exact 74250/1.001). This should also mean that the SW values are all-OK except in the cases where an integer CTS is not possible as per Pierre's note 1. > 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...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>