caching - Will HTML5 support the access of offline cached audio?

Question

We want to make an audio based web based app that will have many sound snippets. We want to cache these files so that performance is good and not dependent on network speed. Can HTML5 cache audio for offline mode?

Answer 1

It certainly seems to me that this should work, and I can't find any documentation that says it shouldn't work (either from the W3C or from vendors like Apple), but putting audio files as resources in cache manifest just doesn't seem to work with Safari on the iPad & iPhone at least.

Sounds play fine when the app is in online (although it seems to load them anew each time and not cache them) and it doesn't complain about the resources not being there when in offline mode (which is does immediately if you forget to include a JavaScript, CSS, HTML or image resource).

Instead of complaining (or loading); if the element has a control that control is replaced with a box that says "Cannot play audio file.". Alternatively, if it's an element without a control - i.e. accessed via JavaScript all to .play() - then it simply just doesn't play (it doesn't cause any errors, there is just no sound, the JavaScript otherwise continues to execute normally).

I have tested this with pretty small (<20k) files and the result is the same, so it doesn't seem to be size related, just a blanket refusal to copy. I'm not sure if you can encode sound as a resource in a page (e.g. encoded in base64) the way you can with images, but I'm going to investigate that option - I suspect that would be possible. I tried encoding audio data as data URI strings and even tried generating audio on the fly - both work fine in Safari on the desktop but do not work on the iPhone / iPad OS (at least on version 3.x - I have not tried on iOS 4, but it won't be out for a week, and is not expected for the iPad for a few months, even if they do fix it).

I would guess the refusal to cache sound files in iOS is an implementation bug or intended limited functionality. It's certainly annoying and a show stopper for a lot of use cases.

I am not sure what happens with other HTML5 clients, I'd be interested to know (in particular on Andriod). Google's support for audio hasn't been stellar either, so it may suffer from the same limitations.