Hi Miller,
Ah. Thanks for this info.
As for latencies, I've not tested under heavy CPU load but seem to be able to run at -audiobuf 24 (24ms?) with both ASIO and MMIO with occasional dropouts when loading patches etc. That seems to be as low as PD will let me go with MMIO before hitting minimum number of buffer limits. Using ASIO I can go lower but start to suffer dropouts in general operation.
On the CPU usage issue: I'm guessing that the main advantages of ASIO in this regard are a more efficient buffer replacement strategy and direct floating point input/output? So one would expect to see only small differences in CPU usage, unless many channels are being used. Somewhat unscientifically, I tried the denoise example patch (at random) under ASIO and MMIO and was surprised to note that CPU usage seems to double under ASIO... (from ~5% under MMIO to ~11% under ASIO). The other patches I tried seem to have no discernible difference at all (which is what I'd expect for stereo in stereo out tests). (PIII-M 1.1Ghz running w2k, rme multiface). I was just using the Windows Task Manager for CPU measurement so there may be other spurious factors.
My biggest problem in this area is actually running audio at the same time as GEM. To allow loading the CPU up doing GEM frame processing means that the audio latency has to be at least a frame time (40 or 50ms). I guess the only way around this is to put GEM rendering into a separate thread. I might look into that possibility.
Thanks, Daniel
-----Original Message----- From: Miller Puckette [mailto:mpuckett@man104-1.ucsd.edu] Sent: Wednesday, 19 June 2002 1:13 AM To: Daniel Heckenberg Cc: pd mailinglist Subject: Re: [PD] Midi timing and ASIO under NT
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