<div dir="ltr">Ok, it makes sense now.<div>From my understanding, even though the negative latency is counter intuitive as you said, it works because the core compensates when it sees the drift.</div><div>I still don't know how to fix it properly though. Hence my request for better suggestions.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-22 17:48 GMT+01:00 Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le dimanche 22 février 2015, 17:36:27 Jonathan Calmels a écrit :<br>
<span class="">> Could you be a little bit more explicit ?<br>
<br>
</span>What? It is obvious and intuitive why an output cannot exhibit negative<br>
latency. Literally, that would be way back machine.<br>
<span class=""><br>
> If it's forbidden, why does the initial code assume that the latency could<br>
> be negative ?<br>
<br>
</span>The same code path is used in the input code, where negative latency is in<br>
fact possible (for virtual sources, notably monitor sources).<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Rémi Denis-Courmont<br>
<a href="http://www.remlab.net/" target="_blank">http://www.remlab.net/</a><br>
<br>
_______________________________________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="https://mailman.videolan.org/listinfo/vlc-devel" target="_blank">https://mailman.videolan.org/listinfo/vlc-devel</a><br>
</div></div></blockquote></div><br></div>