2009/9/13 Dominic Sacré <span dir="ltr">&lt;<a href="mailto:dominic.sacre@gmx.de">dominic.sacre@gmx.de</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div class="h5">On Friday 11 of September 2009 23:22:16 Ray Rashif wrote:<br>
&gt; OK the bug is here:<br>
&gt; <a href="https://bugs.freedesktop.org/show_bug.cgi?id=23739" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=23739</a><br>
&gt;<br>
&gt; A driver bug, not KMS. Be awesome if more people could confirm.<br>
<br>
</div></div>I&#39;ve noticed the same problem with the latest Intel driver versions. It<br>
doesn&#39;t seem to be an issue when running a realtime kernel, but with a<br>
normal kernel the effect on JACK is pretty bad, especially when using<br>
FFADO. Even very large JACK period sizes don&#39;t really help.<br>
<br>
For now I went back to driver version 2.7.1, which still let you choose<br>
between UXA and EXA (the latter has been removed in 2.8). UXA has the<br>
problems you describe, EXA doesn&#39;t. I&#39;ll try to gather some more<br>
information on this and add it to your bug report.<br>
<font color="#888888"><br>
<br>
Dominic<br>
</font><div><div class="h5"><br>
</div></div></blockquote><div><br></div><div>Awesome, thanks.<br></div><div><br></div><div>Yes, UXA and the developers are mostly sure as well, that it&#39;s probably the new method of buffering when drawing. As such, I was told to try:</div>

<div><br></div><div>Option          &quot;SwapbuffersWait&quot;       &quot;false&quot;</div><div><br></div><div>This only decreases the amount of xruns it seems. Events like switching on or off compositing will trigger a burst of xruns.</div>