Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: pe syys 24 1999 - 11:12:47 EDT
On Fri, 24 Sep 1999, Paul Barton-Davis wrote:
[ ... network latency discussion ...]
single message low enough to provide a shared-memory like
> environment. There have been some really cool tricks that have enabled
> Beowulf to take off, but a 100ms delay in response to a MIDI NoteOn is
> going to make you the laughing stock of AES :)
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 ?
>
> 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 ?
[ ... 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
checking for evens in 1 sample steps if you want sample accurate
latency, but scheduling jitter will completely ruin this accuracy.
Therefore it makes no sense to me to check for new events on every sample.
He is assuming that all events will be timestamped, and therefore the output
will be sample accurate for sequenced MIDI events , but the latency will be
constant.
Live MIDI input, will have an event delay of 64 samples, but I'm not sure how
precise the timestamps will be due to scheduling jitter,
but anyway below 1ms with Ingo's patches, that means better than the
MIDI wire resolution.
regards,
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST