Re: [AD] SetTimer for the timer

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2006-01-09 at 02:15 -0800, Chris wrote:
> > > It seems these would fit better than the current hackish way
> > > of running a timed thread.
> >
> > Why is it hackish?  It's pretty straight forward.
> 
> Because they were originally designed to run in an interupt context, not 
> concurrently with the main program (which has led to sloppiness and the 
> mistaken belief that you can wait in a timer for something to occur in the 
> main thread; eg. a mutex). To put it into perspective, if the timer was 
> accurate and better prioritized so it would be used, anything that uses the 
> software mouse or calls a sound/graphic function would randomly freeze solid. 
> Granted the latter shouldn't be done anyway, and the former would hopefully 
> be fixed in some way, but the current implementation clearly allows it.

The documentation always said that you should only use timers to set
variables. I think, the best way around this would be a simple threads
layer. And I mean very simple, basically allow to run a function in an
alternate thread, maybe provide a simple mutex. That should allow to do
anything you would want to abuse timers for (e.g. streaming music from
the background). For more advanced threading needs, you still should use
pthreads or something else. And timers would stay what they are,
callbacks which may get called at any time, and where you can only
change a variable. Actually, you could easily simulate the current
timers with such a threads API, al_current_time, and rest - so maybe we
wouldn't need it anymore at all except in the compatibility layer.

> As well, there's problems making a single thread having to keep track of all 
> the timers which can have different speeds. This is either handled by 
> sleeping at the lowest-common-multiple and checking each function upon wakeup 
> which would cause it to recheck needlessly often when using two speeds that 
> don't cleanly divide, or by dynamically calculating the time until the next 
> interrupt would occur (current implementation, I believe) which causes more 
> delayed jitter which is expounded by the sleeping function's inherent 
> innacuracy.

We should somewhere add a test of the timer accuracy. Judging only from
how exmidi sounds, in Linux they are far less accurate than in Windows
(i.e. under Linux, i can hear how notes aren't played exactly at the
right time, in Windows it sounds perfect.. may also have to do with the
alsa driver though I guess).

-- 
Elias Pschernig