I built a special version with some added debug to make seeing the dropouts 
easier and observe the behavior.  Might be useful to include this in WSJT-X as 
a checkbox in the Audio tab.
We determined the audio was buffering OK at startup...several fast events 
catching up on the audio buffer.  But then large delta times would occur 
without an associated fast interval to follow up indicating audio was dropping 
on the floor.
de Mike W9MDB 

    On Tuesday, January 29, 2019, 5:47:46 PM CST, Bill Barrett 
<w2pky...@gmail.com> wrote:  
 
 Hello MIke & Mike-
"Each sample from the audio buffer (50/per 15 seconds for FT8) should take 
roughly 280uS.  I start seeing several samples in each group of 50 take between 
400-700uS.  As a result not all 50 required audio samples are collected in the 
time allowed and the period is skipped and the .WAV file (if turned on) is not 
written out.  If you turn on Save ALL and you see missing .WAV files in the 
directory, this is another symptom. "

Interesting information; I would be interested in the debugging tool used to 
display the buffer timing.Thanks;Bill W2PKY
On Tue, Jan 29, 2019 at 12:58 AM Mike Lewis <k7...@hotmail.com> wrote:


You have probably seen my earlier posts tracking down the cause of lost decode 
cycles, or more often, decoding just completely stops on a new HP laptop when 
CPU utilization is < 10%.  Above that all is fine.  This is on a new 8th gen 
Core i5 8265U, Intel UHD620 GPU, 8GB RAM, 256GB SSD, and 1366x720 display.  USB 
audio and internal Realtek sound devices.  Laptop lid open or closed, no matter.

 

The final solution here was to set the Display timeout to Never. I normally 
only RDP to this machine and the lid is always closed, so the display would 
normally shut off for that reason. Never thought a timer setting would still 
matter, but it does.

 

After many long hours (over 5 weeks’ worth) of testing and experimenting with 
every setting and program combination you could imagine, debug builds, changing 
C states, latency analysis, I noticed a loose correlation with decoding usually 
working the first several minutes after a reboot before coming to an end and a 
display setting.  The “Turn Off Display after XX minutes” option in the 
Advanced Power Options menu. I am thinking that the display (and external 
graphics HDMI connector) is always forced on after a reboot, or attempts to at 
least.  Setting it to “Never” did the trick after a reboot.  To repro the 
failure, turn it to 10 minutes and wait, decoding will start seeing audio 
delays.  No reboot required to force the failure.

 

Each sample from the audio buffer (50/per 15 seconds for FT8) should take 
roughly 280uS.  I start seeing several samples in each group of 50 take between 
400-700uS.  As a result not all 50 required audio samples are collected in the 
time allowed and the period is skipped and the .WAV file (if turned on) is not 
written out.  If you turn on Save ALL and you see missing .WAV files in the 
directory, this is another symptom.

 

LatencyMon will show all is good.  Changing C states and Turbo Boost and any 
available such tweaks had no effect.  Slide a random window around with the 
mouse fast for 10- 15 seconds to raise CPU above 10% for a decode period, or 
simply run any program that eats enough CPU cycles to get above 10%, all is 
good.  I had resorted to running a Speedtest modern app and just letting it sit 
open on the desktop, tucked out of the way.  Minimizing it dropped the CPU% too 
much.  Its animated GO button was just enough to get me to 12%.

 

I tried to repro this on a similar model HP laptop but with a Core i3 and 1080p 
display, otherwise same packaging, 4GB  RAM and 128GB SSD, same Intel UHD620 
GPU but it worked fine below 10%.  Looked at its setting and it was 10 minutes, 
so this issue seems to be very particular.

 

Here is the Advanced Power Options screen snapshot:



 

I would like to thank Mike W9MDB for his many hours of assistance during this 
exercise, we now have the means/knowledge to easily spot such effects.  
Understanding the reason for them is still an art and likely case by case.

 
   
   - Mike K7MDL

 

 

 
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to