As André already mentioned we have finally got an Ogg Vorbis Encoder in ActionScript 3. André wrote a lot about the benefits already.
Now what I really like about the encoder is the way we could minimize the encoding time by ~50%! I know two implementations of Ogg Vorbnis. One is written in C and another one in Java. What we did first was just getting it to work and it looked pretty much like the C/Java version. Then we started optimizing the code by comparing the encoding results always to reference files. I am quiet happy because on my machine we reduced the encoding time from 32sec to 16.5sec with simple optimizations and tricks.
Where to go from here? Of course we think the best we can do is to open-source the encoder. But there are a couple of other things in my mind. I started modifing Tamarin and added two functions to the Math class. Those convert a Number to its binary IEEE32 single-precision representation and vice versa. With those two functions we could get huge speed improvements for performance hungry tasks like this one. I hope Adobe will not forget about this as well — there seems to be general problem currently trying to support the simple Flash user on the one hand and the “Flash explorer” on the other hand.
I know you may ask what this feature could be good for, but doing floating point math using bitwise operations is a killer when it comes to performance. We are currently not allowed to do this and there is no reason for that.
contratulations, dude! this is by far one of the coolest things I´ve heard of since…I don´t know, threading? :) to be honest I didn´t think it was possible for the flash client so hey, it might be time for me to check out as3 to and not stubbornly wave the java flag :)
I wonder how long it will take before someone (like you or Andre) will totally abuse those new Hydra shaders in FP10, and create something entirely different from it (like you did for that incredible SoundTool).
If you could encode your input data in a bitmapData, then offload it to the GPU for some insane processing with some wicked shader, and then read the resulting pixels back you might be able to do some crazy stuff.
Macaca: I wrote already some code to do very interesting things with Hydra. I hope that I will be allowed to post about this soon. It is all about recompilation at runtime.
I vote too for Number bytes conversions, for (fast) 32 and 64 IEEE formats. They are pretty useful in NekoVM already.
Yes, I want to have this! I tested already with Tamarin and speed improvements are huge …
int MathClass::floatToIntBits(double x)
{
float f = (float)x;
int i = *(int*)&f;
return i;
}
double MathClass::intBitsToFloat(int x)
{
float f = *(float*)&x;
return (double)f;
}
If you want to vote: https://bugs.adobe.com/jira/browse/FP-487
is there also a vorbis decoder?
There is one existing afaik. SpliceMusic was decoding vorbis samples at runtime.
I wonder how long it will take before someone (like you or Andre) will totally abuse those new Hydra shaders in FP10, and create something entirely different from it (like you did for that incredible SoundTool).