[PD-dev] Re: [PD] RME hammerfall
TimBlechmann at gmx.net
Mon Apr 18 17:13:10 CEST 2005
> int sys_advance_samples; /* scheduler advance in samples */ [...]
> /* exported variables */ int sys_schedadvance; /* scheduler
> advance in microseconds */ float sys_dacsr;
> t_sample *sys_soundout; t_sample *sys_soundin; [...]
> which means there is an additional sys buffer, which could be bigger
> than the Soundcardbuffer. I always thought pd needs at least 2
> blocksize for this buffer, but I had to look at the code if this is
> still true.
i just checked the code:
sys_advance_samples = (sys_schedadvance * sys_dacsr) / (1000000.);
if (sys_advance_samples < 3 * sys_dacblocksize)
sys_advance_samples = 3 * sys_dacblocksize;
this seems to be, what you where referring to ... still, i don't see
the reason for this. neither native asio nor jack use this ... with
jack down to 64 samples ...
i don't think this has any technical reason, only prevents the user
from specifying lowest latencies ...
actually, i tested your latency-test patch on my machine ...
the results are:
jack (cb scheduler): 264 samples
jack (synchronous): 456 samples
native alsa: 200 samples
(period size of 128, 96000 kHz)
still, native alsa has some timing issues on my machine, resulting in
gliches, so i can't use it with block sizes lower than 256 at 96000
kHz, which results in a latency of 328 samples... (can someone confirm
but i'm pretty curious about the alsa implementation (i mean, a
callback driven alsa scheduler could reduce the latency even more) ...
cheers ... tim
mailto:TimBlechmann at gmx.de ICQ: 96771783
latest mp3: kMW.mp3
latest cd: Goh Lee Kwang & Tim Blechmann: Drone
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs
More information about the Pd-dev