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@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 > > 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. > 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? --
