There's no control over blocksize in ASIO, but there should be. In the ASIO interface, Pd blocks in chunks of the audio blocksize, whereas for MMIO it blocks in periods of "sleepgrain" (because it does audio I/O by polling, not blocking.) ASIO really should be done the same way, but in the meantime I should just offer control over the "blocksize" which I haven't yet... I'll try to put that in.
By the way, with the RME hammerfall I'm getting about the same latencies (30-ish MSEC) and CPU loads using MMIO as ASIO, which doesn't sound right.
cheers Miller
On Tue, Jun 18, 2002 at 11:53:33AM +1000, Daniel Heckenberg wrote:
Hi all,
So I've been looking at midi timing with PD 0.35test26 and trying to get things running nicely.
I have an RME multiface which I'm using for audio and midi I/O.
Using the MMIO driver (the default in PD) and using -sleepgrain 1 I can get nice, tight midi timing irrespective of the audiobuffer size.
Using the ASIO driver (which should have the usual advantages for audio) I can't get any better than 10ms granularity / jitter in the delivery of MIDI messages. The -sleepgrain option has no effect, nor does playing with the -audiobuf option as far as I can see.
BTW how does the -audiobuf option interact with the ASIO buffer size setting for the audio driver?
Thanks, Daniel