Re: [Audacity-devel] bugs/rewordings?

[Richard A. <ri...@au...>]

On Tue, 2007-10-02 at 17:32 -0700, Vaughan Johnson wrote:
> > Agreed.  To use a new track for the result and copy it back at the end 
> > is the solution I came up with recently for the EQ - great minds think 
> > alike!  It made the code much simpler and easier to understand in that case.
> 
> Seems the right way, but the main thing I was looking for feedback on, 
> is whether this is likely to have a big performance impact. We'll be 
> copying possibly very long selections for *every* effect, so memory and 
> speed might become issues. For instance, ripping a whole LP and applying 
> Normalize to the whole thing could cause a lot more swapping. Of course, 
> that's a go-away-for-a-while step, anyway.
> 
> Anybody have opinions on that?

I don't think it has to be any slower than any other way of doing it, if
the underlying data storage code is smart enough. It probably isn't
right now, but I'm prepared for audacity to slow down until someone
writes some more optimised storage code if it improves our correctness.

At the start we have one copy of the unprocessed audio in the project.
At the end, we have one copy of the unprocessed audio in the undo, plus
one copy of the processed in the project.

So we have copied the data once anyway (to have the undo buffer). I
think what I'm looking for is a fast copy-on-write copy constructor for
tracks, whereby you can copy an existing track, and it does almost no
disk work because the data is the same and it just ups the refcount on
the original files. Then when you modify that track, it realises you
can't modify those files, and writes new ones with the changed data.
Thus, we only get one lot of file reads and file writes to process the
copied track through the effects, and then a pointer-change operation to
replace one track with the other.

I'm not saying this is how it works, or how it should work now, but it
could work this way, and the changes are in Track and Blockfile, so we
can go ahead and make the changes in the effects, with the performance
improvement comming later.

Richard