Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 667280" data-attributes="member: 10858">Xonar does it's own thing again <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" />First of all the drivers are just lying to us, 53333, 53334 is much too accurate to be correct. I would say it is hundred times too accurate what the audio renderer's polling mode could be having for the querying accurancy (timer isn't that accurate).2nd issue that can be spotted is that the driver is telling it is advancing approximately on 1.0666...x speed when compared to the system clock (53333 / 50000). This cannot be true especially since the 26667 happens as well to compensate it. Looks like the driver side is not actually knowing the exact playback position on the HW buffer and makes up the data by some algorithm and then corrects it when the HW buffer information is available (26667 is the correction phase). I wouldn't want to create any workaround for badly behaving drivers (it wont ever be as good as the correctly working driver, also I have currently no clue how to patch and still keep the currently correctly behaving HW ok). Could you test 50 ms, 500 ms buffers as well with the logging?Also if there is no drifting with the HW based reference clock not used case it should be good enough as a overcoming period when ever ASUS decides to fix their drivers.</blockquote>

[QUOTE="tourettes, post: 667280, member: 10858"] Xonar does it's own thing again :D First of all the drivers are just lying to us, 53333, 53334 is much too accurate to be correct. I would say it is hundred times too accurate what the audio renderer's polling mode could be having for the querying accurancy (timer isn't that accurate). 2nd issue that can be spotted is that the driver is telling it is advancing approximately on 1.0666...x speed when compared to the system clock (53333 / 50000). This cannot be true especially since the 26667 happens as well to compensate it. Looks like the driver side is not actually knowing the exact playback position on the HW buffer and makes up the data by some algorithm and then corrects it when the HW buffer information is available (26667 is the correction phase). I wouldn't want to create any workaround for badly behaving drivers (it wont ever be as good as the correctly working driver, also I have currently no clue how to patch and still keep the currently correctly behaving HW ok). Could you test 50 ms, 500 ms buffers as well with the logging? Also if there is no drifting with the HW based reference clock not used case it should be good enough as a overcoming period when ever ASUS decides to fix their drivers. [/QUOTE]

Verification