Re: [wsjt-devel] Audio dropouts confirmed and resolved

2019-01-30 Thread Bill Barrett
Hello Mike- Would be nice if there was an option to report exception situations in a separate window for immediate or later analysis. Bill W2PKY On Wed, Jan 30, 2019 at 12:02 AM Black Michael via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > I built a special version with some added

Re: [wsjt-devel] Audio dropouts confirmed and resolved

2019-01-29 Thread Black Michael via wsjt-devel
Here's a patch which adds audio debug to the Band Activity window.I would also add a patch to the Settings/Audio tab for a checkbox to enable this but since I don't have access to current source code it's a waste of my time to submit a patch for that.  Perhaps one of the team with code access

Re: [wsjt-devel] Audio dropouts confirmed and resolved

2019-01-29 Thread Black Michael via wsjt-devel
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

Re: [wsjt-devel] Audio dropouts confirmed and resolved

2019-01-29 Thread Bill Barrett
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

Re: [wsjt-devel] Audio dropouts confirmed and resolved

2019-01-29 Thread Ryan Tourge
Good info! Thanks! I'm doing something similar and although It didn't affect WSJT-X it did cause issues with my loggin software trying to do lookups. On Tue, Jan 29, 2019 at 1:04 AM Mike Lewis wrote: > You have probably seen my earlier posts tracking down the cause of lost > decode cycles, or

[wsjt-devel] Audio dropouts confirmed and resolved

2019-01-28 Thread Mike Lewis
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