Mobile Safari
Can't pre-load sound files, only plays one sound at a
time, severe lag, timing issues, clicks & pops,
completely ignores every other call to play a sound,
doesn't support Ogg/Vorbis. Utterly useless for anything.
Oh, and did I mention it doesn't support Ogg/Vorbis?*
More specifically Apple has crippled the Audio API by disabling the autoplay option, and disabling the JavaScript .play() function. This makes it completely impossible to build web games, or web apps that have any sort of audio feedback in Safari on any iOS device.
Presumably they've done this to prevent web games from becoming popular and eventually dethrone the App store.
Even if that's true, I, for one, despise the idea of any kind of audio autoplay for the web, be that flash or html5. If that breaks web games -- tough luck.
I might be OK with some kind of whitelist, though -- same way it works e.g. for large off-line storage. But I like my games and audio editing software native anyway, thankyouverymuch.
It's worse than that, it breaks the standard. Audio API can no longer be used reliably if a major portion of the audience can't utilize it. Remember when days when one major heavyweight would refuse to follow standardized web protocols? You know, like how SVG was standardized in 2001 and 10 years later can still not be used reliably. Stuff like that needs to stop.
Well, if the standard allows autoplay without user consent then it's broken. Just because a standard is doesn't mean everyone should follow it. It should be followed when it's a good standard, and in this case it's arguable.
I think the official reason (I read somewhere in documentation) is because they don't want web sites to suck up mobile bandwidth by automatically streaming stuff. You can have videos autoplay, yes, but videos you can overlay with controls, whereas audio can be integrated into an interface in such a way that the user has no means to stop playback.
It seems obvious that Apple's interests don't coincide with fully functional cross platform mobile apps. Getting people to build with objective C and native code helps lock in and ensures that any sales go through their payment platform. If you don't think Apple has been moving in this way (anti-cross platform dev tools, requiring sales to use the iTunes payments) you simply haven't been paying honest attention.
I understand that you're unhappy with Apple, but keep in mind that their original iPhone was HTML apps ONLY.
Further, they continue run WebKit as an OSS project, and have worked to be accommodating to other mobile providers.
The reason they dislike flash isn't some sort of inherent hatred, it's that it's outside their control. They can implement a HTML spec just as well as anyone else, and with Webkit, they can lead the way.
They want this as long as they are not the dominant platform. If MS and Apple swapped places tonight and Apple suddenly had 90%+ marketshare, it's likely that their strategies would flip just as fast, because it's the most profitable thing to do.
Apple's interests are in ensuring that their platforms can run as much user-desired content as possible; they can do this by promoting cross-platform compatibility and interpreted code like JS and HTML.
Microsoft has no need for this, since everything runs on Microsoft by default, because if it didn't, you'd miss out on 90%+ of your potential market. Instead, Microsoft's interests are opposite; they want to do everything they can to ensure that Windows is still required for any and all meaningful usage. This is the major point of IE; do enough to mostly work, but break compatibility where you can get away with it so that developers can't forget about Windows and IE.
They also hope, though the environment isn't appropriate for this to work anymore, that IE will be your sole development platform and that considering the time it takes to make stuff work in IE, you will just leave things broken in all other browsers, further solidifying the MS lock-in.
Lock-in is the holy grail for the software vendor. Apple is putting this in place as best as they can in the markets they control, and they are trying to ensure that MS doesn't lock them out of the desktop game, because they're still vulnerable believe it or not. MS is trying to ensure that Windows' death grip remains in place FOR. EVER., just as Apple wants iPhone/iPod to do the same.
They are a software vendor, and by vendor I mean producer. They don't not become a software vendor because they bundle the software and hardware together. They may make money on their hardware which is great for them, but it doesn't change the fact that OS X, iTunes, and the others, like all other software platforms, want lock-in; Apple merely wants to lock you in to the hardware too, so they use the software platforms to do that.
> It seems obvious that Apple's interests don't coincide with fully functional cross platform mobile apps.
No, it is not that obvious at all. May I remind you that Apple introduced the iOS SDK, spearheads what is usually recognized as the finest rendering engine out there and built what was the first mobile device actually able to surf the web?
And that they have shown no will or wish to backtrack on any of these, doubling down instead?
There is something much, much simpler to these issues:
1. Jobs's Apple will never again live and die at the whim of a third party. They suffered greatly during the Classic-OSX transition because Apple had lost control of the development platform itself (which was basically owned by Metrowerk and its CodeWarrior)
2. Jobs's Apple takes decisions it thinks benefit its customers and its customers are always its users.
Now they may be wrong on that, and they may be misguided, but time and time again you can (pretty easily) explain the decisions of Jobs's Apple either as trying to avoid losing their platform to a third party or trying to make their user's experience life better.
With web browser they fully control the platform. Hell, they control what can be argued the best web platform available (Google's Chrome is giving them a run for their money, in no small part by building upon their work). They don't fear people using their web browser, they wouldn't have built Canvas if they did (why not leave it out as SVG? Slow, hard to use and not a threat at all), they wouldn't be implementing WebGL, they wouldn't spearheads CSS animations and transitions and all the stuff that can make web applications snazzier and cleaner, they wouldn't have the engine with the best HTML5 support by far.
Web stuff is not a threat, because they can have the best, shiniest and most advanced web stuff and they control all of it (number of full rendering engines allowed on iOS devices? one. Nobody else is allowed to ship a JS interpreter, therefore no full-blown web browser can avoid using the Webkit that ships with it and is fully built by Apple).
Apple doesn't fundamentally mind or care for cross-platform mobile apps, what they fear is a third party's cross platform toolkit taking preeminence over their own tool and deciding of their platform's future. That is why they banned flash (also, because flash is a piece of shit).
> Getting people to build with objective C and native code helps lock in
That only works because you assert Apple wants to lock users in.
> and ensures that any sales go through their payment platform.
Cross-platform tools would have the exact same restriction or face bans. iTunes payment mandate is trivially explained through integration and user-experience (did you know that Apple's subscriptions services makes user information availability to magazines opt-in by the user, whereas just about every other service makes it opt-out if opt-able at all? That's because to Apple the device owner is the customer, to just about every other publisher the magazine is the customer).
> If you don't think Apple has been moving in this way (anti-cross platform dev tools, requiring sales to use the iTunes payments) you simply haven't been paying honest attention.
Either that, or I have not been wearing hate-shaped glasses.
But really, I wonder why I bother with all that typing. I should know by now that HN's view of Apple is the same as /r/tech's: a bashing wankfest.
That only works because you assert Apple wants to lock users in.
You must not have much experience in computing. Pretty much every [1] platform provider seeks lock-in. Google seeks it just as much as everyone else, their primary platform just happens to be their web services and not a specific OS. Microsoft and Symbian and RIM do as well, of course, and presumably HP/Palm would as well if they had any customers.
"they wouldn't spearheads CSS animations and transitions and all the stuff that can make web applications snazzier and cleaner, they wouldn't have the engine with the best HTML5 support by far."
Firefox 4 has better HTML5 support than iOS, for one.
Than iOS yes, iOS's saf' isn't resynced with the webkit tree during every minor release (sadly): Safari on 4.2.1 is forked off of Webkit 533.17.9, the most recent release of Webkit (which can probably be find in or around "Safari 6" aka the webkit nightlies) is 534.23 from 5 days ago (I can't find a 533.17.9 tag, but 533.7.8 was tagged in July)
I think you're confusing "most marketing checkboxes checked" and "best support" in terms of Webkit and HTML5 (and also in terms of Webkit and "finest rendering engine").
For example, Webkit is the rendering engine with the worst CSS 2.1 support of the big 4, last I checked, based on the results of the CSS 2.1 test suite. Yes, it claims to implement all of it, but the quality of the implementation is not as good as the others.
For another example, Webkit is the only rendering engine I know that claims to implement CSS3 Selectors but purposefully does so incorrectly because they think doing it right would be "too slow".
This is one thing IE8/9 have actually been doing right. When they commit to implementing a feature they've been implementing it well. The feature set is smaller than webkit, but there are fewer gotchas in the features they do support...
No. They've done this to prevent web sites from outputting sound when they're loading (or just as they're done loading).
The Audio API's .play() method is now always disabled. It was working on the iPad iOS 4.1 only through a hack, but Apple closed that hole in 4.2. I have no hatred of Apple, I own plenty of Apple products, but absurd strategic crippling of standards does not help my impression of them. It just wreaks of Microsoft-style embrace, extend, extinguish.
I've made my point clear. If you think web browsers should not have the ability to play any audio that's a different topic than whether an OEM gets to pick and choose which parts of a standard to implement and which devices can support it. This is exactly what made the IE web development days so particularly maddening.
"I've heard some arguments that it is crippled on purpose, because you don't want a website to start blaring music at you as soon as you open it. Fine, I understand that argument. But why not ask the user for permission to play audio and then do it right? It's already been done with Geo Location and Storage."
A lot of discussion about the demise of Flash is focused on how CSS and JavaScript can now create equally pretty-looking websites, which is fair enough. But take it from a long-time audio developer: HTML5 audio is essentially useless for creating web applications involving almost any kind of audio. Even Firefox, which has the best HTML5 support so far, offers absolutely nothing like what is possible using the combination of a Flash client and a dedicated streaming server.
Flash might have a lot of bad points (which I'd be the first to call out) but RTMP audio (which also handles both video and arbitrary data) really isn't its worst feature, and for this reason alone its going to be a significant part of the internet for many years to come.
I totally agree that for video/audio players, Flash is a good technology (if hardware support is enabled and Flash is properly sandboxed). Flash is platform independant, needs no pre-installed codecs and can be easily blocked. None of this is true for any native audio/video tag.
Not quite true. If you look at audio in HTML only through the lens of the <audio> tag, you're right. Some of the work-in-progress JS audio API stuff that doesn't depend on the audio tag rocks, even right now, in the dev builds. The future looks brighter than ever without Flash imo.
I don't give a shit anymore about this stupid piece of crap that Microsoft calls a Browser and throws out a release for every 3 years, just in time to not let it fade out completely but annoy web developers for more years to come.
In summary: "there's some profanity ahead because HTML5 Audio is still that fucked up".
My experience is entirely aligned. I was trying to use <audio> earlier this week for an incredibly simple task (occasionally play a 0.5s notification sound).
The only thing that worked reliably was Chrome (9) with a data: URI. FF3.6 (or Chrome with a normal URI) would only play the sound once, and Safari wouldn't play it at all. (These are all the Mac versions, and I didn't test Opera).
We've been using SoundManager 2 on quizlet.com for playing audio clips. We're not just playing long music clips in the background, so it's essential to have all the precise APIs for preloading, playing, and firing callbacks when sound is done playing. It handles all the browser deficiencies very elegantly, either with HTML5 or flash. Also, it's just 10k of js (gzipped) so it's pretty lightweight.
I'm using sound manager on http://hackernewsradio.com as well. Right now I am just forcing flash. I had too many problems with html5 audio.
I really wanted speex encoded audio but that is not an option. If I remember correctly Opera handled streaming speex/ogg like a champ. Firefox may have worked... I can't remember. Everything else sucked.
Contrary to his claims, his test case seems to work mostly fine in Chrome 10.0.648.127 (beta) for me. I haven't tried the dev channel version though. Firefox doesn't appear to be working well at all, in either 3.6.16pre or 4.0b13 (but those are both unstable versions, so I'll withhold judgment). All of those were tested on Ubuntu.
Regardless, he's definitely made his point well (and my setup showing different but similarly bad results from his only proves his point): support for the <audio> tag is not really as solved as browser manufacturers are claiming, and is not currently a suitable competitor to Flash.
Has anyone managed to make the audio tag work reliably with streaming? icecast server with ogg vorbis stream comes to mind. Tried konqueror (works), firefox 3.6 (doesn't work properly), chrome 9.x (doesn't work properly).
I know you know this, but for everyone else, Firefox doesn't play chained ogg files. Icecast uses this feature. If the icecast stream doesn't use chaining then it plays.
I hope for the day when the Webkit Web Audio API[1] or something like it is widely available so we can build rich audio apps like Audiotool[2] without relying on Flash.
Ogg/Vorbis works just fine in Safari on my Macs. That's because Safari as far as I can tell is neutral when it comes to audio--it plays whatever you have Quicktime support for and I have installed Ogg/Vorbis.
How do you have <audio> working in the Android browser? Last I checked (2.2) the tag was supported but there was no format support (kind of like an airplane without wings). This was filed as a defect in June 2010 and a fix was promised, but not delivered for Android 2.2:
Could applications such as PhoneGap be used to fill the void regarding audio on mobile devices? It's a shame that as the profits of app stores continue to rise, there is less motivation to promote and expand open standards.
I bought the ImpactJS engine, and I'm currently working on Android to run sounds through SoundPool while everything else happens in an embedded browser. Not much luck yet, but I think I can get there.
I coded a Chrome Web App and can sympathize. I eventually had to entirely recode my app because the first go was crashing the tab randomly when audio was playing. I can't imagine trying to do short sounds like in games.
1) It's hard to detect when to fallback. You'd have to set up a list of user-agents you've tested and code around their individual issues. This is not ideal.
2) It doesn't solve the iOS problem (which, as this post points out, has even more issues than desktop browsers)
Presumably they've done this to prevent web games from becoming popular and eventually dethrone the App store.