JS/Web Audio: How do I jump to loopStart immediately, while playing? - javascript

I'm working with the Web Audio API in javascript.
Part of my current project involves a looper, I need to change the start and end points of the looper dynamically. Which is working.
But I need the playback position of the audio file to move to the start point when I set it. I've been googling and reading the spec for days, but I can't seem to find an answer.
I know you can set it with the start() function, but I need to change it while it is already playing.
Thanks!

If I understand what you're trying to do, I think the only way to do this is to create a new AudioBufferSource using the same buffer. Adjust this new AudioBufferSource with the same loop points as the original and then call start() with the correct start time and offset.

Related

Stop playing sound before going on to next function

I was tasked to create a simple mini game based solely on Javascript. I encountered a problem as I was adding in sound effects..
After the player drowns, the game should 'return' to its initial frame with one 'live' count decreased. During the drowning action, it plummets down the lake while the sound effect comes into place. However, the sound is activated a few .seconds late and the player freezes at the bottom of the lake. The game does not return either.
I have also tried adding stop() but it doesn't work. Here's a fragment of the relevant code.
gameCharacter_y +=2;
drownSound.play();
return;
Been stuck for days now and am an absolute beginner, would appreciate and be grateful for any suggestions!
Thanks.
In order to manipulate sound you should have a soundmanager...
This makes it really easy to see what clips are playing and pause them and do with them as you please! I'm not sure how to make one in JavaScript...
But what you are looking for is...
drownSound.pause();
There is no 'stop()' method apparently...

Writing javascript to detect speed

I am a new member. For school, they want us to write code to figure out the speed of the device (when driving). Is this possible in javascript? Im assuming it will be challenging but any ideas help! Thank you in advance!
You can use Geolocation API to get current position.
Since speed is distance over time, you can use a setInterval() to periodically get the position (every 3 seconds for example) and calculate the distance between the last and current coordinates.
Since that's a homework/school work, I think I shouldn't give you any code.

When changing video currentTime too much, video fails?

I'm using a user drag event as well as keypresses to change the position in a HTML5 video element and then updating the video time accordingly using:
video.currentTime = toTime;
and then I am updating a canvas based on the video position by grabbing the video and putting it to the canvas.
Another element is that I actually get the video time from the frame number, i.e:
framenumber = 123;
fps = 25;
toTime = 123/25;
Problem is, every so often it just fails. By fails I mean I lose the video; it just stops working altogether.
Most of the time it works great but sometimes it just fails, and not always at the same point either...
Any ideas would be much appreciated!
There were 2 answers to my question:
Encoding of the video files - basically by controlling keyframes and
sending the right video to the right browser I was able to solve a
lot of problems. Using FFMPEG I changed the GOP length.
ffmpeg -g <frames> in my case, where <frames> is the amount of frames between GOP points desired.
Using videojs to serve up the video seemed to solve a lot of problems and made it a smoother an experience.

sync audio to a picture carrousel

Is it possible to sync audio to a picture carrousel without using the canvas? Im currently using setInterval to realize the carrousel. I dont want to use flash and if possible and not too hard to realize, I want to do this without the canvas.
Have you tried a canvas?
Assuming you're using an <audio> element, you can get its currentTime property. This will tell you where the playhead is. You can use this information to change the carousel when the audio passes a certain position, or you can set it to change the audio position when the carousel changes. Whatever works better for what you're doing.
What do you mean by realize the carousel?
I would set a specific timestamp when you want the image to show. So at 12 seconds you want to show image.
You might want to also make sure that the audio is loaded. You can use canPlayThrough to check and see if enough is loaded to play through or you can use audio.buffered.end(0) to check against the length of the audio file and make sure the entire thing has loaded.
Here is a good article for more on this: http://html5doctor.com/html5-audio-the-state-of-play/
When the audio is loaded you call a function and pass in the timestamp and set it as the setInterval time. So at timestamp * 1000 the function will fire and show the image that is passed at that timestamp.
You could also try and use audio.currentTime and fire then, more on that in the article above as well. Let me know if you have a more specific question.

Is playing sound in Javascript performance heavy?

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.

Categories