I've noticed that this is a common problem. I know there are similar question like mine but i haven't found an answer yet.
My problem is that i want to loop a video but every time it loops it stutters, freezes about half a second at the beginning of each loop. The video is short, about 6 seconds.
I wonder if this can be done with JavaScript.
I had the same problem. .mp4 was pausing on frame 1 for a few frames then the loop continued. I removed the audio track of the .mp4 during encoding. It worked seamlessly after that. Even though I had 'muted' set, it did not play smoothly until the audio track was removed altogether.
Related
From my tests, and from searching to find out more about the problem, my best guess is that css animations may be using a different physical clock from the one used to stream audio. If so perhaps the answer to this is that it can't be done, but am asking in case I am missing anything.
It is for my online metronome here.
It is able to plays notes reasonably accurately in response to an event listener for the css animationiteration event. The eventlistener is set up using e.g.
x.addEventListener("animationstart",playSoundBall2);
See here.
However if I try to synchronize the bounce with the sample precise timing of the AudioContext method that's when I run into problems.
What I do is to use the first css callback just to record the audio context time for the css elapsed time of 0. Then I play the notes using the likes of:
oscillator.start(desired_start_time);
You can try it out with the option on the page: "Schedule notes in advance for sample-precise timing of the audio" on the page here.
You can check how much it drifts by switching on "Add debug info to extra info" on the same page.
On my development machine it works fine with Firefox. But on Edge and Chrome it drifts away from the bounce. And not in a steady way. Can be fine for several minutes and then the bounce starts to slow down relative to the audio stream.
It is not a problem with browser activity - if I move the browser around and try to interrupt the animation the worst that happens is that it may drop notes and if the browser isn't active it is liable to drop notes. But the ones it plays are exactly in time.
My best guess so far, is that it might be that the browser is using the system time, while the audiocontext play method is scheduling it at a precise point in a continuous audio stream. Those may well be using different hardware clocks, from online searches for the problem.
Firefox may for some reason be using the same hardware clock, maybe just on my development machine.
If this is correct, it rather looks as if there is no way to guarantee to precisely synchronize html audio played using AudioContext with css animations.
If that is so I would also think you probably can't guarantee to synchronize it with any javascript animations as it would depend on which clocks the browser uses for the animations, and how that relates to whatever clock is used for streaming audio.
But can this really be the case? What do animators do who need to synchronize sound with animations for long periods of time? Or do they only ever synchronize them for a few minutes at a time?
I wouldn't have noticed if it weren't that the metronome naturally is used for long periods at a time. It can get so bad that the click is several seconds out from the bounce after just two or three minutes.
At other times - well while writing this I've had the metronome going for ten minutes in my Windows 10 app and it has drifted, but only by 20-30 ms relative to the bounce. So it is very irregular, so you can't hope to solve this by adding in some fixed speed up or slow down to get them in time with each other.
I am writing this just in case there is a way to do this in javascript, anything I'm missing. I'm also interested to know if it makes any difference if I use other methods of animation. I can't see how one could use the audio context clock directly for animation as you can only schedule notes in the audio stream, can't schedule a callback at a particular exact time in the future according to the audio stream.
I'm currently helping a friend develop a web application in which I need ~6 audio tracks (all using the same time signature) to continuously loop and stay in sync. To give context, it is a typeface-music pairing application where as soon as a typeface is chosen, the associated audio loop starts playing and as the user keeps picking typefaces, the tracks layer and begin to resemble a song.
I've tried using SoundJS and the Buzz sound library, but I keep running into the same problem: there is always a slight delay between loops. This would be fine if all my audio tracks were the same length, but they aren't, so very quickly things go out of sync.
This seems to be a known problem, but I can't seem to find any answer to how to fix it. I came across Hivenfour's SeamlessLoop 2.0, but - unless I'm using it completely wrong - it doesn't actually seem to work (setting a volume returns an error).
If anyone has experience with this, I would truly appreciate any input! Thanks :)
SoundJS WebAudioPlugin uses a look ahead approach with web audio that will loop seamlessly, which is described here in a what will probably be a very helpful on audio timing.
Also be aware that some compression formats will insert white noise into sounds. I believe mp3 does this. WAV is supported broadly and does not.
As for HTMLAudioPlugin, we loop as smoothly as the browser will allow but it does not have the same precision as WebAudio.
Hope that helps.
When I'm doing a seekTo on a video I get a quick flash of some frames preceding the actual time I'm seeking to. Even if the video was paused prior to seek operation. It doesn't look smooth, to say at least. Is there a way to avoid such behavior? Can't it simply instantly jump to a time specified in seekTo()?
Ok, there is the way - make more key frames per second. And if you are working with a series of small clips combined into one YouTube video, put big gaps between them (2 second long each, at least).
I'm making a simple game in Javascript, in which when an object collides with a wall, it plays a "thud" sound. That sound's loudness depends on the object's velocity (higher velocity => louder sound).
The play function:
playSound = function(id, vol) //ID of the sound in the sounds array, volume/loudness of the sound
{
if (vol) //sometimes, I just want to play the sound without worrying about volume
sounds[id].volume = vol;
else
sounds[id].volume = 1;
sounds[id].play();
}
How I call it:
playSound(2, Math.sqrt(p.vx*p.vx + p.vy*p.vy)/self.TV); //self.TV stands for terminal velocity. This calculates the actual speed using the basic Pythagora's theorem and then divides it by self.TV, which results in a number from 0 to self.TV. 2 is the id of the sound I want to play.
In Chrome, things work quite well. In Firefox, though, each time a collision with a wall happens (=> playSound gets called), there's a pause lasting almost half a second! At first, I thought that the issues were at Math.sqrt, but I was wrong. This is how I tested it:
//playSound(2, 1); //2 Is the id of the sound I want to play, and 1 is max loudness
Math.sqrt(p.vx*p.vx + p.vy*p.vy)/self.TV;
Math.sqrt(p.vx*p.vx + p.vy*p.vy)/self.TV;
Math.sqrt(p.vx*p.vx + p.vy*p.vy)/self.TV;
This completely removed the collision lag, and lead me to believe that Math.sqrt isn't causing any problems at all. Just to be sure, though, I did this:
playSound(2, 1); //2 Is the id of the sound I want to play, and 1 is max loudness
//Math.sqrt(p.vx*p.vx + p.vy*p.vy)/self.TV;
//Math.sqrt(p.vx*p.vx + p.vy*p.vy)/self.TV;
//Math.sqrt(p.vx*p.vx + p.vy*p.vy)/self.TV;
And the lag was back! Now I'm sure that playing a sound causes problems. Am I correct? Why is this happening? How do I fix it?
I ran into this same delay issue making a sound when the player fires a weapon. My solution was two-fold:
Play each sound at load time and then pause it immediately. This will allow it to resume playing quickly, rather than playing from scratch. Do this play-pause technique after every play of the sound.
Use a pool of <audio> objects for each sound, rather than a single audio object for each sound type. Instead of just using sounds[id], use a 2D array, accessed with sound[id][count]. Here, sound[id] is a list of audio objects that all have the same sound, and count is the index of current object in use for that sound id. With each call to playSound(id), increment the count associated with that id, so that the next call invokes a different audio object.
I had to use these together, because the play-pause technique does a good job of moving the buffering delay to before the sound needs to be played, but if you need the sound rapidly, you'll still get the delay. This way, the most recently used audio object can "recharge" while another object plays.
Two things that might help you is to either utilize Web workers or to precompute several levels of loudness in advance, which you could also do in the background with worker threads. I'm saying this without going into the peculiarities of the Web audio API or how your computing the sound output, but if you've exhausted all other approaches this might be the next direction you should be focusing on.
Instead of working with 2 YouTube iFrame API players at a time (playing on one while buffering then playing on the second one and then switching and doing the same on the first one) is there a better way?
Playing videos on one and using the second one for buffering would be a lot cleaner and lot less error prone implementation if it worked - that is one player does not seem to be aware of what the other one has buffered.
All of this ends up even more important when slicing and splicing together a stream of shorter sub-sections from numerous videos because the buffering spinner ends up popping up much more often.
Any ideas ?
First you would need to use Youtube's API to get the duration of each song (then maybe put it in a database) if you haven't already.
If you want to use two players, I would suggest using Tikku's tubeplayer jquery plugin . It works wonders with youtube's jquery API. you could set a function and delay playing (and then pausing once buffer starts - also easy with Tubeplayer) after 90% of the current song has played.
that's just an idea