I just got some interesting results on this problem. Still working with Mike W9MDB on various investigations and debugging, we are thinking there is a timing issue unique to this 8th Gen CPU and chipset or driver bug, resulting in dropped audio bits someplace, but I thought this is worth sharing now. I would also like to give a BIG thank you to Mike for help investigating this problem with me, it is taking some serious hours.
The no decode at low CPU issue I am having is highly repeatable. I verified it works in at least one other mode than FT8 , WSPR. With FT8 it is easy to find lots of stations to decode, less so on other bands when I need them, but WSPR usually always has something to decode, just takes a long time to test. I then wondered if this issue shows up in older versions. No stations left to decode using an older version of WSJT but there are WSPR stations that are easy to find and decode. So in the last hour or 2 I installed and ran 3 WSPR capable decoding programs (WSJT-X 1.9.1, WSJT-X 2.0, and WSPR 2.12) on the new laptop in question, and ran WSJT-X 2.0 on an old laptop I am running in parallel from the same radio line-out source (my reference system). All 3 programs on the new laptop are on the same audio input source. So those 3 should give identical results, at least to the limits of their version’s sensitivity. Results: WSJT-X 1.9.1 and 2.0 on the new laptop fail to decode complete cycles when the CPU <10%. I used a speed test program to push up the CPU usage to 16% to get the good decodes. The old laptop on WSJT-X 2.0 decoded fine as always for all cycles, and the old WSPR2.12 decode all cycles good also, matching the old laptop results. So I can recreate the fail to decode issue by simply running any program (weather, speed, music, HDSDR, Solitaire) that pushes up my CPU utilization above 10% or so. If I turn off N1MM+ I can get reliable decodes most of the time at 6-7% CPU. We are currently looking at various things, running various tools and attempting to make sense of this, but I found it most interesting that WSPR2.12 works on the same host when the newer version do not, suggesting to me that a library change likely happened along the way to make WSJT-X more sensitive to dropped audio bits. I have some other older versions that I could try also and see when it might have changed by experimentation. Maybe the old versions did not watch for dropped audio bits as close, don’t know yet. * Mike K7MDL From: Mike Lewis <k7...@hotmail.com> Sent: Saturday, January 12, 2019 11:45 To: WSJT software development <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 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<mailto:g4...@classdesign.com>> Sent: Saturday, January 12, 2019 05:31 To: wsjt-devel@lists.sourceforge.net<mailto: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
