Printable Version of Topic

Posted by: Kristofer Dahl Jul 2 2007, 10:06 AM

Hey there,

We have a very helpful user named Marraboy, who is a flash programer (check his site http://www.morangutan.com/) and who has decided to donate a flash metronome to GMC. He has insisted to do it for free so be sure to help him out in the forum as much as you can!

Either way - there seems to be a slight bug, we have agreed to ask openly about it. So if anyone has a suggestion how to solve this, please let us know here.

Check out the metronome in Wallimann's most recent lesson (found http://www.guitarmasterclass.net/solo-guitar/phrygian-to-ionian-modulation/index.htm).

You might notice that the metronome clicks unevenly at higher speeds - which is what we would like to fix. This is only a problem when the flash video player is open simultaneously.

Kris

Posted by: MickeM Jul 2 2007, 10:33 AM

There must be Flash forums where people can help. I don't know if these are any good, just googled a couple.

http://www.flashsupport.com/forum/
http://www.flashguru.se/forum/?gclid=CJ_XvYK7iI0CFSEQZgodel1_jw


And the metronome see uneven at any speed and it's not up to tempo, it falls behind my Guitarport metronome in speed. Or it's my metronome that is not perfect.

Thanks Marraboy for helping

EDIT:
And the "falling behing in speed" happens also when flashplayer is closed. I'm curious to know if it's this or my metronome that's got the wrong tempo.

Posted by: Resurrection Jul 2 2007, 10:49 AM

I don't have experience of flash programming, but I do have quite a lot of experience in developing software generally. My question would be how is the timing of the metronome ticks generated? Is it from a hardware timer? When the time expires and a new tick is needed, how is this event serviced? The problem sounds like the flash player sometimes has to do a higher-priority thing rather than play the tick when requested, resulting in uneven ticking at higher speeds. The fact that the problem is worse when the flash video player is active would also indicate this. Can the metronome 'tick' routine be put on a higher priority? The only other explanation I can come up with is that the timer is very inaccurate in counting out the required delay.

Not much of a solution I'm afraid, but maybe it will give Marraboy a few ideas about how to tackle the problem.

Posted by: Andrew Cockburn Jul 2 2007, 02:00 PM

I would echo what Ressurection says,

but wanted to add, thanks Marraboy for helping to make GMC even better !

Posted by: Kaneda Jul 2 2007, 02:03 PM

I'll have a go, although I gave up on the Flash timing accuracy issue a loooong time ago

Flash's standard timing functions (setInterval, setTimeout, mx.utils.Timer etc.) are nowhere near accurate enough for millisecond timing, no matter what you do. Javascript's similar functions are much more accurate, but still not really good enough for a "professional accuracy" metronome (and then you'd have to do Flash calls from Javascript).

One thing that might help (haven't tested the metronome, and obviously haven't looked at the code, so I have no idea how you actually did it) is to remember, that if you set a Timer (or use setInterval) with an interval of 1000, it's not called every 1000 milliseconds (even if that was the idea of the Timer in the first place). What the interval really is depends on how long it takes to execute the function (event handler) that handles your timer event.

In other words, if you set a Timer with an interval of 1000, and your TimerEvent.TIMER event handler takes 300 ms to execute, the timer will actually be called at an interval of 1300 milliseconds...

I.e.:

We start the timer: 0 ms have elapsed.
The timer "fires" 1: 1000 ms have elapsed.
The timer event handler is called 1: approximately 1000 ms have elapsed.
The timer event handler has done its job 1: 1300 ms have elapsed.
The timer is reset: approximately 1300 ms have elapsed.
The timer "fires" 2: 2300 ms have elapsed. (1300 + the 1000 we wanted)
The timer event handler is called 2: approximately 2300 ms have elapsed.
The timer event handler has done its job 2: 2600 ms have elapsed.
etc.

In other words, the timer reset is not done asynchronously.

Note: This goes for setInterval too.

You can get around it somewhat, by using getTimer() to get the actual time when your handler starts, and when it ends, and adjust the interval until the next time the timer fires by the difference in getTimer().

Note, though, that I emphasized approximately, because even the internal handling (going over the event handlers you have defined) takes time, so it won't be 1000 ms the first time your event handler is called either - probably more like 1020 - 1030, depending on what computer you run it on.

When the videoplayer is playing in the background, Flash is even more "busy", hence the timer is thrown even more off.

It's a recursive, and platform-dependant, nightmare of inaccuracy, it never ends, and it sucks.

Note that the frame/timeline animation of Flash is much more accurate, so you might want to look into doing the metronome sound based on the timeline, and use ActionScript 3's methods for adjusting framerate dynamically.

Posted by: Andrew Cockburn Jul 2 2007, 02:46 PM

As ever, Kaneda gives a complete and well resoned response

I'm guessing you can't reset the timer right at the beginning of the handler like you can in some languages.

Maybe this would work better in a Javascript + DHTML format?

Might even try that if I ever get a spare moment ...

Posted by: Kaneda Jul 2 2007, 03:14 PM

Because JS does setInterval etc. asynchronously, it is much more accurate - the inaccuracy can be adjusted with the various time functions (like Yahoo do for their animation libraries). For some reason, ActionScript just doesn't handle time asynchronously, so it has to wait for the execution of other code.

I've yet to find a way that makes it accurate enough to do real audio work - the mx.utils.Timer object could be reset, but that's just going to do the same as letting it run - it won't start (again) until you're done doing whatever you want to do in response to the timer event - and by then, you can't be absolutely sure what amount of time you should set for the interval to compensate for the time spent in the event handler. It's infinitely stupid handling of time in something that's supposed to be a multimedia/audio/video/animation tool...

The first step to see how accurate Flash could be on its own, would be to call getTimer() at the start of the event handler. Call it again at the end, and set the interval until the next event handler call to [the-interval-you-want] minus the time spent in the function (the difference between the two getTimer calls). Of course, if Flash is busy enough, that difference would end up being larger than the wanted interval (say, if Flash spent 600 ms in a function, and there was only 500 seconds until it should be called again. Then you'll end up with -100, which means "skip the next beat"

Then, as I suggested, there's the hybrid approach, where JS keeps track of the time, and calls a function in the Flash plugin (through Flash's ExternalInterface or the earlier TCallFrame stuff), which then takes care of playing back the sound etc. (since there's no better cross browser/cross platform audio/video playback these days than what Flash provides). Not sure, however, how fixed the latency from calling a JS function until Flash handles it would be. If that varies with CPU load, it's all hell again.

The other way might be to use variable framerates combined with a simple "animation" that plays the sound - but I haven't tried that approach - should be more accurate, since the timeline in Flash is more accurate than AS timers by design.

Posted by: Resurrection Jul 2 2007, 03:35 PM

Great explanation Kaneda! There's little doubt that an environment like flash will find it extremely difficult to generate audio-accurate timings. I write a fair amount of audio coding software, but it's within embedded devices, where you generally have access to very accurate timers within the processor that can fire interrupts at pretty precise times. If you throw in a multi-tasking OS and web-based applications, then it's not hard to see how inaccuracies can creep in, although the timing tolerances for a metronome are obviously a bit wider than for audio generally! I agree that a timer generating asynchronous events should give much better performance, provided the signals/interrupts are serviced with a fairly high priority.

Can't comment on your suggestion about using the frame/timeline in flash, as I don't really know anything about it. However, I wonder is it feasible to set up feedback control on the framerate by counting ticks over a longer period (averaging) and making small adjustments to the framerate, just to avoid continual accumulation of timing error in either direction? Just a thought, not sure if it's feasible or relevant.

Posted by: fkalich Jul 2 2007, 03:46 PM

I was thinking about that, not the timeline, just a subroutine that makes adjustments. problem seems to be though, that when he is using flashplayer, a very large delay can be introduced when flash gets busy, and even though it could be corrected after the fact, the cow already got out of the barn. am i wrong?

but then again, perhaps whatever the timing interval was, the routine could divide that interval by some factor, say by 4, so make the check more often, see if it is time to act, if not make a correction. i expect some scheme to make running corrections would work tolerably. it might screw up once in awhile, but it might still be accurate enough to be acceptable.

Posted by: Kristofer Dahl Jul 2 2007, 04:24 PM

Thanks Kaneda - even though this obviously is way beyon my level of understanding - it's seems you know what you are talking about.

If anyone wants to have a go at the swf file - pm me and we can try it live!

Posted by: Eat-Sleep-andJam Jul 2 2007, 05:03 PM

Thats strange that it does that .. Have you asked Marraboy himself about the bug? Him being the flash programmer he might know how to fix it ?
But as for now it seems we can at least practice up to where it starts making it mistakes. Does anyone have an exact Bpm of when this occurs ? Thanks-John

Posted by: fkalich Jul 2 2007, 05:34 PM

it is not a bug, not really. the logic of what he did is there. however flash is a very high level language, that is, a very busy one. a lot goes on, and subroutines have to wait their turn to be served. normally these slight delays (fractions of a second) have no bearing in any practical sense, and are not noticed. for applications that require precise timings, a language closer to the machine is more appropriate. however, for such languages, building a gui is a major task. in flash building a gui such as for this metronome is trivial.

i will play around with this, see if i can come up with something, in the next couple days (unless somebody takes on the challenge and beats me to it). there is almost always a solution to these things, not always, but most of the time. basically what has been stated above is what needs to be done, a scheme to correct the inevitable delays in response.

edit: here is a link, where the guy says pretty much the same thing.

http://www.bit-101.com/blog/?p=910

I am hoping somebody takes up the challenge so i don't have to, being a very lazy person, who does not have a lot of ego, or at least a person who tries to keep his ego in check, i would be very happy with that outcome. I don't think it would be very difficult, it does not have to be perfect, just close enough from the user's perspective.

Posted by: Kaneda Jul 2 2007, 06:03 PM

Same thing here, fkalich Except I wouldn't ever take up the challenge, since a project I'm already doing for GMC is on hold while I find a new job etc. and get over Summer. I, on the contrary, hope that someone else doesn't take that project over before then

EDIT: Might add, if you do look into this, Flash may actually "freeze" completely for up to 500 ms, mostly in order to garbage collect - there wouldn't be much garbage collection done in the metronome itself, but unfortunately, only one instance of the FlashPlayer is used across each browser - for all Flash content, and since it's used so much for streaming video these days, this freezing might also become an issue (although you'd deal with it the same way as the other timer lagging).

Posted by: Marraboy Jul 2 2007, 07:02 PM

Blimey!!! A few posts here then!!!


The metronome does indeed use setInterval()

I'm a little unconvinced that the problem is simply Flash itself. There is a very minimal amount of code in the program. Not sure about garbage collection in Flash, but I guess there wouldn't be much garbage to collect as there is not many variables.

One thing I can confirm is that when the SWF file runs independant of the browser, in a .exe projector it seems to perform better (much better in fact). Not sure if this has something to do with it being compiled into a binary executable?

Flash is a bit poor when it comes to 'realtime' stuff when in a browser, especially with graphics.

Maybe Flash isn't cut out to be a metronome!!!

Marraboy

Posted by: Kaneda Jul 2 2007, 07:25 PM

The problem with graphics performance is often due to the FlashPlayer having to cooperate with the browser (even if it doesn't cooperate much - Flash content is by default simply drawn on top of the browser window - disregarding whether any HTML is supposed to be above parts of it ). But since there's not any animation in the metronome, that's not it.

The problem with performance in general, is that the moment you have FlashPlayer in a browser, two things are crippling it:

1. The browser has to allocate time to FlashPlayer out of the time the OS has allocated to the browser (i.e., a fraction of a fraction), while in standalone, the OS allocates time directly to FlashPlayer.

2. The FlashPlayer experience will often degrade over time, until the browser is closed, because as soon as a page uses Flash, the FlashPlayer is loaded, and then that same instance will be used for the rest of the browser's "lifetime".

Actually, if you don't clear a setInterval on unload, you may actually see the interval being fired twice as often each time you press refresh - simply because the interval keeps running in FlashPlayer after the swf has been unloaded It's a leak going back to FlashPlayer 4 or so, and I don't believe they've fixed it to this day (they hadn't in FlashPlayer 7). This may also hamper performance in your metronome for each reload (rather than playing the tick twice per interval), depending on how the interval handler is written.

There are other leaks like that, including a fair amount of memory leaks. Garbage collection is handled globally across swf's in the browser (and "absolutely", as in, garbage collection starts when the total allocated memory gets to a certain threshold), and thus while your swf doesn't need much garbage collection, remains of some other swf (like YouTube) may - even if the swf is not playing anymore

The .exe standalone file is really no different from the .swf - it's the same .swf appended to a static version of the FlashPlayer, which plays back the file in pretty much exactly the same way as the browser plugin - with the added benefits described above.

Have you tried doing it in AS3/Flash CS3? While setInterval and Timer are apparently still as inaccurate as always, AS3 does have an immense performance increase when it comes to running code, so the lag may not be as big.

Posted by: fkalich Jul 2 2007, 07:55 PM

have you played with the AS3 Timer class? My download substription of AS3 just expired, gettting it on another computer (at some point I am going to have to fork out the $500 for the Web premium upgrade). I will play with the Timer class in a bit, do some testing. I don't think that was in 2.0, correct?

edit: correct, new to AS3, worth a try.

Posted by: Marraboy Jul 2 2007, 09:08 PM

I haven't even looked at AS3 yet, as I have too much onoing AS2 stuff!!!

It's simple don't look at Youtube before you use the metronome!!!

I guess that if the user closes the browser completely and reopens this will destroy the initial instance of the flash player?

As you know your flash stuff, have a look at this and see what you think: http://www.electro-server.com/forum/?f=2&m=3743 - it's baffling me?!?!?!

Posted by: fkalich Jul 3 2007, 12:42 AM

I will look later at that link. BTW, Moock's 3.0 book just came out, I ordered it today. As you may agree, nobody writes on Actionscript better than Moock.

I am surprised that you got the metronome to work at all with Flash, in any steady beat. I ran some tests using 3.0, and to me it does not seem possible, just too much going on. Below is an example where i check every 5 milliseconds, at 240bps. Seems like it is impossible to avoid delays, based on my readouts. Weird thing is that even when the readouts are pretty steady, I can hear an unsteady pattern to the beat. Perhaps the routine passes the command to the mp3 players asynchronously, but there is a delay in the player module, would not surprise me. You are saying you got this to go steady?

Based on what i have seen, i have concluded that our friend from Holland is right, just no way with flash to get that kind of accuracy. I read where that is the case in another source, seems that delays of up to 100 ms can occur at times, and smaller ones quite frequently.

I realize only half our audience will understand this, not the half working in the food service industry.


package {
import flash.display.Sprite;
import flash.utils.*;
import flash.events.TimerEvent;
import flash.media.Sound;
import flash.media.SoundChannel;
import flash.net.URLRequest;

public class MyTest extends Sprite
{
// The time of the last beep
var lastBeepTime:Date;
// 4 bps so 240 bpms
var INTENDEDINTERVAL:Number = 250;

var _sound:Sound = null;
private var url:String = "beep_1.mp3";
var myBeep:Sound;

public function MyTest()
{
// Timer will go off every 5 ms
var myTimer:Timer = new Timer(5);
myTimer.addEventListener(TimerEvent.TIMER, onTimer);
lastBeepTime = new Date();

var request:URLRequest = new URLRequest(url);
myBeep = new Sound();
myBeep.load(request);

myTimer.start();
}

function onTimer(event:TimerEvent):void
{
var sampleTime:Date = new Date();
var msPassed:Number = sampleTime.getTime() - lastBeepTime.getTime();
// if time passed is at least the interval - 5ms
if( msPassed > (INTENDEDINTERVAL-5) ) {
trace("Time elapsed Before BEEP at "+msPassed+" MS");
myBeep.play();
lastBeepTime = sampleTime;
}

}
}
}

Posted by: Kaneda Jul 3 2007, 08:11 AM

Instantiating a Date object every 5 ms at least won't make it more accurate And since all of FlashPlayer's timing is based on SetTimer (in the Windows API), rather than multimedia timers, and SetTimer/WM_TIMER has an accuracy around 10-15 milliseconds, setting intervals at 5 ms will do no good

And since the Timer class was already discussed earlier in the thread, I guess my job here is done.

Posted by: fkalich Jul 3 2007, 08:41 AM

That is not consistent with my test results. Below I show readouts with sampling every 250ms for that example (240bps), and then with 5ms sampling. You can see the 5ms are dramatically more accurate. I ran some further tests. The average error size grows as the sleep interval that you use increases. With frequent sampling (< 25 ms) timing error is generally single digit. With 250ms in the teens. With 1000ms sampling the errors tend to run closer to 50ms. Clearly we have cumulative damage to the calculation, the longer the interval between the sampling of the time.

However, if I move my mouse around while doing the test, the numbers blow up. That is why I don't think this will help. Also I think the mp3 player itself will have some unpredictable response delays using Flash, so even if the call is accurately timed, it may be off beat due to delayed response of the player. metronomes are probably not practical using Flash. As you said earlier.


250MS SAMPLING:

Time elapsed Before BEEP at 328 MS
Time elapsed Before BEEP at 281 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 297 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS


5 MS SAMPLING:

Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS

Posted by: Kaneda Jul 3 2007, 09:50 AM

Tried it in a browser? Rather than the internal flash player. It sure is consistent with any tests I've done over the past 3 years (last time I checked FlashPlayer performance was the FlashPlayer 9 update 1 beta), plus you'll be straining the player's performance severely as soon as you go below 50 ms. When moving the mouse cursor influences timing, that's a telltale sign that the WM_TIMER messages are clogging up the message queue, or you're on a computer from the mid-90s. The internal player may not use WM_TIMER (but it still seems it does, if mouse movement influences it that much). The external one certainly does. It's a http://www.kaourantin.net/2006/05/frame-rates-in-flash-player.html fact.

As for the mp3 playback issue, you're right - can't count on that either. Sound.start() latency is a well known problem. The flash sample buffer loops every 2048 samples, and sound.start won't have any effect until the moment of the loop. Depending on when you call the function in relation to when it loops, timing will be inconsistent. Plus, you can't even count on that exact rate since FlashPlayer 7.

Posted by: fkalich Jul 3 2007, 05:34 PM

Everything you say sounds right. To be looping every 5 ms would as you say, not be a great thing to do That was primarily a test at the extreme, the results checking every 50ms would be pretty close to just as effective.

Which still really won't be effective (it seems to me).

edit: it take it back, if you sample at over 10ms or so, the results deteriorate. however, it means nothing anyway, because you still do get an occasional delay, maybe only every 5 or 10 seconds, but enough to be unacceptable. and besides that, the mp3 latency is there quite a bit even when the notifications are on time, i can hear delays even when i see steady timings, it just won't work, as you indicated.

Posted by: Hardtail Jul 3 2007, 06:01 PM

Here just use this maybe. I uploaded to my website so download as much as you want. Seems to work fine to me. This one also includes a perfect 440 hz "A" for tuning.

http://www.smalltree.net/metronome.swf

Hardtail

Posted by: Hardtail Jul 3 2007, 06:12 PM

Also, I didn't realize until I reread Kris's original post that the higher speeds are the problem. But to be honest the whole thing is the problem and only at higher speeds do you notice it because the problem starts becoming compounded.

Based on my knowledge of Flash I'd recommend trying a solid tone and use your interval timers to manipulate the volume off/on function. That way the audio file in the SWF only revvs up once (which is where the delay is BTW) and then the "Beeps" are actually just short intervals of VOLUME ON. This should clear up any problems at high speeds.

Hardtail