[hatari-devel] Higher precision when generating samples -> use nanosleep

[Nicolas Pomarède]

Le 26/01/2011 22:32, Eero Tamminen a écrit :
>> If possible and nanosleep is ok on a machine, it will be better to
>> alternate between 16.66 ms and 16.67 to emulate a 16.66666... ms delay
>> (60 Hz), than to alternate between 16 ms and 17 ms to also emulate
>> 16.6666 ms delay.
>
> Well, any process/thread (like X server, composite manager, SDL sound thread
> etc. doing what Hatari asks them to do) will probably take at least 1ms of
> time.  And then there's the monitor sync to consider...
>
> While using nanosleep() isn't much extra CMake&  C-code, I don't think it's
> going to help at all with the US TOS sound delay.  That delay is in several
> hundreds of ms, SDL having "just" 1ms accuracy cannot be a cause for that.
>

I think sthg iw wrong in what you wrote ; the sound delay problem as 
first reported by David is not about the delay suddenly jumping to 
several hundreds of ms, it's about about SDL sleeping for 16 ms instead 
of 16.66666 ms (4% error), which VBL after VBL slowly accumulates and 
gives a growing delay (until the ring buffer "loops" and delay goes to 0 
and grows again).

So yes, it's completly about a 1ms accuracy problem, even a 0.666 ms 
problem :)  If we were able to do sub-ms sleep, we could do a faster 
convergence toward the correct 16.6666 ms delay.

Even with absolutly no other process running that Hatari, SDL_Delay at 
1ms level will diverge if used without a self adaptation mechanism.


> The mentioned standard POSIX functions use highest available HW
> accuracy when kernel has been configured with high resolution timers
> support.  About everything should have it nowadays:
> $ grep -e cpu -e clock -e resolution /proc/timer_list
> cpu: 0
>   clock 0:
>    .resolution: 1 nsecs
>   clock 1:
>    .resolution: 1 nsecs
> cpu: 1
>   clock 0:
>    .resolution: 1 nsecs
>   clock 1:
>    .resolution: 1 nsecs
> cpu: 2
>   clock 0:
>    .resolution: 1 nsecs
>   clock 1:
>    .resolution: 1 nsecs
> cpu: 3
>   clock 0:
>    .resolution: 1 nsecs
>   clock 1:
>    .resolution: 1 nsecs
>
>
> That's not much help for non-realtime process though when there are other
> processes running in the system.

Of course, that's not as perfect as a real interrupt that would 
immediatly calls Video_InterruptHandler_VBL every 50 or 60 fps with no 
latency, but still the smaller error margin we have when sleeping (nano 
instead of milli), the better approximation/correction we will get in 
Main_WaitOnVbl()  (because chances are rather high that if the user 
doesn't run anything than Hatari, nanosleep will quite often be able to 
do 16.67 ms precisely ; if more processes are running, results will be 
less stable, but it can't be worse that what we have with ms-sleep)



Nicolas