From: Jim Peters (jim_at_uazu.net)
Date: 2002-03-28 21:10:15
John Morrison wrote:
> I've been having a think about the idea since it was put up and I do like it
> as we should reduce contact switching as much as possible. Though I "think"
> there "maybe" problems too.
>
> MY ANALYSIS
> So as I understand it a data byte arrives at the device which in some way
> triggers the "network" which executes the following actions.
> > dev->process();
> > fb1->process();
> > fb2->process();
> > xmas->process();
> Sounds great (I do like the idea) until we realise it's a REAL TIME system
> we are working toward.
>
> So lets plug some (Made UP) figures into this system and apply some
> restrictions and assumptions to the system.
>
> Assumptions
> ALL inputs and outputs aren't buffered and can only hold 1 byte of data at
> a time.
> TI = Time Interval
>
> Timings (No basis in reality just for demonstration)
> DEV
> Input arrives every 1 TI
> stay valid for .5 TI
> Process takes .5 TI
>
> FD1/2
> Process takes .5 TI
>
> xmas
> Process takes .5 TI
If the processing for every sample takes longer than the interval
between samples, then we are stuffed in any case -- even if we had a
different networking model, or huge buffers, the processing would just
get farther and farther behind the input.
So, in your model, the total processing must be less than 1 TI,
whichever way we arrange the networking code. If it doesn't, then
your computer simply isn't fast enough to do what you want to do.
The only way around this is to do what you do when you are handing
audio, and that is to optimise the processing code by breaking up the
audio into 64-sample (or larger) chunks, which are faster to process
and pass around. However, in our situation, dealing with data at
256Hz, say, working in 64-sample chunks results in a 250ms delay.
For the kind of data rates we're using (e.g. 256Hz, rather than audio
rates of 44100Hz), I think processing one sample at a time would be
quite feasible. Working in chunks of 4 or 8 samples might also be
do-able, which could give a small increase in speed, but I don't think
it is worth the extra coding complexity and signal delays. Also, it
really would start getting messy if we tried to handle signals with
different sampling rates in 4-sample chunks (e.g. 16Hz and 256Hz).
As a guide to the processing power required, imagine what kind of spec
machine you would need to run a network in one of those audio plugin
platforms like Buzz or Cubase, and then remember that we're dealing
with data at roughly 1/100th of the sampling rate. So we don't need
*that* powerful a machine to do what we want to do.
I hope this helps --
Jim
-- Jim Peters (_)/=\~/_(_) jim_at_uazu.net (_) /=\ ~/_ (_) Uazú (_) /=\ ~/_ (_) http:// B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:43 BST