Yes I've tried the multimedia timers. The problem is that on Windows they aren't quite good enough for musicians, frankly. They don't let you quite achieve the 1 ms precision that musicians require. There is a Microsoft article about that here too:
So, anyway, it actually turned out it is only partly solved. I had the HPET enabled as well - the HPET described in that article which I think is a normal feature of modern chips.
To enable it you open up an admin level command prompt and type:
bcdedit /set useplatformclock true
then you need to reboot.
This requires Vista or later.
You know it is enabled if QueryPerformanceFrequency gives you a frequency in the range of 14+ MHz. You might possibly need to enable it in the BIOS as well.
To disable you do the same and type
bcdedit /deletevalue useplatformclock
It's disabled by default. Which seems surprising since it improves multimedia performance - or should - but from the forums it seems some users have issues including reduced performance of some games and mouse pointer "ghosting" and some report freezes with it enabled in the forums. So they might have decided it is more trouble than it is worth to have it enabled by default.
So - with HPET enabled and using the interrupt timer I get this perfect timing.
Actually turns out the interrupt timer changes only once every ms on my computer (roughly) and stays steady in between those calls. So I suppose on some other computers might change less often.
So though very fast look up, you wouldn't probably use it for code performance testing. I'm planning to use it most of the time, but to use the QueryPerformanceCounter(..) for the last couple of ms of the loop just to time fractional ms increments, if required (or for longer if it turns out to have larger increments than 1 ms).
Also bug fix in the previous code, seems you have to do this every time you check it:
// http://www.dcl.hpi.uni-potsdam.de/research/WRK/2007/08/getting-os-information-the-kuser_shared_data-structure/// However, to ensure applications (Win32) to read a consistent time value, the order in which the members of KSYSTEM_TIME are updated has a very strict manner. // The ISR first updates High2Time, then LowPart, and finally High1Time. // A consuming application must read the structure the same strict but // inverse order, that is, it first reads High1Time, then LowPart, // and finally High2Time. If High1Time and High2Time are equal, // the High1Time:LowPart is a consistent value. // Otherwise the application was interrupted by the clock interrupt and // needs to read the structure again.for(;;)
ts.SysTime.High1Time = USER_SHARED_DATA->InterruptTime.High1Time;
ts.SysTime.LowPart = USER_SHARED_DATA->InterruptTime.LowPart;
if(ts.SysTime.High1Time == USER_SHARED_DATA->InterruptTime.High2Time);
On the backwards timers, there is one thing to be careful about - this caught me out - if you have a multi-threaded app with different threads calling the time simultaneously it might seem to run backwards just because you are using the previously recorded time of one thread and comparing it with the current time of the current time. I fixed that by using thread local variables to check the previously recorded time.
It turns out that that was the reason why I thought I had the time going backwards - not multiple cores or anything just a bug in the code for testing if the time was monotonic in a multi-threaded app.
Sorry about that!
Anyway - still have these timing issues for users who run my program on a computer with the OS set to not use the HPET - as it is by default. So - what I'd really like to know is if there is any way to access the HPET in the case where Windows isn't using it for timing itself? Is there some assembly language way for instance to get at its register even though Windows itself isn't using it?
Don't really think there is or surely someone would have posted a way to do it by now, and everyone would be doing it, but you never know .
So - seems - that code actually does work, you don't need to do it for the entire thread, just with every call as in the example code.
Sorry for the confusion.
So - seems - here anyway - that you can get time reversals if you let the time be measured on any core.
You avoid them if you access the interrupt timer via KUSER_SHARED_DATA though that doesn't have the same resolution on my computer as the QueryPerformanceCounter (only changes every 1ms - though it seems likely that it reports the exact time at the moment that it changes - so you could time an exact ms by just waiting in a busy loop for it to change).
But to get the clocks running at a constant rate you need to force the OS to use HPET. Doesn't seem to be anyway for a program to access HPET if Windows isn't using it as far as I can see anyway.
HPET is guaranteed, on Intel machines anyway, to be accurate to 0.05 % over 1 ms and
I don't know if you're aware that HPET implementation on some motherboards are flaky, in particular AMD Chipsets, may also have problems with boards that have SMI incorrectly generating too many interrupts.
Take a look at the foot of the Wiki page for High Performance Event Timer
Lastly, some source code you might wish to take a look at ($0.00) zip
I did wonder if you might want to look at the source code for VirtualBox with has options to enable HPET features for VMs.
--* OFF TOPIC & Previously touched upon *--
There have been problems with multi-core timer issues, and apparently there is serialized cpu instruction to avoid out-of-order execution affecting timer readings. RDTSC (not serialized) RDTSCP (new)
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
Oh right, maybe that is why some users have issues enabling HPET while others find it works just fine for them.
When it comes to musicians, if this is indeed the best way to achieve sub-millisecond precision on Windows with true exact timing - well they might well when buying new computers choose to buy one that can have the HPET enabled without causing problems. You often get exchange of notes and musicians asking each other which computer makes in their experience work best for music making. Normally ones that score well for silence, and latency and DPC. But this seems another thing to add to the list.
It is hard to over-stress how important it is for musicians to be able to play midi notes and record them with sub millisecond precision, and at least - not with multi-millisecond errors.
I just checked it up, I think from this post that RDTSCP is just like RDTSC except that it also tells you the processor id.
But so long as you don't mind forcing your thread to go to core 1 whenever it checks the time, then SetThreadAffinityMask seems the way to go - I was wrong earlier when I said it seemed that the thread has to sleep first before it works, that was that bug in my own code.
It seems to work instantly somehow - does this mean the scheduler instantly moves the thread to the other core?
I suspect that probably it looks ahead in the code and when it sees a SetThreadAffinityMask in the near future moves it to another core in anticipation.
Thanks for your suggestion, I tried this and its successful.
I did EnableDHCP and few others but on enable static it's not working.
on enable static IP address is to be there in an array(SafeArray).
Do you have any Idea?
This is my first code using DirestShow and could use some help with this linker issue.
The “problem “ is that the second usage of CoCreateInstance with CLSID parameter of CLSID_VideoMixingRenderer fails to link.
Here is “standard” linker error:
I have replaced ( in uuids.h) failing CLSID with working one , same linker error.
Since I do not know squat about this I guess I need to find out what it should be to make this troubleshooting more effective.
The library is inluded. That is why I am lost since one of the CLSID works and the other does not.
Maybe I should look for #ifdefs in the uudis.h, but the compiler "reported" the #pragma message I stuck in front of the "bad" CLSID.
Then the chances are that there is another missing library. Unfortunately I have no experience of this package and only found the answer by searching through the documentation. I am afraid you will have to do the same.
I can understand if you are trying to stay with VC6 for financial reasons, but I have to echo the last line of the response "You should really think about upgrading to a more recent version of the IDE."
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
Don't worry, I will not give you a whole lecture about upgrading, just suggest it. I am using VS2010 and I don't have problems with Windows SDK 7.1, I think .
From what I have heard, VS2010 is slower than VS2012, so you might be even more disappointed should you switch to that.
I recalled reading a post a few weeks ago in the Lounge by Marc Clifton where he said VS2008 was the last usable IDE put out by Microsoft. I hunted the post down for you in case you are interested: I would have to say...[^]
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
I truly appreciate you sparing me from lecturing how cool MS stuff is.
I was once interviewed by MS “experts” only to find out that the development “teams” do not maintain any records from one release to another – in their own words “ we do it from scratch because we have new “teams”. I was actually glad they did not hire me.
I also believe the other reason their stuff so boated and full of holes need fixing is they are actually hardware company – pushing for more memory, larger HDD and even “developed” CD because loading OS using couple of dozen floppies was ridiculous.
I wish I could figure out why the VFW is so flaky and skip the Direct whatever for now.
If the DirectShow sample posted ( written with VC6.0) here worked for me I suspect I would find out that it also have problems to display the captured video.
Actually that is the root of my current linker problem – the CVMRCaputre class posted here does not link either, I get same linker undefined symbol. Unfortunately the author is no longer active – so I got double trouble.
Makes one wonder why so many authors of video capture programs posted here disappear from the scene fast. I guess the only stalwart is CxImage stuff.
Sorry for the rant, going on my morning walk now.
Cheers and have great day.
Unless I can find a source code ( just dreaming) for this stinking stream id library to build my own - what are my alternative(s) to do RELIABLE video capture besides ( expletive deleted ) DirectShow?
I really do not want to switch to Linux and start over.
No more cheers from me on this one.
I want to extract frames from a compressed AVI video file.
I have used WIN32 Apis such as "AVIStreamGetFrameOpen" to extract frames from a uncompressed AVI video file.But for a compressed AVI video file the API "AVIStreamGetFrameOpen" returns NULL.Are there APIs to extract frames from a compressed AVI as well as uncompressed AVI file.