Thanks for the link Tom.
Yes, that's the method I was following, and since it didn't work I wrote to
this list to ask for ideas :)
The page mentions a stable 46 ms clock, but as I have tested it, it's not
stable at all. I guess it's what you mention about SOUND_COMPLETE becoming less
reliable.
I tested exporting RAW instead of MP3 and I can not see a clearly more precise
timing. Maybe slightly better, but I don't get a fixed 46 ms timer.
I would say 4 out of 5 times it's 45/46/47 ms, and 1 out of 5 it's something
totally different, like 23 ms or 70 ms or even 100 ms.
And if they say it will get worse in FP10... that's bad news. They will make it
possible to generate real time sound, but the timers will get less precise? or
only the SOUND_COMPLETE event?
In the worst case I can 'synthesise' (render) the track in real time, in that
case I will get perfect timing I guess... (and more CPU usage).
My application is anyways working, I'm just looking for tighter timing, and if
it's not possible, then it's not.
Following this discussion I wondered if you are aware of this:
http://www.b-nm.at/flash-sound-synchronisation/
(also as normal webpage, but then the ascii examples wont work:
http://www.actionscript.org/resources/articles/159/1/Advanced-Flash-MX-Sound-Ti
ming/Page1.html
)
Could explain the seemingly irregular mp3 play times.
The bad news is: this technique relies on the precision of the
Sound_Complete Event wich has become more and more unreliable with
every new PlayerRevision since FP8 (and it will even be worse in
FP10...)
If this is old stuff - sorry for the noise.
I will definitely give playback of the WAV/AIFF instead of mp3 a try,
thanks for that!
--
Aloha,
tom
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
