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~~~ > _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev