blixtsystems.com

With the new beta 2 version of Flash Player 10 the Sound API has changed a bit.

Most of the changes is very straight forward and only renaming of some methods, events and properties:

SamplesCallbackEvent is now SampleDataEvent
samplesCallback is now sampleData or Event.SAMPLE_DATA
Instead of accessing Sound.samplesCallbackData to write to the output buffer one now use the SampleDataEvent.data.

Tinic Uro has updated his examples if you like to look at some example code with the new API.

So basically very straight forward changes but there was one thing that I managed to waste a bit of time on. This is what the documentation say about the buffer size for the SampleDataEvent:

Provide between 2048 and 8192 samples in a SampleDataEvent object. For best performance, provide as many samples as possible. The fewer samples you provide, the more likely it is that clicks and pops will occur during playback. This behaviour can differ on various platforms and can occur in various situations - for example, when resizing the browser. You might write code that works on one platform when you provide only 2048 samples, but that same code might not work as well when run on a different platform. If you require the lowest latency possible, consider making the amount of data user-selectable.

If you provide fewer than 2048 samples, Flash Player plays the remaining samples and then stops the sound as if the end of a sound file was reached, generating a SoundComplete event.

All my code was using a buffer size of less than 2048 and hence did not work any more.
I'm not sure why the available range has been made smaller since it was nice to be able to lower the latency by having a 512 samples buffer.
I guess it is a common problem that Flash developers are a bit irresponsible with the users CPU power and I can understand that they want to avoid the reputation of being a CPU hog, but IMHO it's a bit like if they would have decided that the maximum frame rate should be limited to 20FPS.

Tags: Astro, Audio, flash player 10

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

Tags: AS3, Astro, Audio, benchmark, flash player 10