Messages in this thread | | | Date | Sat, 24 Jul 1999 19:40:15 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
Paul Barton-Davis wrote: (...) > Do you know anyone who does professional HDR on a computer?
Yes, but off course, they're not very happy with it. I'd never even try with any of the existing "solutions". They're only usable for editing.
> I don't, > and everything I've read in EM and Mix suggests that nobody in their > right minds does this.
And I fully agree with them.
So, why does computer based recording suck? Simply because doing it on OSes WITHOUT HARD REAL TIME support will not work, EVER! The kind of virtual mixer response times required for such a system to be usable cannot be handled without dedicated hardware... unless you have true hard real time support in the OS. We're not talking about the average multimedia application here.
> Protools interfaced with a computer, Paris > interfaced with a computer, yes, but thats not what we're talking about.
ProTools and Paris have their own DSPs, but use the computer's hard disk for recording. As long as there is sufficient buffering (which means at the very least one second for most OSes), there shouldn't be a problem, as long as you're not overloading the hard drive.
Soundscape HDR, OTOH, has it's own HD, and is only remote controlled from the PC. It still has the same problems as a computer based system, but as the HD is 1) dedicated to recording and 2) not used for more tracks than it can handle under any circumstances, it's reliable. (SSHDR DOES however get problems if you don't defragment the HD for too long... Unless you design a file system that doesn't need defragmenting even when streaming multiple huge files "simultaneously", you'll just have to accept defragmenting as a standard maintenance procedure. Analog machines require more work in that area, BTW.)
> >Audio/MIDI sequencers. > > MIDI sequencing is not a problem, or rather, its certainly not a deep > problem. Audio is, however.
MIDI IS a problem, unless you accept that some notes are delayed by a few ms every now and then. (It doesn't matter that mosts synthesizers delay the notes by 2 - 30 ms; the delay is from when a MIDI event arrives. MIDI have no time stamps...)
The only difference with audio is that if your data is late, you're screwed. You get a drop-out, while a MIDI note "just" gets a little late. IMO, neither case is acceptable.
> >"Cool" Windoze/Mac DAW style > > These all rely on external hardware if they do the job > right.
I disagree. It's just a matter of using the right kind of OS so that the resources at hand can be used properly.
> Furthermore, many of these packages are soundfile editors > and playback systems, not real-time processing systems. Linux can do > this stuff OK already, though I guess there are still playback > problems to be fully solved.
Well, that's another discussion... (However, I certainly don't like playback problems when editing. It's not the end of the world, though.)
> >Yeah, Kyma/Capybara looks pretty nice. Can you send me a system? ;-) > > I'm about to buy one. I'm setting up the first semi-pro Linux-based > recording studio :) We'll be using Windows or Mac stuff for a while > and then gradually move into a 100% Linux configuration as I manage to > get Creamware (Scope) and Symbolic Sound (Kyma) to co-operate :)
Sounds nice! :-)
> >BTW, do you think you can expect a UN*X-like programming environment > >when programming Kyma plug-ins? > > No. Its a graphical system. You build stuff with the mouse, then the > Mac/Windows software compiles it down to 56309 code, and ships it over > the wire to the Capybara.
Well, that's pretty much what I have in as one use for Audiality. Only, you don't need an external box to do the actual processing.
(What I meant was thinking about was actually the system that's running on that external box for example. They all run some kind of OS, with APIs and all.)
> >Well, off course it all depends on what you want to do. I want rock > >solid recording and editing with real time monitoring through the > >virtual mixer. Preferably, everything should be running as long as the > >audio apps are running. The feel of analog machines and dedicated boxes > >with the advantages of having it all in the same environment. > > I want the same things. I'm just not sure that I want to use RTL to do > it. But I'll think more about it.
What would you have against Audiality (or RTL or whatever it will run on in the end) as an end user? Apart from it all being open source, a dual Alpha AXP or Xeon is a nice machine to play with when not using it for recording... :-)
> >need buffering in the order of seconds, unless you want to grab the > >fastest drive money can buy > > thats my general plan, yes :) i think seagate cheetahs are about it > for now (5ms seek time, they fly!)
Nice drive, AFAIK. :-)
But have you though about this: Instead of moving the heads for 5 ms, the drive could read or write about 100-150 kB of data. (With reservation for inaccurate transfer rate figures - I don't have the data sheet at hand.) When playing 32 tracks and buffering 200 ms (no kidding! this is how many applications are doing it...), 80% of the time will be lost to seek times. (At least under Windoze, as it's capability of keeping track of more than one file at a time is practically nonexistent.) That means you'll use around 70 % of the maximum transfer rate, while under Windoze, the practical limit (where you simply can't keep the recording/playback running for more than a few seconds without a drop-out) is usually at 60%.
Also note that these are figures I got when I played with my old Windoze base 16-bit engine. It played 16 stereo tracks from a 5200 rpm 5.2 GB drive rather reliably on a K5-100 while doing 32 bit integer mixing (pan+level for each mono track). Most applications are having problems doing that on much faster machines...
Read-ahead buffering makes all the difference. And with low latency processing, a fast drive and smart caching/buffering code, there will be no irritating delays when pressing the start button, so there's nothing to lose.
//David
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |