Extremely slow Auto Duck - and a solution.

[jcxz100]

I have been using Audacity for some hobby projects for several years now, and as I started to use the Auto Duck feature I immediately wondered what made it so slow??
For a 4:30 song it would take over 20 minutes to complete - on my system.

I quickly discovered that it didn't use any CPU at all and my suspicion turned to extensive disk i/o (my harddisk is very slow).
To cut to the chase: This turned out to be right!


I've just been able to compile Audacity 2.0.3 for the first time, and I've tweaked one single element. The buffer for Auto Duck is set at 4096 samples which means a theoretical memory use of 4KB x 4 x 2 (i.e. samples x sizeof(int) x stereo) = 32KB. I tested with the following buffer sizes: 8192, 16384, 32768, 65536 and 131072 samples (8K, 16K, 32K, 64K and 128K samples).
I only Auto Ducked the first minute of my song.

My findings can be studied in detail here:
https://docs.google.com/file/d/0B-9LFBx ... sp=sharing (raw data text document)
and here:
https://docs.google.com/file/d/0B-9LFBx ... sp=sharing (excel sheet with graph)


My conclusions are:

1) There is an inverse relationship between buffer size and the following measurements:
- total duration (2:59 for ordinary Audacity with 4K buffer, 0:04 for 128K buffer)
- number of i/o writes (6411 for 4K buffer, 312 for 128K buffer)
- time spent in i/o (2:38 for 4K buffer, 0:03 for 128K buffer)
- time spent in CPU (0:21 for 4K buffer, 0:01 for 128K buffer)
At least for these buffer sizes (and probably if we made it smaller). There seems to be the beginning of a flattening of the curve between 64K and 128K - but everything is so fast for those, it's hard to be sure.

2) Even though it would seem reasonable to expect a relationship between buffer size and memory use, there is in fact no sign of this.
From my experiments it seems that Audacity uses same amount of memory no matter the buffer size.

3) The max memory used for running the effect is below the peak memory used when loading the project - for all buffer sizes.

4) CPU max are about the same for every buffer size (around 20%) except for the ordinary 4K buffer Audacity, where it never gets above 15%. Probably because it is so busy doing disk i/o.
Also I noticed (but didn't otherwise document) that the CPU drops to 0% at long periods for 4K and 8K buffer Audacity. This is still seen for 16K and 32K buffers though not for so long or so frequently. Even the 64K buffer version dropped to 2% during my test, but the 128K version was so fast I didn't see anything like that.

Summa summarum:
I find that the Auto Duck buffer size ought to be set at 128K samples rather than 4K samples.
It's this line:
#define BUF_SIZE 4096 // number of samples to process at once
in the file "src/effects/AutoDuck.cpp"


My system:
- VS2008 Express
- Windows XP Home SP3
- 2.2 GHz Intel Core2 Duo
- 2 GB RAM
- 120 GB hdd
(I would like to post something about the speed of my hdd, but I don't know how to test to get the data that people would want to see).


// Lasse

[jcxz100]

I apologize for posting the above in the wrong part of the forum...
I suppose it should have gone in the "bugs" section.
// Lasse

[steve]

I think there must be something else going on as you get very different results to what I see.
5 mins stereo 44100 Hz sample rate -> 1 min 8 seconds processing time. (50% CPU load, equal to one processor core at 100%)
There is no excessive disk activity.
My computer is a cheap Acer laptop running Linux.
Hopefully someone else can test on Windows to see if this is OS dependent.

[jcxz100]

I think there must be something else going on as you get very different results to what I see.
5 mins stereo 44100 Hz sample rate -> 1 min 8 seconds processing time. (50% CPU load, equal to one processor core at 100%)
There is no excessive disk activity.
My computer is a cheap Acer laptop running Linux.
Hopefully someone else can test on Windows to see if this is OS dependent.

I just tested - my system runs 5 minutes of 44.1 kHz stereo at 0:01:20 now, which is almost as good as yours.
It doesn't go above 20% CPU usage at any time - probably because it has a so much slower disk than yours. If I could get it to run at 50% CPU it would be 0:00:32.
Maybe you could get the same benefit?

(If you saw the post I just deleted where I claimed to be running 5 minutes song in 20 seconds, it was due to me setting the threshold wrong *blush* )

// Lasse

[Robert J. H.]

On my W7 64 bit Desktop Computer, The processing has taken 50.9/51,7/48.8 s.
The hard disk is a new Western digital made for continuous work (such as in surveillance camera systems), not the fastest on the market but reliable.

[jcxz100]

Alright, I must admit my PC seriously blows when it comes to disk operations!

But I just tested on 2 other Windows PCs:
- My children's WinVista laptop
- An old (and quite unstable) WinXP destop PC
For both systems there was an incredible difference between running the ordinary Audacity and my increased buffer version.
One minute conversion ran in just a few seconds for both systems!

You can see a video capture of the test I did on the laptop here:
http://youtu.be/azysc3pOBLM


If anyone is interested in repeating my tests and doesn't have the patience to compile Audacity 2.0.3 themselves, they can download my exe file here:
https://docs.google.com/file/d/0B-9LFBx ... sp=sharing
But I would recommend you did the compile yourself (and also a Linux version would be nice!) so you know I didn't fiddle with anything


// Lasse

[steve]

Thanks jcxz100. I've tried your modification on Linux and I can confirm that there is a considerable speed increase (about 20 x faster).
I'll forward your modification to the developers.

[steve]

I'll forward your modification to the developers.

Posted here: http://audacity.238276.n2.nabble.com/20 ... 58144.html

[jcxz100]

yay

[steve]

Congratulations jcxz100, you've just had your first patch added to the Audacity code base
http://audacity.238276.n2.nabble.com/20 ... 58144.html

Martyn also added a couple of other changes which you can see here: https://groups.google.com/forum/?fromgr ... 6xVj8YTKTI