24 Jan
2003
24 Jan
'03
11:27 a.m.
On Fri, 24 Jan 2003, Kai Vehmanen wrote:
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?
--
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
Could you also send an output of pcm0[cp]/sub0/status...?
Anyway, this is very good info.
kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more
/proc/asound/card0/pcm0c/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 12
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1953
kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more
/proc/asound/card0/pcm0c/sub0/sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 1811939328
stop_threshold: 1811939328
silence_threshold: 0
silence_size: 0
boundary: 1811939328
kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more
/proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 10
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1953
kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more
/proc/asound/card0/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 1811939328
stop_threshold: 1811939328
silence_threshold: 0
silence_size: 0
boundary: 1811939328
What does
"cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output
I'm at
work now, and we ~only have delta cards. At home I use a built-in
sound-card on an nforce chipset. But I get nearly the same good
performance in pd here as at home. So here is delta44 parameters:
kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params
[...]
period_size: 64
buffer_size: 1728
So I guess this explains a lot. This equals to running jackd
with "-p 64 -n 27" (and not as root or otherwise it will throw clients
out if they miss one 64 frame deadline).
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.