SmartSDR not playing nice with WSJT-x 2.1??

Joseph

I upgraded WSJT-x to v2.1 today and periodically the whole setup hangs. 
What I mean by hangs is that I can see audio levels on WSJT just fine, SmartSDR seems to be acting normally, but decodes cease and desist.  When it does this, the Band Activity window (WSJT) stutters up about 1/2 line and output stops until I restart BOTH SmartSDR and WSJT-X.  Restarting either one by itself will not make the problem go away.  I don't have a good case for saying this, but it has not yet happened in FT4 mode, just FT8.  Does this ring a bell with anyone???  Radio is a 6600M.  SmartSDR  and radio software up to date.

Mike Blake

I just loaded WSJT-X 2.1 and it is working fine with SmartSDR on my 6600M

Mike-VA3MW

I agree with Mike.  I upgraded and it was fine.

Make sure you check your Audio selection in WSJT and make sure it is what you expect it to be.

Mike

Wayne VK4ACN

Ive been running 2 copies of the new version for the last 4 hours, so far no problems

Roger_W6VZV

WSJT-X 2.1 running fine on my system.  Only problem is lousy band condx.

Johan _ SE3X

WSJT-X 2.1 running fine on my 6700. Been running WSJT-X v2.0.1 since it came out. Using SSDR V3.0.27.

Buddy Spiegel

when wsjt-x stops decoding  … try closing only DAX and then reopening it.  that works for me and only takes 15 seconds.

Joseph

Update: turns out that the rc7 version also exhibits the same behavior.  I had not noticed that before.  I can't see any pattern in the decodes when it hangs.  But I have learned that I can wake it up by enabling a transmission, even if I halt it before it is finished.  Stay tuned.  I will try the DAX restart next.

Cal N3CAL

Just curious what radio do you have selected under the WSJT-x setup? 

Cal/N3CAL

Randy

I have the same problem.  Stopping and restarting DAX usually fixes the problem.  Occasionally the radio freezes and I have to hold the power button down for several seconds to get it to shutdown.  The problem seems to be getting progressively worse.  I am running rc7.

K3SF

FYI


checkout wsjtx io groups

they have reported similar problems of decoding issues

https://groups.io/g/WSJTX/topic/32439146#3578

seems
to be a pc audio issue and /or cpu heat issue as more processing load is occurring. Intel Cpu will slow down to prevent overheating and decodes stops and/or audio begins to stutter.

even though waterfall shows everything looks OK...


this is both 2.1 GA as well as RC7

Paul K3SF

Joseph

Flex 6xxxx

Joseph

Restarting the DAX control does also restart decoding (Thanks Randy).  Wrt other comments: clock is good (GPS based), I haven't heard the desktop computer fan increase speed (but will pay more attention to that), and I haven't ever seen the radio freeze (not even sure how to see that since I am running SmartSDR, but I NEVER have to reset or mess with it...stays on 24/7 for weeks at a time).

Since this is sounding more like a WSJTX problem, I will add a post over there (see above).

Cal N3CAL

I haven't seen this issue yet but my radio selection in WSJT-x setup has always been Kenwood TS480 instead of the Flex 6xxxx.  Might be worth a try to change it? 

In previous years there were issues with selecting Flex 6xxx with WSJT-x.  That's why the Kenwood selection has always worked fine for me. No freezing.

Cal/N3CAL

Cal N3CAL

It's also worth noting there has been improved UDP messaging for inter-program communication which could somehow play a role in this? 

Cal/N3CAL

Joseph

FYI, upgrading to Windows build 1903 (from 1803) has no impact.  I am now having to restart DAX every 10-15 minutes of operating time to get the decoding to continue.  In all of the upgrading/uninstalling/installing, Windows has corrupted the DAX driver names (predictable, there is a post on this, and a fix) so I also have a DAX Driver Error error message every time I restart DAX, but it works for at least slices A and B.

Joseph

So, with some help from Flex all the DAX naming issues are fixed.  Still have the WSJT-X decoding issue remaining.  Wouldn't it be nice if WSJT and Flex got together and figured out what is going on here??  Lots of people seem to have the same problem.

Joseph

Flex is taking the position that this is MY problem because MY computer is causing the problem.  Maybe, but I am evidently not the only one with this problem!  Not arguing that this problem may have been there ever since I fired up SSDR, but it is on a relatively new reasonably powered machine.  I am going to open a tag on it but I am not optimistic that it will generate the desired response.  I urge anyone with this program (WSJT-X stopping decode, reqiring a DAX restart to continue) to open a ticket on it.  Maybe at least they will get a handle on what is going on.  Best of luck to everyone I have heard from!

Joseph

(This is a repost of a note on the WSJTX group, more or less.)

Found it!  I think!!  Knock on wood.  It wasn't the NVidia driver or the NDIS drivers.  Not much you can do about those anyway.  It turns out that when I was dutifully updating all the drivers that I could find an update for, Dell evidently added some new "helpful" software when I updated the BIOS.  I found a reference to this problem kind of inadvertently when searching yet again for DPC latency issues.  I opened Programs and Features in the control panel, uninstalled every applications that had Dell in the name, rebooted, and I have been running without a DAX/WSJT-X hangup for more than two days.  Like I said, knock on wood!!  I guess I don't have Dell Customer Support real-time anything, but I don't think I had it before the BIOS update.  I've never used it at least.

For those of you that have this problem (WSJT-X decode stopping until DAX is restarted), I strongly recommend you run LatencyMon and get a look at what is happening in your system.  I think it is okay for some ISRs to have high execution times, so long as they don't get in the way of DAX.  For instance, over the over two days LM shows that dxgkrnl.sys (DirectX graphics kernel) has a max ISR execution time of 381microseconds and ACPI.sys (does something with plug and play) has a highest reported DPC routine execution time of 27 milliseconds!  Apparently no harm no foul.  (This event may have been recorded before I started SSDR and WSJT-X.) The latter is the only one with a time over a millisecond.

I still say that the software could be more robust in the face of a poorly engineered software that it has to coexist with.  But I am at least running more or less normally.  Caveat: I have spent the last week chasing down a ridiculous number of suggestions gleaned from the web.  Turns out serious audio heads and gamers are on a mission to keep DPC latency at a minimum and have a lot of experience tackling related issues.  BUT...I have changed so many things that I cannot say for certain that there wasn't more than just the removal of the Dell applications that helped fix the issue.  Fact remains that WSJT-X was still hanging up (every 20-30 minutes if I was active) before the Dell software uninstalls.

It was, in fact, my problem and I found my solution.