Extremely slow Auto Duck - and a solution.
Posted: Mon May 06, 2013 11:30 am
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
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
