Hi, On Audacity 2.1.0
the amplification-effect is slower than the noise-reduction-effect, I don’t think that’s normal because amplification only demand to multiply every sample by a factor, after having found the highest peak, first.
I didn’t look at the code, maybe I should find the relevant .cpp file and submit it directly here ?
The current version of Audacity is 2.1.1 http://web.audacityteam.org/download/
Your description does not match any known bug for Audacity 2.1.0 or 2.1.1.
you mean that on your computer, the amplification effect is fast ? not on mine, really.
you are right :
sampleCount EffectAmplify::ProcessBlock(float **inBlock, float **outBlock, sampleCount blockLen)
{
for (sampleCount i = 0; i < blockLen; i++)
{
outBlock[0][i] = inBlock[0][i] * mRatio;
}
return blockLen;
}
I don’t understand why it is slow on my computer !!!
We don’t know what operating system you use, which effect you run first and other steps to reproduce the problem, or any specifications of your computer including disk space available.
Can you give us those specifics ?
Gale
I Have a normal configuration :
windows vista, 4gB of ram, chipset soundcard, very bad microphone
and because of that bad microphone, when I record myself playing the piano (~5 to ~15minutes ) :
And my hard drive crashed recently so that I have to reinstall visual C++, then I’ll log the calls to EffectAmplify::ProcessBlock myself. See you in a few days.
On the timing tests I did for Audacity 2.1.1 Amplify showed a significant improvement over the 2.1.0 release - 14 secs versus 58 secs.
And on 2.1.1 it showed to be significantly faster than Noise Reduction 14 secs versus 43 secs
See attachment for full test results: http:
Timing tests 2-1-1 RC2 7Jul15.xls (22.5 KB)
WC
In contradiction of that, I never saw that difference on my Windows systems (7, 8.1 and 10). For me, both versions of Audacity average about 20 seconds for Amplifying 30 minutes of stereo audio.
Gale
Maybe that’ll help :
audacity with the last version 2.1.1
15min of stereo audio
the problem I noticed is that it is using only 7% (with process explorer) of my CPU while doing this (and 18MB of RAM)
(sorry for the spelling, I edited my messages)
EDIT : it looks like at the beginning it is consuming 7% to 10% of the CPU, but then it decreases and stabilize to ~3.5% after 30sec of processing
Amplify should be quicker than Noise Reduction. It is on my machines. If you are running games or Skype or Visual Studio at the same time, it may not be quicker.
Gale
that’'s why I opened the discussion at first…
I’m quite sure that you have a problem with threads priority or “sleep” calls in how
Effect::ProcessBlock
is repeatedly called and processed.
Who is “you”? From the contents of this topic is seems that the only one to see this alleged problem is you acx01b 
Perhaps you could give us some steps for how to reproduce the issue.
ok, I sucessfully compiled audacity (on VS2010 after a few… tricks) and I discovered how audacity saves onto the temporary folder the modified samples (to allow undo/redo). thus the speed at which effects are computed is dependent on how fast the OS (Windows) can write/read onto the disk, and if your disk is a SSD instead of a HDD it will be really faster.
C:\Users\YouFirstName\AppData\Local\Temp\audacity_temp
I think many of you didn’t know that, because nobody adviced me to delete that folder in order to allow faster writing there (less defrag). 15min of stereo 32bits samples at 44100Hz = 44410060152 = 317MByte so when you modify 2 times your track, it demands 1GByte !! you understand why it can be slower on some computers.
Secondly, I’m not able yet to say if that’s normal to take 30sec to 1min or more to write onto the disk 300MBytes of datas, or if audacity is buggy, I’m going to make some tests from scratch : just simulate what audacity is doing. from an empty program, creating 300MByte of random samples and writing it onto the hard drive. This would be the “reference speed test” which would be useful to be compared with audacity’s speed.
There is a very important parameter :
//audacity/src/sequence.cpp
int Sequence::sMaxDiskBlockSize = 1048576; // 1MByte
And modifying it didn’t yield very much success. It defines the size of the files which are written in the temporary folder (audacity_temp\project00\e00\d00\e000***.au**)
Finally, you (the developpers of audicity) should also think about allowing users to modify the track without saving the past samples (not writing it onto the hard drive and not allowing undo/redo) this way increasing speed (modifying 300MByte of RAM takes ~5sec) or maybe allowing to use more of RAM and less of hard drive sometimes. This is the SimpleBlockFile class which is managing that, directly calling wxwidgets::wxFFile and wxwidgets::wxFile class which directly write onto the disk, maybe you should replace these calls by a wrapper class deciding if it is better to write onto the RAM or the disk.
Thank you.
I did some tests, I write 300MB of datas onto the disk, as I said before, it is equivalent to 15min of sound. And what I obtain is :
thus the difference between 1MB files and 15MB files is not so high, thus modifying Sequence::sMaxDiskBlockSize wouldn’t change the performances so much.
But, this is also proves that audicity is TOO SLOW because writing 300MB of datas onto the disk shouldn’t take more than ~15seconds. If you want to do the test yourself there is the code is used for the test :
#include <cstdio>
#include <string>
#include <iostream>
#include <sstream>
#include <ctime>
void create_many_files(int size, int N, const std::string &strname) {
FILE * f = NULL;
for (int n = 0; n < N; n++) {
std::stringstream ss;
ss << strname << n;
std::string name = ss.str();
if (n%5 == 0) std::cout << name << "\n";
f = fopen(name.c_str(),"wb");
char * datas = new char[size];
fwrite(datas,size,1,f);
delete datas;
fclose(f);
}
}
int main() {
const int how_many_MegaBytes = 300; ////////// don't forget to verify the files have been deleted really !!!
system("mkdir test1");
system("mkdir test2");
clock_t t0,t1,dt; float final_dt;
t0 = clock();
create_many_files(1024*1024,how_many_MegaBytes,"test1\\test_1MB_");
t1 = clock();
dt = t1-t0;
final_dt = ((float)dt)/CLOCKS_PER_SEC;
std::cout << "time elapsed " << how_many_MegaBytes << "x1MB: " << final_dt << " seconds\n";
t0 = clock();
create_many_files(1024*1024*15,how_many_MegaBytes/15,"test2\\test_15MB_");
t1 = clock();
dt = t1-t0;
final_dt = ((float)dt)/CLOCKS_PER_SEC;
std::cout << "time elapsed " << how_many_MegaBytes/15 << "x15MB : " << final_dt << " seconds\n";
system("rm test1/*"); system("rm test2/*");
system("del test1"); system("del test2");
system("rmdir test1"); system("rmdir test2");
return 0;
}
Which version of Audacity did you compile?
I for one do not have a Solid State Drive (SSD).
We know that Audacity stores Undo and Redo data on the disk. If your disk is almost full, yes effects will be slower each time. This is why I asked you which effect you ran first. Were you using Amplify after Noise Reduction on a drive that is or was almost full?
For the benefit of other users, deleting the temp folder if you have not saved an Audacity project will destroy any existing data you can see in Audacity. If you have finished working on the data you can see, you can instead use File > Close to clear out the temp folder. You need to do that regularly if you are low on disk space.
If you need to clear our space in an emergency, retaining the audio you see, you can discard Undo layers at View > History… .
It won’t be that slow if you have sufficient disk space to work with. How much disk space did you have before you deleted the Audacity temp folder?
Audacity prior to 2.0.2 to used to have a (buggy, crash-prone) “Audio cache” feature to write to RAM rather than disk.
The feature was supposed to switch back from RAM- to disk-write when user’s memory fell below a specific threshold, but it usually crashed before that level was reached, usually after about 1.5 GB RAM was used.
Such a feature will never be as much use as it could be until we have 64-bit builds of Audacity for Windows. 32-bit Audacity as now could never address more than about 3 GB of RAM, even on 64-bit systems and even if we and the user made the appropriate tweaks.
If you want to try the Audio Cache feature and fix it up for us, that would be much appreciated.
Gale
I compiled the last one… the one on your SVN server. as you do yourself I guess.
about : Audacity 2.1.1-alpha-Sep 20 2015
Please, consider what I am writing as interesting, in the first place I did that because audacity was too slow on my computer, not because I’m an idiot.
and please consider the last message where I tested writing 300MB of datas onto the disk and that it took (only) less than 15seconds.
I think it would be interesting, first, to understand why it takes ~1min to amplify in audacity while I need only 15seconds to write 300MB of datas, there should be an important loss of time somewhere ? A performance analyzer tool would be useful.
And the history tool in audacity is useful too, thank you.
I never used so much of that performance tools for developpers, and I think the one of VS2014 is much better than the one of VS2010…
Much of Audacity’s “speed” in working with audio is supposed to depend on splitting into small blocks, and sometimes only manipulating the blocks that are necessary.
So I suspect your suggestion would require very considerable testing, notwithstanding a larger blocksize might make file writing marginally quicker.
Gale
You (and Peter when he tested 2.1.0) are the only ones who found Amplify might take an excessive time.
You yourself were previously attributing the slowness to lack of disk space. Can you write 300 MB to the drive in 15 seconds when your drive is as full as it was before?
And a lot depends what else the drive is doing at the time and whether Audacity should drive the CPU harder than it does.
Have a look at Help > Run Benchmark… in alpha versions of Audacity.
Gale
You don’t understand that in the same time, with more than 10GB of free space, audacity takes 1min15sec to amplify 15min of sound (which I looked in the history of undo/redo equals 300MB) while I need only 15seconds to write 300MB on my hard drive with a small test program.
Thus, there is a problem somewhere. It is simple and true.
That the problem is not present on your computer is disappointing, maybe you could compare audacity with the small test program I wrote ? My computer is quite old, ~2007 or 2008 for most of its parts, and Vista is probably slower than Win7 and 8 for some applications (like hard drive defrag managing).
EDIT : I tried to test the same thing creating 300MB of datas in the ‘C:\Users\FirstName\AppData\Local\Temp\audacity_temp’ folder and the result, 15sec at most, is exactly the same.
EDIT : there is the tool I should use for perf analysing (profiling), I guess https://msdn.microsoft.com/en-us/library/z9z62c29(v=vs.100).aspx