Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: David Olofson (audiality_AT_swipnet.se)
Date: ke syys 29 1999 - 17:53:29 EDT
On Wed, 29 Sep 1999, Paul Barton-Davis wrote:
> >> One application for really needed multitrack recording could be a recording
> >> of a concert or a play. I guess 16 tracks is then quite minimum number
> >> of channels.
> >
> >Indeed. And that's also an application where you *really* need high
> >reliability.
>
> Yeah, so high that Studer or OMB will charge you an incredibly large
> amount of money to provide it.
>
> As much of an audio evangelist for Linux as I might be, I don't think
> that 48 or 64 track recording consoles have ever been built around
> generalized microprocessors, and I suspect that because of the
> reliability issue, they likely never will be. One of the more
> expensive 24 track (analog) consoles I've seen has modular strips in
> it, and this is apparently highly sought after, since real studios
> can't afford to lose the whole console if there is failure in a key
> component. modular strips reduce the chances of this by a large
> amount- making the whole based around a single motherboard with 1 or
> more CPU's on it will likely get someone pretty pissed off when there
> is a problem.
So, use two or three machines, either 100% over capacity with distributed load
(also gives you some extra CPU headroom, just in case), or in parallel. In the
later case, the idea is to use a model similar to that used in aerospace
control systems. One scheme is to have all systems watch each other, and
disable a system that disagrees with the others.
How much reliability do you need? If there's money, there are solutions... And
Linux isn't all that bad a foundation to build on.
> The places that do this kind of thing with *digital* mixers, at least
> for now, are also the kind of places that are going to want to run
> real hardware consoles, and its going to be a while before Linux or
> any other non-custom OS is going to be capable of running that kind of
> beast with 48 or 64 channels of 48KHz+ audio.
Why? Lack of DSP power in workstation CPUs, lack of hard RT support with
protected memory, or what?
> No self-respecting or
> even semi-intelligent recording engineer is going to settle for a
> couple of physical faders and a monitor or two.
That's nothing to do with Linux, or any other similar OS. The instrument I'm
developing an embeded application for at work doesn't have a screen at all...
(You can hook one up for debugging with current version, but I'm planning to
drop that too, and kick the video board, if we can find a BIOS that can boot
without one.)
> I did see a Paris system at AES with 4 monitors and 4 control surfaces
> (48 tracks) running on a Pentium III in one of those cryo-cooled boxes
> allowing it run at 800MHz. Ensoniq rhetorically asked if this was the
> most powerful DAW ever built ... I can't imagine anyone being willing
> to use it for live recording of a professional event, and for lesser
> events, the number of channels is probably down around 16.
Hah! Well, I don't blame them... And in this case, it's the _Paris_ doing the
processing with dedicated DSPs. (That's why it's actually rather usable,
compared to most all native solutions.) The P-III 800 is only doing the disk
I/O and the GUI! What a waste...
> On the other hand, running, say, 3 RME Hammerfalls (3 x 3 ADAT = 72
> channels), with the DAC(s) in some hardware digital console, and Linux
> as the raw HDR seems pretty feasible.
Yes. However, you're still in for reliability problems here, if we're talking
about the live situations mentioned earlier. Or perhaps an uptime of at least a
few months is enough, after all?
Keep in mind that embeded systems usually have special boot/system "disk"
solutions that are quite different from what you find in the average server.
And they're shut down and rebooted (from R/O media) quite often, which means
you never come close to the average Linux uptime...
How much more reliable are dedicated DSPs really? A bug in DSP code means a
freeze or crash on that DSP (which may kill several plug-ins), as there's
usually no OS whatsoever, and certainly not one with protected memory, as that
can't even be done with most DSPs. RTLinux + protected memory would make such
things easier to control, and wouldn't take the system down. What the high
level control system code and GUI (if any) does is pretty much irrelevant - if
it segfaults, it'll just do a M$ NT/98 Explorer: Restart and hope no one
noticed that the icons went away...
//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
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST