<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 9:42 AM, Joakim Hernberg <span dir="ltr"><<a href="mailto:jhernberg@alchemy.lu" target="_blank">jhernberg@alchemy.lu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, 31 Jan 2016 14:37:13 +0100<br>
Christian Schoenebeck <<a href="mailto:schoenebeck@crudebyte.com">schoenebeck@crudebyte.com</a>> wrote:<br>
<br>
> Another internal deficit was the policy how to deal with laggy<br>
> clients. Which is quite important for consumer use cases. Instead of<br>
> simply kicking out a laggy client from the signal graph it would be<br>
> better to handle it like CoreAudio does: that is automatically<br>
> increasing the latency instead.<br>
<br>
</span>I'm absolutely not a fan of zombifying clients (at least up to a<br>
certain point), but I'd also not be a fan of automagically changing<br>
latencies... IMO it far better to just the client cause xruns and to<br>
let the user deal with the problem himself.<br></blockquote><div><br></div><div>coreaudio has per-client latency, not just system-wide latency.<br></div><div> <br></div></div></div></div>