Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe syys 24 1999 - 15:56:58 EDT
[ network latency ]
>100ms seems rather ridiculous to me ..
>the ping (64bytes ICMP) round trip time between 2 machines is <1ms on
>an idle 10mbit LAN,
>that means as long as you use the LAN for audio-only,
>you can get <20-30ms latency easily,
>or am I missing something ?
yes, you are. ping doesn't tell you how long from when it, the
application, decided to send its first packet until the reply
arrived. it tells you the time between the packet timestamps. so,
sure, it the round-trip-time is <1ms, but how long did it actually
take from the decision to send until a reply was received ?
>> So, I don't think that clusters are viable for real-time audio
>> generation when you want sub-100ms event latency. They *are* fantastic
>> as rendering farms, the way that ILM uses them, for example. Its easy
>> to imagine some very impressive audio generation taking place on a
>> cluster, but without any input devices to "disturb" the computation.
>
>What do are input devices ?
>MIDI masterkeyboards , or mouse/keyboards which cause X traffic
>slowing the audio event flow ?
both. anything that causes some I/O that has to be handled by the X
server and/or a thread. it could be the RTC as well.
>[ ... sample accuracy ... ]
>
>> how can this work ? lets suppose that there are no events pending. you
>> just call process(..., 64) to generate the next 64 samples. someone
>> causes a MIDI CC message that is supposed to alter how the plugin
>> works. this is presumable queued in `events', but how is the plugin to
>> know to look for it ? it will be queued up after the terminator event
>> in the `events' "list" you pass in, so it can't see it during this pass.
>>
>> so in this case, you've got a 64 sample event latency. to get this
>> down to 1, you've got to tell the plugin to only generate a single
>> sample.
>
>Yes the event latency will be 64 samples, there is no way around
but there *is*. Quasimodo has no inherent input event latency at all!
of course, in real life, the delay between a byte arriving on a wire,
and the EventManager thread running the relevant callback is
non-zero. but Quasimodo's UI and EventHandler can directly tweak the
data the DSP works on without having to tell the DSP at all. NOTE: i
qualify this below.
>Therefore it makes no sense to me to check for new events on every sample.
I would go a step further. Event checking is wrong as a general
design.
When events *do* matter is not for parameter changes, but for things
that alter the program that the DSP simulation should be running. An
example is a MIDI NoteOn or its equivalent.
In this case, paying attention to the event is not just a matter of
altering a memory value, but inserting a whole new series of
instructions into the DSP's current program. This has to have a
certain latency associated with it, and in Quasimodo (and to some
extent Csound and possibly SuperCollider as well), its determined by
the control cycle period. So, if the cycle is set to 64 samples, and a
MIDI NoteOn arrives just after a new cycle has started, then we have
to wait for the rest of the cycle till a new voice is audible/new
effect starts/whatever. *BUT* (and this is *very* important), if a
MIDI CC message or its equivalent arrives, it can be handled
*immediately* with no latency whatsoever (*)
This idea comes from a careful reading of papers on DSP design, and
thinking a lot about the benefits of running a DSP simulation in
software and how we could end up with the best of a fixed program DSP
a variable program DSP and a general purpose CPU. After all, *I* am
the one designed the "Quasimodo DSP", and I can make it do anything I
want :)
A key idea inside Quasimodo is the notion of run-time editing of the
DSP program(s) (aka the set of plugins currently running), and its
this that allows overhead-free patching between modules. For example,
in Quasimodo, when one plugin writes a certain value to its "output",
there is no "message" to connect it with another plugin that is
nominally connected to it - the same memory location is used by both
plugins, without them being aware that the engine did some run-time
editing to make it so. I am very happy with the way this idea has
turned out in practice - its very powerful, IMHO.
--p
(*) writing this reminds me that i need to make careful use of the
volatile keyword in writing opcodes. excessive use prevents gcc's
optimizer from doing its stuff, but inadequate use will cause there to
be a control cycle's worth of latency whether i designed it that way
or not.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST