Looper's Delight Archive Top (Search)
Date Index
Thread Index
Author Index
Looper's Delight Home
Mailing List Info

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

Re: Real-time category



 > Again, my understanding is that the EDP was designed so that the lapse
 > between command and execution is constant, and I believe that constant
 > is 1.5ms.  A constant 1.5ms seems to be plenty accurate enough for
 > musicians needs in this context (looping).  If you're doing engine
 > management on a rocket, it may be woefully slow.  I'm not talking
 > about MIDI jitter in this case, but the response time between user
 > commands and execution.

Response time and jitter are basically the same thing, jitter means
the response time is changing which can cause alignment errors if you
are not compensating for it.

If we ignore the potential for jitter, then the PC is just as accurate
as the EDP for recording.  Not for triggering, but I'll get to that
later.  There are two things involved here:

   1) MIDI latency, the time between when you press a switch till
      an "event" is received by the looping application

   2) Audio latency, the time it takes for something you were playing
      at the moment you pressed the switch to pass through the
      sound card and the OS and reach the looping application

In PC's MIDI latency (ignoring jitter) is on the order of 1 or 2
milliseconds, let's say 2.  It can actually be faster than that
but when synchronizing MIDI and audio, it is often quantized to
a millisecond boundary, which is accurate enough.

Audio latency is determined by the ASIO buffer size, 256 is typical
which amounts to 5.8 milliseconds of delay.

Note that unlike most dedicated hardware, on a PC audio latency is
higher than MIDI latency.  This means that even if it takes 2 milliseconds
to get the MIDI event into the looper, the audio you were playing when that
switch was pressed *hasn't even arrived yet*.  So the problem isn't that
we have to be as fast as possible processing the MIDI event, we actually
have to *delay* processing it by 3.8 milliseconds so that it is aligned
with the audio stream.  It is easy to get recording accuracy in a PC 
because
the increased audio latency gives us lots of breathing room.  If the
latency compensation is calibrated accurately and we are not experiencing
significant MIDI jitter there will actually be *zero* delay between the
MIDI event and its effect on the audio stream, they are in near perfect 
sync.
In practice they will be misaligned by one or two milliseconds which you 
can think
of as "response time" on the same order as the EDP.  You don't need an RTOS
to do this, we are simply compensating for known latencies.

What an RTOS will do is ensure that MIDI latency is 2 and always 2.
Never 3, never 1, never 20, always 2.  A non-RTOS cannot do that
when it is under stress.  What I am trying to explain is that when a
non-RTOS is operated within certain limits, you can expect to achieve
very consistent MIDI latency which when compensated correctly will give
you near perfect synchronization between MIDI and audio.

There seems to be this misconception that you will have wild
fluctuations in MIDI response time if you do so much as open a window,
or touch a key, or take a page fault.  This simply isn't true.  You
have to introduce a significant amount of system stress for that to
happen.  Sure it is possible, and it is also avoidable.

 > What I was referring to was the potential of unanticipated delays in
 > processing commands within an audio application which are a result of
 > OS design that are possibly beyond the ability of a regular user to
 > address.

Yes, there are things that the computer owner must do and things that
the software developer must do.  Like any machine, the owner must
operate it within certain limits and they are not particularly
difficult limits to follow.  But the software also has to be written
to detect latencies and inconsistencies and compensate for them.
There is nothing fundamentally flawed in Windows XP or Mac OSX that
makes this impossible.

 > but many people have the experience of
 > loading down HD recording software with a too-heavy load of plug-ins,
 > tracks and edit points no matter how fast the computer is.  The
 > display stops keeping pace with playback, recorded audio may get
 > choppy, MIDI and audio tracks lose sync, and eventually you get an
 > error or a crash.  With something like the EDP, the UI has been
 > optimized and stripped down to a set of possibilities that essentially
 > prevent this from happening given the overall performance of the
 > system.

True, but this isn't relevant to the RTOS discussion.  A computer will
behave badly if you exceed its limits.  So don't.  The EDP doesn't
allow itself to be overloaded.  Fine, but now we're talking about UI
choices not RTOS issues.

 > Again, I've always been referring to looping-type tools, not soft
 > synths or amp simulators or what have you.

If you're referring to my comment about keyboard players, the point was
that if there truly was dramatic and unpredictable variance in MIDI
timing, then the problem would be much worse for a keyboard player
than a looper because they are pressing keys a thousand times more
often than loopers are and they are extremely sensitive to "feel".
If they don't have any insurmountable problems, neither will loopers.

Jeff