Well, the pd code, unless I've written it wrong somehow, sets the total portaudio buffer size roughly to the requested latency in samples. Also, having Pd poll a fifo that's filled in by the callback routine should only add another 64 samples of latency, plus whatever the OS wakeup latency is. Certainly this shouldn't be more than 20 msec or so on a reasonably modern system. So I don't know how the latency is getting up to 70!
Anyway, I'm planning to upgrade to Portaudio 0.19 on all platforms for PD version 39... I'm playing it conservatively for 0.38 because I've almost got it all working and don't want to break things now.
cheers Miller
On Mon, Nov 22, 2004 at 11:53:42PM +0100, gnter geiger wrote:
On Mon, 22 Nov 2004, smoerk wrote:
Seems that the portaudio code of pd is less than optimal. Not sure if the way to solve this is writing native ASIO code, as it is done currently by Tim and Tom (;)), or to fix the portaudio stuff.
Guenter
but it works perfectly with audiomulch. it seems it's not a problem of portaudio (afaik ross bencina wrote portaudio and audiomulch), but the combination of portaudio and pd.
Thats what I meant with "the portaudio code of pd". Its the way pd uses portaudio that is wrong. First, I think it uses the maximum number of buffers. Then, the pablio (portaudio blocking I/O) thing is a bad hack, as portaudio is meant to be used in a callback model.
Guenter
PS: I have been talking with Ross about this and he sort of agrees, he is sitting in my office.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list