The basic issue here is that SWF content was able to preload assets such as audio files well ahead of the slide on which they were used. This allowed for a near seamless multimedia delivery and was a big advantage over other systems available at the time it first came out.
HTML5 content is designed to be more mobile-friendly, and since mobile devices and browsers do not have the same ability to cache huge amounts of files, the browsers generally only download the assets required for each slide or page when arriving at that point. This means that how quickly the audio begins to play is very dependent on the bandwidth available to the end user.
When playing back HTML5 content from your own hard drive, bandwidth is not an issue. However, when your content is being served up over the web, you will get at least some delay between the time the slide first loads and the audio begins playing.
What is needed here is a better way to preload all assets required one or two slides ahead of time. But at this point that's not how things are working.
Your workaround will be to reduce as much as possible the duration of each slide so that the audio files are not large. Additionally, since you mention that your current design has audio files attached to objects moving into and out of the timeline, you may find that you get better results by just having one audio file for each slide because that will mean only one request to the web server instead of several to get audio for that slide.
10
Replies
AdChoices