I'm using SoundJS 0.5.2 to play audio in a music player that I'm designing for a client.
According to the documentation, I have to register or preload an audio file before I can use it, by using the registerSound method of the Sound Class and the audio cannot be played before it is fully loaded.
But how I do I go about buffering the audio while it is being played? Like wait till 10% of the audio is buffered, then play the song? Can this be accomplished using PreloadJS ?
After Googling about it, I found this thread. It says that the WebAudioPlugin does not support buffering because of the underlying technology, but the HTMLAudioPlugin can play the audio before it is fully loaded.
But it does not mention how to do that. When using HTMLAudioPlugin, do I still have to register the sound using registerSound ?
Also, when using FlashPlugin as a fallback, will the buffering still be supported by FlashPlugin?
HTMLAudioPlugin fires the ready event when it receives the canplaythrough event from the audio tag, so it supports buffering by default (no setup required). You have to register sounds for them to start loading, either with PreloadJS or internal SoundJS methods. Buffering will work the same regardless.
Buffering is not supported by the FlashPlugin as far as I know.
Hope that helps.
Related
How does one go about streaming video in HTML5 ? I can go with using a single browser of the latest version if I have to.I need to be able to start playing from any location of the movie even if the entire video has not been loaded by the browser.
WebRTC ?
I've already seen this question and no one has answered.
Does not allow the viewer to skip to the middle of a video in any
browser. They must watch the video straight through start to finish,
which is not ideal.
This is the main point for streaming.
Currently if you want to use pure HTML5 and work cross-browser you are limited to progressive streaming with the <video> element.
While that still does allow the user to skip ahead via the scrubber or programatically by setting the .currentTime there will still be some buffering while the browser re-loads enough content to be comfortable playing smoothly.
Solutions like Smooth Streaming, HLS do not work across browsers today so you would require a Flash or Silverlight plugin, though with MPEG-DASH being recognized by the W3C there is some hope for the future as samples like this demonstrate http://dash-mse-test.appspot.com/release-notes.html
For today however if you want to stick with an HTML5 solution and you have source in a format the works with the browser then you should be fine
Chrome has implemented the Media Source API in the mean time. Hoping the rest will follow.
http://www.w3.org/TR/media-source/
Abstract
This specification extends HTMLMediaElement to allow JavaScript to generate media streams for playback. Allowing JavaScript to generate streams facilitates a variety of use cases like adaptive streaming and time shifting live streams.
When you play audio using the audio element in Chrome you get annoying clicks and cracks. At least under my 64bit Linux installation, even after I formatted and installed a new Fedora version. (Firefox and Opera are fine, even IE9 in a VirtualBox Windows 7.)
But demos using the Web Audio API instead of the audio element have perfect sound. So I was wondering if I could use the Web Audio API like the audio element? But there are some things you seem not to be able to do with this API. Or am I missing something? The things I couldn't find where:
starting to play a file before it is completely loaded
getting buffer progress updates (depends on the previous point)
getting play progress updates
seeking
Is there a way to do this with the Web Audio API?
This is where I would use it: http://tinyurl.com/magnatune-player
I think you should still use <audio> for streaming at the very least. You can treat it as a MediaElementAudioSourceNode in web audio if you'd like:
var mediaSourceNode = context.createMediaElementSource(audioElement);
AFAIK, there is no way to stream web audio directly. In fact, the web audio api suggests that you don't:
4.9. The AudioBuffer Interface
This interface represents a memory-resident audio asset (for one-shot sounds and other short audio clips). Its format is non-interleaved IEEE 32-bit linear PCM with a nominal range of -1 -> +1. It can contain one or more channels. Typically, it would be expected that the length of the PCM data would be fairly short (usually somewhat less than a minute). For longer sounds, such as music soundtracks, streaming should be used with the audio element and MediaElementAudioSourceNode.
Unless you used a MediaElementAudioSourceNode (which I would assume suffer from the same issues you're having since it's just using an <audio> tag) AFAIK the answers to your questions are:
starting to play a file before it is completely loaded: No.
getting buffer progress updates (depends on the previous point): Possibly (You could check for progress events on the XHR)
getting play progress updates: No.
seeking: No.
In the meantime Chrome fixed the audio playback issues. So I don't need any workarounds anymore.
Check out this space shooter demo.
The HTML5 audio is perfect on Chrome 18 and Firefox 10. There is no lag in playing sounds and each sample plays perfectly. The last time I tried to play sounds using HTML5 audio and JavaScript I couldn't get a sound to play more than once.
What sorcery is Scirra doing to make this so perfect?
I'm the developer of Construct 2, so I hope I'm sufficiently qualified to answer your question :)
HTML5 audio is indeed a mess, so I've gone to considerable lengths to try and make it bulletproof in Construct 2. Here's an outline of what I've done:
Use the Web Audio API
HTML5 audio appears designed for streaming music, so a HTML5 Audio object is kind of a heavyweight object. Playing 10 sounds a second with it like Space Blaster does can easily seize up the browser. On the other hand, the Web Audio API is a high-performance audio engine with routing, effects, and lightweight sound playback. It's perfect for games. Audio buffers and audio playback are separated, so you can have one data buffer and efficiently play it many times simultaneously, whereas some browsers are so buggy if you play a HTML5 sound a few times it re-downloads it each time! Since it was actually designed for games and such, you can happily play back tonnes of sound for ages and it will still hum along nicely. It can also use HTML5 audio as a sound source, although I only use HTML5 audio for things the user has designated as music tracks (since that's where you'd prefer to have streaming - typically everything else in the Web Audio API is fully downloaded before playing).
The Web Audio API is supported in Chrome, has also made it in to iOS 6+ (although it's muted until you try to play some audio in a touch event), Firefox are working on support, and it should be coming soon to Chrome for Android. So on these platforms audio will be significantly more reliable.
More info on HTML5Rocks and the proposed spec - you'll have to use the spec as the documentation for now, there's not much else out there.
Other browsers: implement an audio recycling system
The Web Audio API isn't yet supported everywhere, notably IE, which means you still need to crowbar HTML5 audio in to something that might work for games for backwards compatibility. The way to do this is to recycle audio objects.
The player's laser in Space Blaster fires 10 times a second - and that's not including any other sound effects! As I mentioned earlier, Audio is kind of a heavyweight object, so if you're doing new Audio() 10+ times a second, lo and behold, the browser eventually dies and audio starts glitching up. However, you can drastically reduce the number of Audio objects created by recycling them.
Basically, for each sound effect, keep a cache of every Audio object you've created with that sound as a source. Then, when playing a new sound, search the cache for any sound effects which have finished playing (the ended property will be true). If you find one, rewind it back to the beginning (currentTime = 0) and play() again. Otherwise, create a new Audio() object in the cache.
Since the player's laser sound effect is short, instead of creating 600 Audio objects a minute, there will just be 3 or 4 that it keeps cycling round. Some browsers unfortunately will still download it 4 times (Safari did this last I checked!) or have high latency the first time each sound buffer is played, but eventually the browser catches up since the same buffers are always being reused. So basically sound might be a bit weird for a few moments, then it clears up. We also use the HTML5 app cache so next time you play everything loads from disk, so subsequent plays should perform well immediately.
That's basically it. It's still a little dodgy on the first play with HTML5 audio, but every time after that should be fairly solid providing the browser has a sane audio implementation. There are a number of ways to try to clone Audio objects, but I've found that rewinding existing Audios works best.
There's no SoundManager or any Flash/plugin-based fallbacks at all since we make a point of being pure HTML5.
We also support audio APIs provided by PhoneGap and appMobi for mobile, since HTML5 audio on mobile isn't even worth trying. That makes a total of four audio APIs our audio engine wraps, and yes, it does look like a frankenstein mess, but it works.
That's it. I suppose our competitors will read this, but who cares when there's SO rep to be had???!!!1111
working on a project with a custom flv player.
Everything works as it should
However, the flv's don't seem to be caching, if I play the video once, close the player, and replay again, the video has to cache -load entirely again before the video starts playing.
Can anyone suggest troubleshooting steps since, as far as i know, this should not be the way it works...
As spender mentioned, if you are not loading the flv via http, then caching does not apply.
You might want to check out Greensock's LoaderMax, as it provides highly configurable and easy-to-use video playback functionality which has ironed out many of the kinks in Adobe's own video player classes:
http://www.greensock.com/loadermax
Can I click on some time and eventhough the video is not downlaoded till that time and the video starts playing from the time I clicked?
If yes, what would be a better option for viewing streamed video- HTML5 or flash player like JW player? WHich one will have less lag?
HTML5 browsers generally don't support this, however I believe the video tag in Safari will work with the Apple HTTP Streaming format for this functionality. For something that works across all browsers, Flash Player can do it using either RTMP streaming or HTTP Streaming (either with our without OSMF to support this). Probably the easiest place to start is with OSMF, which supports both RTMP and HTTP streaming of video.
I have tested this with Firefox and Firebug and while you can "seek" to a point in the video without having to watch video preceding the point you wish to seek, this still causes the entire video file to download.
Indeed, each time you seek in Firefox 4, the entire video downloads.
This may change and improve as HTML 5 video implementations become more mature and may differ based on the actual browser being used.
More information on the test here:
http://www.stevefenton.co.uk/Content/Blog/Date/201106/Blog/HTML-5-Video-In-Real-Life/