[...] 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 that?)
but i'm pretty curious about the alsa implementation (i mean, a callback driven alsa scheduler could reduce the latency even more) ...
cheers ... tim