Re: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Fwd: [rtl] Beowulf and RTLinux (and NIC latency)
From: David Olofson (audiality_AT_swipnet.se)
Date: ke syys   29 1999 - 17:25:21 EDT


On Wed, 29 Sep 1999, Paul Barton-Davis wrote:
> >The point: I certainly don't see a significant hardware problem with
> >real time audio processing on clusters.
>
> The figures cited don't measure the kind of latency that I consider
> important in any likely audio system running on Beowulf.
>
> I would be excited about these figures if they were for the *first*
> packet after, say, 10ms of no packets at all. If they are, then
> whoo-hoo!

Well, if you get higher latencies in such situations, there certainly is a low
level hardware problem. However, I can't see what would cause such problems,
unless there's other traffic on the same network, that gets in the way. And
there won't be on a dedicated RT Beowulf - the cards are used as very fast
serial ports, and using full duplex cards with crossover cables (no hubs or
anything) eliminates collision problems, as there is nothing to collide with...

Besides, why would you drop communication for 10 ms in a system that constantly
transfers data with a cycle time of less than 10 ms? If there really is a low
level hardware problem (which I doubt there is, except in the case of a few
flawed NIC chipsets), it could be solved by just sending dummy packets to keep
the link in a stable state.

(Just to make it clear: I'm not interested in the lowest or average latency for
single events. It's guaranteed bandwidth with bounded maximum latency that
matters here.)

> >What's a few ms (if even that much) extra per node crossing (one or
> >two in the normal case) for mix down processing and playing from the
> >sequencer? People ar e actually *using* Windoze for that kind of
> >work... (*muhahaha...!* Sorry. I sure know what it feels like. ;-)
>
> well, it depends on whether you're doing production/mixdown, or
> real-time performance.

That's exactly the point. An RTL Beowulf would (at least with proper networking
hardware) beat any Windoze system on latency, reliability and, of course, CPU
power, which pretty much invalidates the point that Beowulfs would only be
usable for batch jobs. People edit and mix on Windoze boxes, and many seem to
just accept the more than noticable response times, and the inability of doing
any real time monitoring through the virtual mixer.

> most of my interest is in the latter, which is
> why, for example, i consider quasimodo to be an instrument rather than
> an equivalent to, say, ProTools or Logic.

I know, and I'm not suggesting that Beowulf is a viable design solution for real
time _instruments_.

(However, I might be wrong... I was afraid the hardware related latencies would
be much bigger, and that the peak latency was hardware related. Posts from
people working with this kind of stuff indicates that this is not the case.)

> but sure, if you're mixing down 128 stereo tracks of 32bit/192KHz
> audio, a beowulf cluster or three would be mighty handy, and would
> work just fine.

Yep, and even if you're right about the 100 ms, it's still very much better
than destructive/off-line editing - one of the most annoying parts of digital
editing. IMO, off-line edit operations can *never* be fast enough. It's simply
the wrong way to do most things I use DAWs for. Who likes waiting for the
results, or even stopping playback, when trying to be creative?

//David

 ·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    ·Rock Solid David Olofson:
    ·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
    ·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
    ·Open Source ·Singer/Composer


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST