I have a high resoultion timer object that is supposed to trigger the callback every 2 ms. This works fine on mac, but gets called about once every 500 ms on iOS. If I switch to a regular Timer, then the callbacks work responsively on iOS. Any ideas what is going on?
Weird.. No idea at all. It just runs a high-priority thread, and is the same code on iOS as for OSX, linux and android. I wonder if iOS has some kind of funny thread scheduling that's messing things up?
Weird indeed. I'll let you know if I find anything interesting.
iOS will throttle things down that it thinks are being a hog. I thought that was per app, but maybe it's getting that thread? What if you trigger less often?
I've just implemented the HiResTimer in an App I'm working on, and tested it on my original iPad Mini: I went to 2ms accuracy as well, but in this case ( JUCE 3.1.0 , iOS 8.1 ) I had no issues. It's working like a charm ( so far ).
Mind you, I'm being resource paranoid, absolutely no new objects are constructed in the callback method, in fact, I'm not even creating stack variables ( directly accessing pre-allocated iVars only ), I doubt that last bit is really necessary, but I went with it and it was easy enough to do.
Also, for time stamping, I'm avoiding calling a method, and instead using the C function CFAbsoluteTimeGetCurrent(), in fact, in general, inside the callback methods, I'm trying to keep any extra method calling to a minimum ( though, to be honest, in Obj-C, once a method is looked up and the address is cached, the calling becomes very fast - so this probably isn't that much of an issue ).
So far, on my iPad Mini, HiResolutionTimer takes up 10% of the cycles of an App, that's using 30% of the horsepower of the iPad Mini ... not trivial, but hardly overwhelming … there's plenty of horsepower to spare, but Jules is right, don't implement HiResTimer unless you really need the extra accuracy - but if you do, it probably won't break the bank.