Mike, you might see what you can turn up using this tool. It goes way beyond the basic windows power management:
https://www.techpowerup.com/download/techpowerup-throttlestop/ Start out by using it in a monitor-only mode, and get a feel for the C-state levels when you are successfully decoding vs failing. Then play with the performance level controls in the tool to see if you can coax the system into working decodes while it is otherwise idle. It feels like your system is either dropping into deeper C-states when it shouldn't (causing realtime latency that drops samples), or there's a driver bug that can't handle the C-state transitions properly, even when they would otherwise be safe. In either case, artificially forcing less C-states by using this tool may get you back to working. The cost is a small increase in power consumption of the CPU. It's also sometimes possible to change BIOS settings to limit package C-states; another way to resolve high latency issues at idle. This app is a bit less invasive than BIOS changes though, and will give better realtime feedback. -- Brian AF7MD On Sat, Jan 12, 2019 at 4:49 PM Mike Lewis <k7...@hotmail.com> wrote: > Hi Bill, > > > > Tried check/unchecking them, no change. Uninstalled all 3 audio device > drivers, rebooted, tested, updated 1 of the drivers, tested, no change. > Running more tests today, quite a few last night. Does not have to be an > audio program running to make things decode again, just need CPU load it > seems now. Started with audio programs by chance, but moved on to other > programs like weather and speedtest and solitaire apps to get the CPU over > 10%. > > > > - Mike K7MDL > > > > *From:* Bill Somerville <g4...@classdesign.com> > *Sent:* Saturday, January 12, 2019 05:31 > *To:* wsjt-devel@lists.sourceforge.net > *Subject:* Re: [wsjt-devel] Odd Decoding Problem on new Core i5-8250 > Laptop - Only decodes perfect when running HDSDR in parallel > > > > On 12/01/2019 06:36, Black Michael via wsjt-devel wrote: > > I had a test session with one user who can easily reproduce the audio > dropouts. Latency testing shows his system more than capable of handling > realtime audio. > > I got some timings from the dataSink. > > The Good plot is a normal/good decode. One high time period is corrected > on the next iteration. > > The plots show the time intervals between calls to dataSink. > > > > The Bad plot is when decoding has stopped. the n_ihsym never gets to 50 > to satisfy the n_ihsym requirement > > > > if(m_ihsym == m_hsymStop) { > > > > Starting another program (most any one) will cause decoding to stop. Having > another audio program start will cause decoding to start succeeding again. > So the audio gets stalled periodically and sticks there until something > tickles it. > > > > de Mike W9MDB > > > > Hi Mike, > > did you check the recording device advanced properties? Was the default > sample rate set to 48000 Hz and did unchecking either or both of the > "Exclusive Mode" options help? > > 73 > Bill > G4WJS. > _______________________________________________ > 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