24 Jan
2003
24 Jan
'03
11:42 a.m.
I'm quite
sure you get much more reliable performance this way, although
JACK doesn't take advantage of multip-period buffer configurations very
well. And this has its reasons. With a setup like shown above, you either
get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter
(latency varies between 1.45ms->2500ms). Both are something we'd _really_
want to avoid.
Because of the above reasons, JACK is designed for two or three
period operation (-n 2 or -n 3). This way we can achieve both low
latency and avoid latency jitter. We could improve reliability by
sacrificing one or both of these goals, but for many of the use scenarios
we are aiming at, this is simply not acceptable.
Pd does not run with 2500ms standard latency, thats for sure. So if
your theory is correct, and it probably gives latency jitter, it
must do a pretty good job at making it unhearable. Wouldnt it be a good idea to have an option for jack to
hide latency
jitter? Or is it to much work (hacking) with the design model?
JACK is specifically designed not to allow latency jitter. you can't
properly sync audio+video with latency jitter, because the software
cannot know for sure when the audio it generates will actually become
audible. pd, by contrast, allows significant latency jitter but in all
likelihood doesn't cause it to wobble all that much.
However, as Kai pointed out, nobody runs JACK with -p 64 -n 27, and if
they did, I suspect that they'd get similar performance to pd. it
would be interesting to hear how pd works with, say, a period size of
1024 and a buffer size of 2048 (i.e. 2 mid-size periods) instead of
lots of small periods.
--p