3 Jul
2013
3 Jul
'13
10:31 a.m.
On 07/03/2013 10:09 AM, Jeremy Jongepier wrote:
On 07/02/2013 08:27 PM, Robin Gareus wrote:
I don't know if that's USB-2.0 or something else.. - The same goes for
the statement that "USB devices should perform better if the sample
rate is divisible by the period size". I cannot find any evidence that
supports that statement.
As with all complex systems, I trust measurements more than theory:
http://robin.linuxaudio.org/tmp/vsl1818latency.png
(x-axis are permutations of jackd's -p, -n, --sync parameters,
no x-runs with either configuration but it's just jackd + jack_delay,
no load).
[Surprisingly]? the latency increments are not quantized to
milliseconds (as the USB protocol implementation would suggest it should).
On 07/02/2013 07:49 PM, Harry van Haaren wrote:
Hi Robin,
So with and USB2.0 audio interface like the 181VSL using -n2 yields
a stable setup too, no need anymore to use -n3?
On Tue, Jul 2, 2013 at 5:53 PM, Fero Kiraly
<fero.kiraly(a)gmail.com> wrote:
* linux 3.2.35-2 PREEMPT RT (debian's RT kernel recompiled with
VSL1818 clock selector fix added) * jackd 1.9.10 (git) * Rui's
rtirq script * jackd with -p64 -n2 (actually jackdbus) I have some troubles - read xruns - with this
setup:
There's a lot more to removing Xruns from a system than just
the kernel and JACK settings (although they are very important
:) 