[hpsdr] Fwd: Re: Audio distortions during zoom/pan panadapter

[Roger Rehr W3SZ]

QSL on all, George!

The result is what we both expected.  I just couldn't test it here on 
Windows 10 given that DPC Checker won't run on W10.

The ClockRes.exe program to which you refer tells you the "set" value of 
the timer interval, and the program I recommended shows you what timing 
is actually produced for various arguments of the sleep function, in 1 
msec increments.  You get 70 data points for what actually happens from 
0-69 msec with that program.

So your suggestion is really consistent with what I recommended, just 
using a different program to do the test, one that tells you what the 
timer is set to, rather than showing what timing actually results from 
the setting.  Both approaches are valid, and perhaps complementary if 
one of them gives results that seem to be anomalous.  I myself prefer to 
see the larger "result" dataset given with skedgran rather than the 
single "settings" datapoint given by ClockRes.

As for the cure, back in 2007 I just fixed the problem in the manner 
outlined on the webpage I wrote and referred to in the previous email, 
by explicitly setting the timer resolution using timeBeginPeriod() at 
the beginning of the affected code and then resetting it to default at 
termination using timeEndPeriod().  An example where this is done is is 
given in the stackoverflow link you provided.

If you need a granularity of less than 1 msec, then another approach is 
needed, as was also outlined in the stackoverflow link.  
NtSetTimerResolution() is useful in that case, and 
NtQueryTimerResolution() reports the supported resolutions available 
with that command.

Note that the timer granularity affects far more than just "sleep" 
commands.  Sleep commands are an easy way to check the timer 
granularity, but the granularity affects the timing of multimedia 
applications independent of whether or not those applications use the 
sleep command.  So I don't think that it is correct to say that there 
are necessarily "sleep" commands in the code that are causing this 
behavior.  I suspect that sleep statements are not the problem here.

What needs to be done to fix this is likely along the lines of what I 
recommended above and on my old 2007 web page, to set the timer 
resolution explicitly for the code that is being affected by the changes 
in the timer granularity.

73,

Roger Rehr
W3SZ

On 12/9/2015 1:59 PM, ghbyrkit at chartermi.net wrote:
>
> I did a little more digging.  SysInternals has a tool that shows the 
> timer resolution.  It's called ClockRes.exe, and is available at the URL:
>
> https://technet.microsoft.com/en-us/sysinternals/bb897568.aspx
>
>
> You could run it without having the DPC checker running, then run the 
> DPC checker and run again, and note/report any differences.  It's also 
> possible that running the Media Player would get a similar result.
>
> The SysInternals page says that there is a fine document discussing 
> how to change the system timer resolution at:
>
> https://technet.microsoft.com/en-us/sysinternals/bb897569, but that 
> link doesn't seem to go anywhere useful.
>
>
> StackOverflow has some info at: 
> http://stackoverflow.com/questions/3744032/why-are-net-timers-limited-to-15-ms-resolution
>
>
> There is possibly other information on the NT Kernel functions 
> NtSetTimerResolution and NtQueryTimerResolution that a program could 
> use to get better resolution, if that makes things work better.
>
>
> 73,
>
> George K9TRV
>