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

[Mickael Pointier]

>> We could define our own "FineSleep" function and uses the best possible
>> alternatives depending on the OS / compilation flags (1st nanosleep,
>> then SDL_Delay, active wait on SDL_GetTicks, etc.).
>>
>> I think it would fix the VBL precision problem with very few changes to
>> Hatari. Any opinion on this ?
> I think it's more robust to have code that adapts to unprecise timings.
>
> Hatari sound behaving erratically when any program runs on background
> and on platforms which don't have submillisecond accuracy is not really
> good.
>
>
> 	- Eero
>

The two issues are not incompatible.
It's good to make robust code that adapts to inaccurate timing, but it 
does not hurt to use really accurate timers when doing multimedia kind 
of applications. The two points to consider are of course the frequency 
of the timer, but also the granularity, and the cost of the timer call.

For some reason many people assume that because they have a millisecond 
timer they have actual millisecond accuracy. Well, that's not always the 
case.

On some systems when you do a large loop that stored in memory the 
millisecond timer values in an array, you will find out that you get 
things like 0,0,0,0,0,1,1,1,1,1,2,2,2,2,2,3,3,3,3,3 (which is fine) but 
on some other machines you will have instead 
0,0,0,0,0,0,0,0,0,0,2,2,2,2,2,2,2,2,2,2, .... some values are missing.

On Windows I tend to use QueryPerformanceCounter / 
QueryPerformanceFrequency, not only because it has a higher frequency 
than the standard millisecond timer, but also because it has a way lower 
granularity: You are guaranteed that if you call QueryperformanceCounter 
twice in a row, you get two different values, which is nice for 
profiling or measuring very short events.

Not sure for other systems.

     Dbug