[PD] Midi timing and ASIO under NT

[Daniel Heckenberg]

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 at 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
> >
>
>