On 30/12/2019 21:03, Chris Elmquist wrote:
Actually, I was referring to the difference between WSJT-X (running in WSPR
mode) vs. the old stand-alone WSPR app (v2.12). As I noted, the stand-alone
WSPR app does not exhibit the problem. It works fine when the screen blanks
and continues to transmit audio through the USB radio interface forever.
Keeping everything else constant but using WSJT-X (in WSPR mode) instead of
WSPR.EXE, results in the failure.
Hi Chris,
ok, my bad. The original WSPR application uses a different audio library
which uses a different Windows audio sub-system (there are several). The
way Windows handles stream failures is different for different audio
sub-systems, the one WSJT-X uses seems to make best effort to keep audio
going to a working destination, even if that means silently and
transparently switching to a different audio sink. WSJT-X is given no
indication that the actual device rendering the audio has changed.
Bottom line is that something is temporarily disabling the selected
audio sink, until you can stop that happening the problem will persist.
Have you tried plugging your microHAM USB III into a different USB hub
on your PC, case front vs. back for example?
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
