timer problem under vista

noot · Post by **noot** » Mon Sep 17, 2007 1:40 pm

i have this small program that plays soundfiles at designated intervals, like a metronome / drum machine, and the timing for the sounds relies on the ElapsedMilliseconds() function. I put it together under XP and there it beats time like nobody's business, but when I run it under Vista it goes totally bonkers, speeding up and slowing down all the time, even if no other programs are running...

is there another way of having something happening at exact millisecond intervals that I should be using, or is this just another Vista problem..?

netmaestro · Post by **netmaestro** » Mon Sep 17, 2007 4:49 pm

This should work:

Code: Select all

Procedure Pulse(uID, uMsg, dwUser, dw1, dw2)
  Debug "Hello! I was sent the user value of: "+Str(dwUser)
EndProcedure

timeSetEvent_(1000, 0, @Pulse(), 5, #TIME_PERIODIC)

Repeat
  Delay(1)
Until GetAsyncKeyState_(#VK_ESCAPE) & 32768

noot · Post by **noot** » Mon Sep 17, 2007 7:43 pm

well... thanks, seems to work, but i'll have to rewrite all my programs to implement this

is there documentation somewhere for timeSetEvent_?

rsts · Post by **rsts** » Mon Sep 17, 2007 8:42 pm

noot wrote:well... thanks, seems to work, but i'll have to rewrite all my programs to implement this is there documentation somewhere for timeSetEvent_?

msdn - multimedia sdk

cheers

noot · Post by **noot** » Wed Sep 19, 2007 8:24 am

OK, still on this topic:

I'm still using ElapsedMilliseconds(), and I just ran the program on both machines with the same soundfiles (small) and same parameters, and had a look at the task manager:

old machine (XP): memory usage 8500kb, CPU usage stays between 0-2 percent, no noticable difference in timing.

new machine (Vista): memory usage over 10000kb, CPU usage bouncing between 0-10 percent, AND if the program window is selected, it goes up to 20-40 percent, with expected results...

now WHAT exactly is happening here?

does this have to do with the way Vista allocates resources to programs? i'd like to stick to the current programs because they seem to work well enough and i don't have any idea if rewriting them with timeSetEvent would even correct this problem... any ideas?

pdwyer · Post by **pdwyer** » Wed Sep 19, 2007 10:29 am

It's your hardware screaming from under the OS to upgrade to XP

Seriously though, this is pretty scary. Something as basic as ellapsedmilliseconds not working properly...

How about if you change it for that API queryperfticks or something (can't remember the name)? maybe you could put a wrapper proc on it and copy-paste it though your code if it works. Apparently it's more accurate to the millisecond too so it might be better

DoubleDutch · Post by **DoubleDutch** » Wed Sep 19, 2007 11:04 am

Did you do an update to Vista or a re-install to Vista? I have found that updates from XP are quite a bit slower than fresh installs with regard to Vista.

Also Vista appears to take a *lot* more RAM than XP to work properly. Using a ReadyBoost memory stick can speed up your system a lot if you cannot add extra RAM (you may not have any DIMM slots left) - add both if you can. Using ReadyBoost can also save HDD usage and so possibly make it last slightly longer - well worth the tenner!

If you don't need all the extra Vista bits, you can actually make it look like XP and get similar (imho slightly faster) performance with the same amount of memory as before (when it ran XP).

imho Vista appears to allocate more resources if they are not needed elsewhere. For instance the RAM cache appears not to be returned unless there is a need by an application for more memory - why return it as until it's needed it's best as RAM cache. I don't think that this is the same is XP.

noot · Post by **noot** » Wed Sep 19, 2007 11:45 am

this is pre-installed Vista so shouldn't be a problem there...

took off all the extra crap right at the start, and I'm not running any virus shields or anything (while btw on the much slower XP machine I have F-Secure running at the same time and even that doesn't slow the timer down!) - in short i've tried to pare it down to do nothing else than run this small silly program, and it still can't handle it.

it's probably down to the resources allocation system... I've turned the control panel inside out trying to find a way to switch this off but it's probably not possible...

pdwyer · Post by **pdwyer** » Wed Sep 19, 2007 1:10 pm

I'd still try changing just that call to a similar API, it would tell us if this is an isolated issue and be fairly easy to work around

rsts · Post by **rsts** » Wed Sep 19, 2007 1:20 pm

Certain subsystems were almost totally rewritten for Vista. Video and audio being among them.

Depending on what you're doing (e.g. with Video and audio), and the video and audio drivers present, Vista could be acting quite differently than XP.

Since your system came preinstalled, I would expect the video and audio drivers to be correct, but you might want to check for updated drivers since most vendors were scrambling to get them ready (and some still don't have good ones).

cheers

noot · Post by **noot** » Wed Sep 19, 2007 5:06 pm

thanks for the tip paul, i'll try it with something else (GetTickCount is it?), and maybe also check the driver updates... i'll report back when i see what happens

noot · Post by **noot** » Wed Sep 19, 2007 8:25 pm

OK, I changed it to GetTickCount_(). XP works fine as before, Vista
got even more messed up than with ElapsedMilliseconds(). Now the
program takes up 30-40% CPU all the time and memory usage
increased to 11000...

what about this - does anyone think this could have to do with the fact that the computer with the timing problems is dual core and the XP one isn't. I remember reading something about this, but I don't think it should affect GetTickCount_() or ElapsedMilliseconds() should it?

Derek · Post by **Derek** » Wed Sep 19, 2007 9:34 pm

Can you put together a little example that goes nuts and post it here, the example from netmaestro works fine on mine, dual core vista, with only about 1 - 2% cpu usage.

pdwyer · Post by **pdwyer** » Thu Sep 20, 2007 1:21 am

AMD has timing issues with some dual cores, theres a patch out on their web site.

One of the ways you can test this is to ping something close by (like your default gateway) and you get a negative response time. You know you need the patch then.

Not sure if the Intel core duo's have any issues or not

Rescator · Post by **Rescator** » Thu Sep 20, 2007 5:02 pm

You are not telling us how you do the loop(s).
Do you use WaitWindowEvent(ms)
or WindowEvent() plus Delay(ms) ?

Also be aware that on Vista, audio is software only. (no hardware support)
Unless you use OpenAL that is or you got a creative card and their ALchemy driver that sorta redirects audio calls to OpenAL driver.

[soapbox]
Common PureBasic team, with Vista, PureBasic is in even more need for native support of OpenAL. (did I mention that OpenAL is avail on Windows, Mac and Linux, and that on all platforms it has fallbacks like on Windows you can have it try native (audio driver shipped with card drivers, hardware on both 9x/XP and Vista) or DirectX hardware (9x/XP only) or software (Vista and 9x/XP) or WaveOut (hardware/software on 9x/XP, software only on Vista I believe?)
[/soapbox]