lkml.org 
[lkml]   [1999]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: real-time threaded IO with low latency (audio)
Steve Underwood wrote:
(...)
> > Coments, facts, figures?
>
> It sound like the problem is being structured in the wrong way.

I'm afraid not. I've though of and seen many different ways of doing it
over all these years I've had this project in mind (looking for a real
OS to build it on)...

> If you want a 32
> channel mixer why use 32 files?

Because we're not talking 32 hard sync'ed surround channels here, and
I'm not going to implement yet another backwards emulation of an analog
multitracker. Tracks may be recorded a few at a time, and most
importantly, will be moved around and reused as desired when editing the
project. Actually, ther audio clips should be directly usable with the
virtual sampler in order to get everything under a common system, which
forther complicates things, as each sampler voice will have a locked
buffer of a few hundred kB, and will start streaming audio into these
buffers as soon as any channel starts playing.

> That's bound to cause major seek overheads,
> whatever the file system.

It didn't on my old Win16 engine playing 16 individual stereo files, and
it doesn't on Cakewalk 8.0 with a proper configuration. (That is FORGET
anything TTS says about disk I/O buffer size - they obviously have no
clue about how hard drives work physically...)

> Why not have one file, with 32 audio streams
> interleaved inside it.

(See above.)

> If you want just one or two channels, there is lots of
> hopping around, but the system load is light at that time. When you want all 32
> channels at once you read or write a stream with very few seeks. 34 interleaved
> sections might be even better. That way you have room for a final stereo
> mix-down too.

And what happens when the user starts moving individual tracks in time?
;-)

Interleaving is good if the primary goal is to keep disk access latency
down, but as streaming buffers of just a few hundred kB per stream
solves the seeking problem easily, and background preloading when the
user moves the play position eliminates most delays when operating the
system, I see no reason to do it any other way. It's tested and works.
:-)


> Steve


//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.124 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site