Hi Thomas and Miller,
For some reason I thought that the latency was due to Portaudio. So in short, is the current consensus that the cause is somewhat "uncertain"?
-- David Shimamoto
Well, I've seen latencies down to 6 msec in linux using ringbuffers. They theoretically only add 64 samples of latency. So I don't think that in itself is the problem.
I think the problem in Windows is the "audio server" that non-ASIO audio I/O apparently always goes through. Also, I think it's not feasible to use audio callbacks in Windows since Pd can make system calls (e.g., allocate memory) during the callback -- linux and Mac allow this but Windows doc says not to do that. (This shold be a leftover warning from older times but I've been heeding it anyway.)
Well, trying the forbidden way to use callbacks (and portaudio/ASIO or WDMKS, as implemented in the devel_0_39 branch) actually yield ADDA latencies below 5s for e.g. RME hardware, so the question is where the additional approx. 20ms of latency for the ringbuffer-based ASIO PD implementation come from. I've tried around a lot with the ringbuffer implementation, but it seems the "theoretical limit" of the ringbuffer implementation is just not approachable in Windows, for whatever reason. Besides that, I think we can just forget MMIO or DirectX for serious real-time audio. Also, this thread brings up the question how other programs do it (like Max/MSP or audio editing apps) - do they do something forbidden? Huh?! gr~~~