May 302008
 

Playing around with the new Flash player 10 audio processing functionality the need for optimization becomes very apparent when you want to apply effects to several tracks of audio.

With a sample rate of 44100 and a dozen stereo tracks we are talking over a million samples to be processed per second where each process you apply will have probably at least some 30 operations. All of a sudden the great performance of AVM2 becomes quite limiting.

So it’s important to squeeze out every drop of performance you can by optimizing the code.
First of all I have been benchmarking the performance of running code inside the processing loop, in a function, in an external class and inside a loaded swf (would have been neat for the possibility to plug in effects without recompiling the main swf).

The code I used for testing was to process a value and return it like this (obviously without function enclosure when doing the processing in the local scope):

public function calculate(num:Number):Number
{
	return num * 1.01;
}

The time needed in ms when calling the function 10 000 000 times:

  • Locally: 46
  • Calling a function in the same class: 213
  • Calling a function in a separate class: 213
  • Calling a function in an externally loaded swf: 2347

Not so surprising results.
Having processing code in an external swf is obviously not an option. I tried with both simply sticking a function in the swf or in a class which I retrieved by applicationDomain.getDefinition and both methods performed equally bad.
Doing processing locally instead of in a separate function or class is a lot faster, but obviously that could easily becomes very cumbersome and ugly.
At least there is nothing lost on having the function in a separate class compared to having a function in the same class.

Something that does surprise me a bit is that when just calling the function once and having the loop inside the function instead the resulting time was 75ms.
That’s about 30 ms added for just one function call so it seems like the first call is a lot more expensive.

One would think that the conclusion is that the best approach when processing audio if one like to avoid placing the code inside the samplesCallbackEvent loop seems to be calling the processing code once and then iterate over the size of the buffer in the class for the effect.
This is exactly what I was suggested by Spender when I posted a 3-band EQ example.

The problem there and why my attempt at implementing his suggestion failed at making an improvement is that reading and writing floats in a ByteArray is slower than the function calls.
Testing to writeFloat 10 000 000 times to then read loop through them to read them again takes 1727 ms. So compared with the 213 ms doing the same amount of function calls it’s clear that function calls actually is comparatively cheap. A Vector fares a bit better then the ByteArray with 1239 ms.

So the optimal approach seems to be to only do samples.readFloat once then use the returned value doing function calls for each process you like to apply before you do samplesCallbackData.writeFloat

Share/Bookmark

Switch to our mobile site