[Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15

Kjetil S. Matheussen k.s.matheussen at notam02.no
Fri Jan 24 10:28:00 UTC 2003


On Fri, 24 Jan 2003, Kai Vehmanen wrote:

> On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
>
> >> 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:
>
> Could you also send an output of pcm0[cp]/sub0/status...?
> Anyway, this is very good info.
>

kjetism at 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 at 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 at 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 at 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



> > kjetism at 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.
>

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?


-- 




More information about the Linux-audio-dev mailing list