Re: Real-time category

[Jeff Larson <Jeffrey.Larson@Sun.COM>]

Stefan,

I've read through your comments, and I don't think we have the same
understanding of how ASIO works.  Before responding to your points, it
may be helpful to agree on some basic concepts.

When you set the ASIO buffer size, you are actually defining 4
buffers, a pair of input buffers and a pair of output buffers.  The
driver is performing "double buffering".  At any moment in time, the
sound card is filling one of the input buffers and the application is
processing the last input buffer that was filled.  The application is
also filling an output buffer and the sound card is playing the last
buffer output buffer that was filled.  Graphically it looks like this:


                                                Output Buffer 1 --> Sound 
Card
                  Input Buffer 1 --> Looper --> Output Buffer 2
    Sound Card --> Input Buffer 2


ASIO does not say that during the audio interrupt the input buffer you
are receiving and the output buffer you are filling represent the same
moments in time.  It can't because that would violate the laws of space
and time :-) They are synchronized only in the sense that they advance
at exactly the same rate.

Anything the application puts into Output Buffer 2 will be delayed
because the sound card is busy playing Output Buffer 1.  The musician
is hearing what is in Output Buffer 1.  What the musician is playing
is being recorded into Input Buffer 2, but the looper won't receive
that until the next interrupt.  The sound the musician is recording
and the sound the musician is hearing are dealigned by the length of
two ASIO buffers.

It may help to think of these buffers as lengths of recording tape.
Let's exaggerate the latency and say that each buffer represents 1
minute of audio.  The application can consume and fill these lengths
of tape almost immediately, but the sound card can only record and
play them slowly at exactly 44100 samples per second.  The application
spends most of its time waiting for the sound card to record and play 
another
length of tape.

Now let's say that your audio stream command to "play loop 1" enters
the sound card.  In the worst case, the sound card has just begun
recording Input Buffer 2.  So your command is going to sit there for
one minute while the sound card fills up the rest of this buffer and
the application is waiting patiently.  After a minute, the application
gets an interrupt and a new pair of input and output buffers.  It
looks in the input buffer and notices the command.  It then
immediately copies the first part of loop 1 into the output buffer.
But nothing happens for another minute because the sound card is still
playing the piece of "tape" you gave it in the last interrupt.  After
another minute, there is another interrupt, and the sound card finally
begins playing the beginning of loop 1.

The musician meanwhile is wondering why after pressing that trigger
switch they don't hear anything for 2 minutes.  There is nothing you
can do to compensate for this without guessing when the switch is
going to be pressed before it is actually pressed, or going back in
time and changing the "tape" the sound card is playing.  The only
thing you can do is lower the input and output latencies to the point
where the combined delay is so small that it is difficult for the
musician to detect.

Here's a simple test you can do to demonstrate this.  Connect one of
the output channels of the sound card to one of the input channels.
Have the application output a short pulse and count the number of
samples until this pulse appears at the input.  It will be 2 times the
ASIO buffer size plus a few extra samples for the latency introduced
by the digital/analog converters on the sound card.

Agreed?

Jeff