Hallo,
[...] 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 ...
The reason I think is historical and going back to the ISPW, 2 i860 cpus on an extra card running fts where you can distribute working load to dedicated cpus udn need to have latencies because of signal distribution on shared memory,....
Nevertheless I think since all messages are calculated before the dsp-stuff each tick, the chance to have a FFT-Border and a lot of messages triggered eg. by bang~ at the sametime can easily exceed the buffer size so its better if you distribute the message calculation in finer grains, therefore its good to have at least 2 (3) dacblocks as a sysbuffer, even if you use a 64sample buffer on hardware. If you really need (it will be nice you write down a Use-case) and want to go unter say 3*64 ca. 3.5ms, you its better to mach DACBLKSIZE smaller, which works on most and all well written objects, fine. Also be sure pd is never blocked less then time of a syssamples, which I did with increasing the scheduler rate from 100Hz to 10000 in ancient times ;-)
I think using higher samplerate is the same as reducing DACBLKSIZE to reduce latency time.
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)
should be 2ms which is very small.
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?)
I dont know if it depends on alsa mmap implementation, but code is not really test to much since when I got latency about 5ms I was already happy und i didnt need more.
but i'm pretty curious about the alsa implementation (i mean, a callback driven alsa scheduler could reduce the latency even more) ...
I dont exactly know what jack does, but since alsa makes direct memory access and can copy samples to buffer in smaller units than buffersize of hardware and also watches the write read pointer from rme hardware card (use precise_ptr on module load), you theoretically can go smaller than 64 samples on as hardware buffer ;-) so you should can go down until I think 8 samples (PCI Bridge Buffer with 26channels) , depends on pci bridge on computer.
mfg winfried