bfirsh/dynamicaudio.js

Race Conditions When using dynamicaudio.js (in chrome)

diclophis opened this issue · 0 comments

Hello,

I have identified 2 problems with the dynamicaudio.js that stem from a common problem, which is that the SWF file maybe "loaded" according to SWFObject2, however, it may not have initialized its ExternalInterface just yet... see: http://stackoverflow.com/questions/1436722/problem-accessing-externalinterface-exposed-method-in-google-chrome/5294147#5294147

It seems like dynamicaudio.swf should be built in such a way that it can be passed a function callback that it will trigger after it has exported its ExternalInterface callbacks.

The second smaller error is that flashElement is re-used, and during the execution of dynamicaudio.js could mean either the

for the wrapper for swfobject, or the of the dynamicaudio.swf... I have corrected this in my local build by using a different variable name for the flash element reference, which seemed to help with the race condition, but there is still the small chance that the SWF is "loaded" and triggers the embedSWF callback before its external interface is loaded.

Another thought I had is that it would be awesome if dynamicaudio.js had interfaces for controlling the "buffer" sizes, either with exposed parameters, or some sort of option flag (I am looking for the lowest latency possible, at it appears that things can get buffereed in both the JS and the SWF)... Also it would be cool if there was some sort of "isReadyForAudio" function that I could use in my loop to detect when everything is ready to go, and its safe to feed audio into it...

Other than that, this framework really kicks ass, I am looking forward to seeing even more features from it in the future!