It looks like the YouTube API does not have a way to stop a video playing once it reaches a certain point. It has a way to start it at a certain point, but not to stop it at a certain point. I'm wondering if there's a workaround for this? or maybe I glanced over it without noticing.
You could do some repetitive polling of the time elapsed with player.getCurrentTime() and then when it reaches the point you want, call player.stopVideo(). If that's a little too busy, you could use a timer and only start polling after a certain time had elapsed.
Related
I'm making an app that plays synced audio loops with a metronome. For example, I might have 3 files like this:
bass_60bpm.m4a
drums_60bpm.m4a
guitar_60bpm.m4a
And a metronome sound tick.m4a, which I play with AKSamplerMetronome.
I need to play them back at arbitrary tempos, so I use AKTimePitcher on the AKAudioFiles (so playing at 90bpm, I'd play bass_60bpm.m4a at 1.5x).
This almost works, but after 3-5 loops, the metronome gets out of sync with the audio loops. I think I understand why that happens (audio_sample_length * floating_point_number is not equivalent to AKSamplerMetronome's tempo calculations), but I don't know how to fix it.
What I suspect I need to do is manually reimplement some or all of AKSamplerMetronome, but play the metronome ticks based on AKTimePitcher's output, but I can't piece together enough info from the API, docs, and examples to make it happen.
An alternate approach might be to use AKSequencer instead of AKSamplerMetronome. The midi output of the sequencer's track could be sent to an AKCallbackInstrument, and the sequencer's events could get the callback function to trigger both the time-stretched sample and the metronome ticks (and you could also trigger synchronized UI events from there as a bonus). This would guarantee that they stay in sync.
Apple's MusicSequence, which is what AKSequencer uses under the hood, is a little flakey with its timing immediately after you call play, but it's pretty solid after that. If you start the sequencer just before its looping point (i.e., if you have a 1 bar loop, start it one sixteenth note before the end of the first bar) then you can get passed that flakiness before the actual loop starts.
I am trying to measure how long an AVPlayerItem buffered before it began playback.
A trivial solution for this would be to simply start a timer/save a timestamp when buffering begins, and stop the timer/compare the timestamps either when playbackLikelyToKeepUp first becomes positive, or use addBoundaryTimeObserverForTimes with a 1ms boundary.
Since this is something I want to use in a production environment (to track performance metrics), I prefer not to start a bunch of timers that could potentially bring down app performance.
Is there a way to achieve this by using KVO or some other method?
I'm working on writing a poker room game in ruby. I'd like to set a time limit on how long each player has to decide what their play is, at the end of which period the game will decide what happens next. (did this particular player time out? did everyone fold? is this the end of the game? etc)
I'd like to poll what's happening on the server from the user's side with JS, but how do I make the server run a background task that advances the state of the game every N minutes? (a value that could be different per each poker room)
This is quite a hard problem to solve. Here might be one of the easiest ways to solve it. Using a background scheduling. For example with sidekiq.
You can schedule a job to update the game state like:
class GameTimoutTrigger
include Sidekiq::Worker
def perform(game_id)
game = Game.find(game_id)
game.timeout!
end
end
And when a game round starts you schedule the timeout trigger
round_timeout = game.round_interval
GameTimoutTrigger.perform_in(round_timeout, game.id)
Be aware that sidekiq will poll jobs in the schedule on intervals (15 secs by default). So there will be always some delay on the timeout.
If the round time must be always exactly 60 seconds for example, you could save the round start and stop timestamps, and user's action timestamp. And only accept user action if it's between the round range. But this might be not necessary. It's just a heads up.
You got the right idea with setInterval().
window.setInterval("javascript function",milliseconds);
The "javascript function" can update the game on the client side and make a request to the server to update. Make sure to clearInterval() if you want to prevent the function from running.
If you're really looking for a way to make the server run a background task, you can maybe try the delayed-jobs gem, but websockets or setInterval is probably a better way to go.
I'm working on an iOS7-only app that needs to display a clock complete with ticking sound. I've used a NSTimer of 1s and I use AVAudioPlayer to play the tick sound every second.
Unfortunately, there's something slightly off with the timing. I've measured that timer is off by between 2 and 22 thousands of a second, which you wouldn't think would matter a great deal, but the lag creates a nail biting tension.. kind of like a heart flutter :-)
I've looked around a bit but it sounds like using audio queue services is the only way to go.. and I really don't fancy delving into the depths of that particular framework again.
My question: Is there some other way of getting precisely scheduled sound events in iOS 7 and failing that is there a decent wrapper framework for audio queue services available somewhere? Or better still is there a way of more precisely scheduling NSTimers?
Using any of NSTimer, libdispatch, or spawning a thread that sleeps for the tick duration rely on the underlying thread getting scheduled in time. The kernel provides no guarantee of this, and it is not surprising that the you observe timing jitter; the latency you observe looks reasonable.
NSTimer running on the main thread is likely to perform worst of these as you are also contending against other events delivered through it.
I think your options here are either to use audio queue services, a real-time thread to schedule the events with AVAudioPlayer, or render the audio yourself to a remoteIO unit.
I don't think AVPlayer provides any particular guarantees about timing either.
I am trying to play an MP3 using Actionscript 2. I have the following requirements:
I don't want to wait for the MP3 to load before playing it.
I want to know when enough of the MP3 has downloaded that I can start playing it.
I don't want the MP3 to start playing immediately: I need to control when the play starts.
An example scenario is that I need to start playing a 30-second MP3 exactly 8 seconds from now (at the top of the minute, let's say). Depending on the connection, I may or may not be able to download the entire MP3 by then, but I can almost certainly download enough to start playing without interruption.
The closest way I can see to do this is Sound.loadSound(url, isStreamable). If I pass true for the isStreamable parameter, though, the sound will start playing immediately (docs say: Playback begins when sufficient data has been received to start the decompressor).
I've tried the following:
call mySound.loadSound(mp3Url, true)
mySound.stop(); // so that the auto-play won't happen
set a timer for the top of the minute (8 seconds from now).
In the timer, check the duration of the sound (which continues to get bigger as the file gets loaded). If the duration is < 5 seconds, we don't have enough buffered sound, so generate an error. Otherwise, start playing the sound with s.start(0).
The behavior I see is that the sound doesn't start playing until it's entirely downloaded.
I found your posting (which is a little older now, but... anyway):
there are two options you can use in the Sound-class:
Sound.getBytesTotal
and
Sound.getBytesLoaded
If you compare these two, you can get the amount of bytes loaded at a certain point of time. (See also Sound.onLoad and Sound.onSoundComplete, these two are helpful)
There are also some examples in the Flash help for this.
Greetings,
Draco
I do not believe that this is possible using ActionScript 2. I think you are going to have to either move to AS3 or wrap the MP3 in a SWF.
Even with AS3 you may have to target FP10 in order to use the new sound methods and events that were just added (Sound.extract and Event.SAMPLE_DATA).
In general Sound capabilities in Flash have really lagged until the most recent version of the player.