Audio plays back with about a second and a half delay on the Microsoft Surface / Windows 8 Phone

[volkipp]

All audio plays back as it should, however it plays with about a second and a half delay every time.

In flambe if you play a sound, then immediately pause it like so:
var playback:Playback = mySound.play(); playback.paused = true; // Do something else for awhile... playback.paused = false;

Then the sound plays without a delay when you un-pause it.

My best guess is that when element is getting cloned, IE doesn't have the sound cached in a way that allows immediate playback.

Relates to #48

[aduros]

Urgh, yeah, unspecified cache behavior is one of the reasons HTML5 audio sucks for games. Is it actually getting re-downloaded after every play? Have you tried serving up sound files with a far future HTTP Expires header?

[volkipp]

From what I can tell, it does look like it's getting re-downloaded from the server every time. I haven't looked into the HTTP Expires header. Is there an easy way to do that with the SimpleHTTPServer python has?

[aduros]

I don't know of any way to configure headers in SimpleHTTPServer, I guess it wouldn't be too Simple then ;)

Does this page cause sounds to be re-downloaded: https://aduros.com/flambe/demos/horses/?flambe=html ? That web server is set up to serve assets with an Expires header.

I'm planning to add instructions on how to do this in nginx and apache to the wiki, as it's useful even outside of sound playing. You probably noticed the ?v=(MD5 hash) parameter appended to all asset requests, that can be used to aggressively perma-cache assets.

[volkipp]

Ha, true. I tried out that link, and unfortunately it's having the same trouble on the surface tablet. I've tried poking around to see if I could find some kind of clever hack to make it play back correctly, but no luck so far. :(

[aduros]

Maybe the way to go is to have HtmlSound pool a bunch of <audio> elements instead of creating one for each playback.

[volkipp]

Yeah, I definitely think that would solve the problem for most scenarios. Three sounds being spooled up initially would probably be plenty. You want me to take a stab at this, or would you prefer to do it?

[volkipp]

Hm, you know I've been so focused on mobile devices I hadn't tried IE10 in Windows 8 for the Desktop. It appears that IE10 desktop has the same issues for me. Trying the horses demo you posted on desktop, there is the long delay on the first playback, but subsequent playbacks seem to be much better. Using the simple python server, the sound delay happens every time on the desktop, just like the Surface.

[aduros]

Feel free to take on the sound pooling if you can. I'm not as well equipped to test things on Windows 8.

Ideally the pool can grow if you request too many playbacks. HtmlSound should probably avoid adding audio elements to the DOM, to prevent leaks when it's garbage collected.

[aduros]

Also, the fact that the horses demo has a long pause on the first play seems to suggest HtmlAssetPackLoader isn't preloading sounds correctly for some reason.

[volkipp]

I'm not sure what changed with audio loading / support in the nightly builds, but recompiling some past projects are giving me latency-free playback on the Surface RT!

[aduros]

Great! That's surprising, I don't think anything changed on Flambe's end with sound loading/playing.

[volkipp]

I couldn't see anything there either that would have affected sound playback. At first I thought it was a MS software update, but setting my Flambe version back down to 2.2b re-introduced the delay.... Anyway, I'm glad it's working now!

[aduros]

Asset loading internals have changed substantially since 2.2b, but sound shouldn't be affected... but good to hear anyways :)