lkml.org 
[lkml]   [1999]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.085 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site