Hi Mike,
Let me share my observations with Windows Remote Desktop (RDP).
When you use Windows RDP in and out to a remote station, the remote station
will reconfigure all its audio devices each time the connection is opened or
closed.
And this independently whether you bring the remote audio to the local PC or
not. That is a known Windows 10 problem (google : windows 10 rdp loses
remote audio).
So any hiccup in the internet connection will result in a remote
reconfiguration of the remote audio devices.
My solution was to abandon Windows RDP and use Teamviewer. With Teamviewer
you can happily RDP in and out without affecting the decoding. Remote
decoding was not affected and it works for a Raspberry Pi remote client as
well as a Windows Teamviewer remote client.
Hope this helps your particular case.
73's Erik
ON4PB.
--------------------------------------------------------------------
Message: 1
Date: Mon, 4 Mar 2019 20:32:52 +0000
From: Mike Lewis <k7...@hotmail.com>
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] Busy CPU
Message-ID:
<bn6pr03mb3315b8624836dd2dcb631202f6...@bn6pr03mb3315.namprd03.prod.outlook.
com>
Content-Type: text/plain; charset="utf-8"
Decodes do fail if the reads for the audio buffers are delayed too long and
unfortunately there is no easy way to spot this. A debug version with audio
buffer timings displayed was used to diagnose my oddball case ultimately
tracked down to the Windows advanced power option for the Display Timeout,
had to set it to Never.
Another case is if audio is briefly interrupted, the decoding and waterfall
stop, Monitor button remains green and the clock remains operational. A
change to the audio in settings or restart of WSJT-X is required to get
things rolling again. This is highly repeatable if you RDP in, start
decoding, drop the session (even quickly as an internet interruption for 1
second) and come back to see the results. Decoding will have stopped.
In the cases above decoding either stopped or cycles missed. It would be
very helpful to put up a warning flag for these events. A display or log
file message and/or Monitor button turned red or orange. A further step
would be to attempt some self-healing such as buffer reinit after failure is
detected. A use case: I run WSJT-X remote much of the time, mostly
monitoring in WSPR or FT8 with spotting at a remote site. I have to keep the
RDP session active all the time, and cannot tolerate any internet hiccups,
so cannot monitor through the nights reliably.
73,
Mike
K7MDL
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
