Loading Profile...
HTML5 Audio
HTML 5 Audio?
A lot of browsers are now starting to support HTML 5, and ultimately for those browsers that support it it is a superior solution to flash.
Is it possible for soundmanager in the future to do browser detection and automatically use HTML5 for compatible browsers and Flash for those that are not. Thanks.
A lot of browsers are now starting to support HTML 5, and ultimately for those browsers that support it it is a superior solution to flash.
Is it possible for soundmanager in the future to do browser detection and automatically use HTML5 for compatible browsers and Flash for those that are not. Thanks.
10
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company has this under consideration.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?I like the idea of supporting HTML 5.
At this point I am considering writing a compatibility script, which could take an HTML 5 page with <audio> elements and effectively make them backwards compatible with SoundManager 2.
This way as support grows for <audio>, SoundManager 2 should eventually become redundant.
The current "playable MP3 links" demo for example could probably be retrofitted to use HTML 5 + audio instead of regular <a> elements, with SoundManager 2 being a compatibility layer for non-HTML5-supporting browsers.
I'm not familiar with how the current HTML 5 experience works at this point, but I may get around to implementing a basic compatibility-style demo in the future.
I’m happy
3 Comments
Add a comment
This is one of the best points
-
Great! Eager to see this! -
Scott, I have been working on a Flash-based transparent upgrade script for HTML5 video and audio tags. And as it happens, I am using SoundManager 2 as the underlying media player. Right now I am covering quite a part of the HTML5 audio and video tag (and the DOM API thereof), but now I am running into smaller problems that I think could be solved more easily directly within SM2.
My source code is available from GitHub: http://github.com/trieloff/html5flash...
Let me know what you think. -
Hi Lars, this looks pretty good; I haven't investigated the HTML 5 API much and plan to continue supporting SM2 for the foreseeable future, but it might be wise to reference your HTML 5 upgrade script from the SM2 site if you feel it's complete enough.
-
Inappropriate?I love this idea - imagine writing a single media player+visualization script and having it magically work on everything from IE6 (flash) up through an iphone (html5)!1 Comment Add a comment
This is one of the best points
-
Having audio that "just plays" as JS + Flash for non-HTML5 and <audio> in modern browsers would be nice for the first phase. At this point I don't think HTML 5 audio gives access to the spectrum/waveform data, though the spec/standard still may be in development - maybe we'll see it added.
-
1 Comment Add a comment
This is one of the best points
-
I think having SM2 as a fallback option is nice, but ultimately the best HTML 5 "backup" solution will not require Javascript. The following link details an approach which doesn't need JS, and though the markup isn't simple, should be most accessible: http://camendesign.com/code/video_for...
-
Inappropriate?The Video for Everyone proposal looks good for the use case where you "just want to to play audio/video". If you need more control, then html5flash would be the better alternative.
1 person thinks
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
I like this point also. HTML 5 is being debated somewhat right now re: formats and support, but hopefully things will sort themselves out. In the meantime I'm happy to see something that while requiring JS and Flash, can offer an option for backwards compatibility.
-
Inappropriate?I absolutely love this idea. My only suggestion would be letting the coders choose the fallback order.
For instance, I want to be able to use waveform and eq data where possible, so I would want to have an order of flash then html5 but for those who don't, you might want to be able to set html5 first in case it would run faster (I believe that the html5 standard is also supposed to support seamless repeats, so that would certainly be nice).
It would also be nice to do it that way in case you know that say, most of your clientele will be using IE.
Plus, the HTML5 standard technically only supports OGG formats I believe at the moment (though browser makers obviously aren't going to be happy with just that as mp3 is a much more popular right now, so I expect they'll generally implement it, but some purist browsers won't)
On top of that allowing specific fallback orders according to file type would be nice as well. However that could make it very messy I think.
EX. (cleanest I came up with)
sm2.fileTypes = {
"mp3":["flash","html5audio"],
"ogg":["html5audio"],
"flv":["flash"],
.....
}
And then should be able to "override" the file type for a given sound object.
The biggest problem (which would also be a nice bonus at the same time) I see with that is that it would require soundmanager to change the way it functions for each file type. Meaning that you could get a mix of flash and html5 on the page.
1 person thinks
this is one of the best points
2 Comments Add a comment
This is one of the best points
-
The Yahoo! Media Player project takes an approach like this, in trying to match file types to the type of plug-ins installed on the client computer. The risks are edge cases, code complexity and of course inconsistency in the features offered (if any) by each plug-in which may limit the API on the JS side.
I imagine MP3 will be supported in HTML 5 by default, though I've been wrong before - and for video, H.264 is a likely candidate in addition to more open/free formats like OGG. -
This would seem like a sensible approach, since I'm also one of those who'd love to use the waveform and eq data (and possibly some sort of streaming control with Flash 10 as discussed elsewhere) whenever possible, but also provide HTML 5 -based support for OGG Vorbis, which Flash still lacks.
How about a separate version (SM3/Pro?), with such extra features included but leaving any possible API limitations to be handled by application developers as they see fit? -
Inappropriate?My main concern is getting soundmanager to work on mobiles without Flash support, so rather than having Flash be a fallback for html5, use html5 for a fallback when there is no Flash.
I also want to do this without having to rewrite my entire application, which is built on the SM syntax. It would be nice if there was one, generic solution, eg SM, that can handle cross platform sounds, rather than having every application write its own syntax converter, or w/e.
Thanks. :D
I’m hopeful
-
Inappropriate?For future projects, a more forward-thinking approach would be to use HTML 5 <audio> as the default, with a fallback to using something like SoundManager 2 for IE 6-8 (and maybe 9? TBD :D) and other non-HTML5-supporting browsers. (Ideally, SM2 should become obsolete as HTML 5 takes over!)
Someone has been working on a script which does HTML 5 by default for both audio and video, using SM2 as a fallback option:
http://gettingsoftware.posterous.com/...
That being said, for now it may make more sense to do SM2 by default and use HTML 5 if available given that HTML 5 browsers are still in the minority. This way, you would only have to write some wrapper methods for your sound calls in your current project.
The downside is that when I wrote SM2 there was no HTML 5 audio API, so I made mine up based on what I think made sense, and what was provided in the Flash audio API etc. While SM2 does have its own style, there is a lot of overlap in the basic play/pause/stop and event handling between SM2 and HTML 5 from what I have seen.
-
Inappropriate?I know that you may be working on it for the next version, and I know that if that's the case then it's going to be a MAJOR upgrade and such (maybe time to call it SM3?)so it's gonna take a LONG time to complete, but any updates? I'm sure lots of us are eager to know if you have made any progress with it at all.
I've been working on a successor of the website I've been hosting and one of the requirements we're hoping to fulfill is mobile device support. If possible I do not wish to have a separate library to run audio on different devices or browsers (if we move to strict html5 then we obviously lose IE, not that we like it anyway). Anyway, if you're working on it, then good luck and I'm definitely excited! Always a fan,
-bum51
I’m excited
4 Comments Add a comment
This is one of the best points
-
No updates on the HTML 5 front, but I have been working on a few minor bug fixes for SM2. HTML 5 is still in flux and I was experimenting with some Flash 10 ideas, so I'm waiting to see where the <audio> stuff goes. As always, thanks for the bug reports and support!
-
In that case I think I'm gonna take some time and look through the SM2 js code, and see if I can't come up with a temporary solution, possibly even one that ends up being a complete solution. I'll let you know if I make any headway!
-
Having some sort of wrapper for Audio() or whatever might be nice, for the pure JS side. I'm not sure about trying to make <audio> work just yet, that's likely to be another can of worms. The smartest thing at this point may be to make an Audio() JS object that mimics the native HTML 5 one, and then uses SM2 behind the scenes for that. It can be an extension of the existing SM2 core, that way. If I get Audio() working, then I can look at the HTML side (which should be an extension of Audio, by that logic, etc.)
-
Basically what I've come up with as the easiest solution right now is a wrapper object that uses an <audio> object as the main engine, but includes SM2 as a sort of plugin engine for an cases that the <audio> doesn't work (instead of an extension of SM2), or is not supported with requested features (wave/eq data, or certain audio codecs). I would want to make it look and feel like SM2 as much as possible so that it can be relatively easily dropped in to any code that already uses SM2.
The advantage to this approach would be that each "engine" is separate from the wrapper code so if for instance the <audio> spec changes, the engine can be stripped out and restarted, without having to scrap any other part of the project. And to go one further, if someone ever wanted to make a silverlight plugin or something, that would be possible as well (not that I can imagine why anyone would though)...
For now I'm going to work on the <audio> engine, and then I'll get to the wrapper.
(btw, kinda off topic, but since we've got stereo wave forms, can we get the same for the eq? my visualizations look kinda funny when the waves are stereo and not the bars :D ) -
Inappropriate?Following up bum51's comment with a full post..
Ha, I should have the EQ on both channels if it isn't, yep - I may have forgotten that when adding the second waveform channel recently. I'll check and see where I left off.
Re: Audio(), I like the idea of some sort of generic Sound() object, say, which uses the native Audio() if available, and falls back to SM2 if not.
Thinking about it more, it seems to make sense not to try to "fake" the DOM-native Audio() object by default, in the event that other libraries start looking for it. That said, someone can simply say if (typeof Audio == 'undefined') { Audio = Sound } or some such if they wish.
Mapping the native Audio() methods to SM2 is going to be the interesting/fun (and possibly frustrating? :D) part, I think. ;)
-
Inappropriate?The mapping is definitely fun, but you do not have to do it again, you can simply fork my previous work off github: http://github.com/trieloff/html5flash
The Soundmanager API is much richer then the HTML5 API, so there might be the need to force the use of Soundmanager (which I have not implemented yet)3 Comments Add a comment
This is one of the best points
-
Ah yes, your project looks to cover a lot of the HTML 5 audio stuff I've seen out there; nicely done. The demos don't seem to work for me in Firefox (maybe due to the video format used?), but I see the underlying logic looks good - and it does work in Opera.
-
I agree with Scott, it looks quite good. However my idea was to port HTML5 to SoundManager instead of the other way around. It just makes it backward compatible with pre-existing applications. Not to mention the flash features being more readily available. I do think that any NEW application would definitely benefit better from your project, as it makes it a bit more future-proof.
-
For future stuff, I think it'd be smart to have people using an API mimicking the HTML 5 audio API, so they can eventually drop the SM2 bit once browsers all do the same thing and so on - however, I do like the SM2 API because I built it. ;)
Giving people the option of HTML5 <-> SM2 could be good for choice, so I like the idea of having both of these options available. If you have a current SM2-based project you want to "upgrade" to use HTML 5 audio without having to rewrite your sound code, for example, bum51's code could do a nice job at this, for example. This is good.
On the other hand, if I'm doing some brand-new project and am all into HTML 5 stuff, I'd want to use an HTML 5-like JS API but have SM2 fill in the backwards-compatibility angle for IE 6,7,8 (maybe 9? :/) and so on.
My goal is to try to have a wrapper API for JS-based sound that mimics the HTML 5 stuff closely, so ideally people are learning how to use a "go-between" API that will be very similar to what the browser's built-in support is supposed to be. This despite that I built SM2, but HTML 5 ideally is the future and will get shinier as they add features. I'm pretty sure the audio nerds will demand access to waveform data etc. in the future, for example. ;)
I think separate code bases for these would be a good idea (not in soundmanager.js, but included with the project), they could be add-ons or extensions run alongside SoundManager() and so on so people can mix and match.
I think my first take at an HTML 5-like API wrapper with SM2 fallback will work just at the JS level, eg. new SoundObject() vs. having audio elements in the HTML and trying to handle that case just yet. One step at a time, etc. ;)
Glad to see people stoked about audio thinking about these things. It may be a while before audio is "free" in JS, but the first big steps towards it are being taken right now and it's a pretty interesting time to be building this sort of stuff.
EMPLOYEE
