Subject: Re: [linux-audio-dev] non-destructive editing
From: David Olofson (audiality_AT_swipnet.se)
Date: la loka 09 1999 - 14:17:18 EDT
On Sat, 09 Oct 1999, Benjamin GOLINVAUX wrote:
> Hi,
>
> I want to implement a non-destructive editing app (basic operations : cut,
> copy, paste, process) and
> I thought of keeping consecutive editing chunks in different files, in order
> to be able to undo any number
> of actions. Then, I read that Fairlight MFX3, which is a rather old (1994)
> machine, uses chunks of 128K inside a _single_ file...
>
> Furthermore, I would like to be able to MOVE parts of one sound to another,
> possibly on another track,
> which makes the non-destructive stuff complex (I certainly don't wanna
> duplicate data until necessary).
>
> What's your opinion on the tradeoffs and advantages of both methods ? I don't
> wanna start with something I could regret later...
>
> Thanks.
I'd split the problem into multiple layers (in order of dependancy):
1) Playlist interpretation
First (execution time), you have to decied what to play, and when,
so that you know what data to stream. I'd use some form of playlist
that contains entries looking something like this:
struct playlist_entry_t {
int time; /* Samples */
clip_t *clip;
int track; /* for virtual mixer routing */
float level;
float pan;
};
clip_t is used by the editor to keep track of clips (parts of audio
files, or entire files) in a structured way:
struct clip {
char *name;
int file_id; /* ...or handle */
int offset; /* start in file */
int length; /* # of samples */
};
(file_id could be used instead of directly using the file handle,
as that would allow the disk I/O code to avoid reading the same
data multiple times in some cases.)
2) Data streaming
Here you need to make sure you can reliably deliver and record data.
Basically, you turn playlist entries into read requests, and feed
them to this layer. A similar scheme can be used for writing data.
Buffering will always be needed, and if you want to do processing
with less latency than this buffering means, you have to run this
part as a separate thread.
3) Mixing
This layer reads the playlist, and mixes the data from layer (2)
into a master output mix. It shouldn't care about the interaction
between layer (1) and (2), but just make sure the mix is correct,
and expect layer (2) to do it's job correctly. (If the data is
late, you're screwed anyway...)
There are many possible variants on this theme, but I think separate files is
the way to go in this case. The seek overhead reduction that a single,
interleaved file design means, would have the exact opposite effect as soon as
you move something more than that a delay in the mixer could handle it.
Note: A file with large chunks is *not* the same thing. Actually, it has about
the same effect as using mulitple files WRT physical positioning of data on the
disk. The difference is that it gets rather messy to remove unused data with a
single file design...
BTW, does anyone know of a fs that allows removing blocks in the middle of
files? (It's possible to do, but I'm not sure I would want to see the
resulting mess... :-)
//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:13 EST