On Monday (12/30/2019 at 09:11PM +0000), Bill Somerville wrote: > 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.
Does WSJT-X receive a Windows "event" when the screen blanks? Does it have code that handles that event? Is it possible that that event handler is mistakenly changing the audio output device? Or inadvertently selecting the default device by not properly choosing the one listed in the settings? It would seem that people who set their default audio device to their radio interface would not experience this problem since WSJT-X is switching to the default audio device on screen blank. If that is already your radio interface then you don't experience a problem. In my case, the default audio device is the line out jack on the back of the computer (connected to a pair of desktop speakers) and the radio audio source is the USB microHAM interface. So the change on screen blank results in WSJT-X screaming into the room through the speakers while keying the radio with silence going into the transmitter. > 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? I have not as all the ports are equivalent in this box. There is just one root hub and front and back jacks are all on that same one. Testing with the old stand-alone WSPR.EXE shows no "hickup" or loss of audio stream when the screen blanks. I have listened to my transmit signal at the very moment the screen blanks and it is as pure of a tone as it is before or after. So whatever thing is temporarily disabling the selected audio sink only happens to WSJT-X and not WSPR.EXE. Additionally, after the system has been unblanked, WSJT-X continues to send audio out the wrong interface. It's not like the system state returning to unblank fixes things. Even disabling and re-enabling Tx within WSJT-X does not fix it. WSJT-X continues to use the wrong audio output device until the program is killed and restarted. That suggests to me that the state deciding which audio device to use is in WSJT-X (or associated libraries) and not the underlying Windows system. I'd be tempted to believe that if WSJT-X proactively selected the audio output device each time just before it transmits, this problem might go away. I'm tempted to believe that it is selecting the audio output device only once early in start up and then doesn't select it anymore. Something during screen blank reverts it to default and it doesn't get set back to the correct one again until the program is restarted. I'm not suggesting this is a WSJT-X bug per se-- but an artifact of how the underlying sound libraries work and this extra step is needed to keep it talking out the correct audio device. But that's just a theory. I'm a Linux guy not a Windows guy :-) I guess I will need to find a way to prevent screen blanking from occuring when WSJT-X (and any associated DLLs) are active. I no longer think this is a USB power management problem. It is something else not properly handling the screen blanking event and this is changing the audio device inappropriately. Thank you for your debugging assistance though. I appreciate it. 73, Chris -- Chris Elmquist _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
