1. Occasionally it seems as though the RSP2 simply stops and the waterfall becomes solid vertical stripes as though the something was repeating the last received sample indefinitely. I have seen this locally AND remotely via RDP. It does not happen often but it does happen. It never seems to occur spontaneously.... just simultaneously with some other SDRUno action.
2. Often, and usually only once per session, RDP and SDRUno will simply freeze. Usually RDP will report that it has lost connection. When it auto connects again, SDRUno reports queuing errors that can be dismissed with multiple clicks on OK. However, this often results in SDRUno no longer being able to communicate with the RSP2. The only way to restore operation is to either unplug and re-plug the RSP2 or reboot. This does occur spontaneously, without any user input.
3. Often, the text in the memory panel box becomes black instead of the usual yellow. This makes it VERY hard to read This issue seems to be confined to connections over RDP..... I don't recall seeing this one locally.
Since my preferred use is RDP from laptop to host PC, I would like to find a solution to these issues. SDRUno is an otherwise superb product. I initially thought this might be a networking issue (and it still may be). When I switched from the stock Netgear router firmware to OpenWRT, the issues did seem to get better. But they never went completely away. It is easy to blame RDP but I use RDP a LOT (including other SDR software) and SDRUno is the only program that has an issue with it.
I'm looking for other user's input and/or input from the SDRUno programmers.
Reason: No reason
I connect to the host PC from my laptop via remote desktop. As I detailed in my OP, some of the issues occur both locally and via RDP and others only (or more often) when using RDP. There clearly is some sort of interaction with RDP and network traffic but it is not responsible for all of it.
I have tried changing router firmware from stock to OpenWRT plus playing around with QOS settings. Simply switching to OpenWRT helped a lot but did not eliminate all issues. I am in the process of trying to figure out how to prioritize traffic to/from a specific MAC (in this case, the host PC) but have not found how to do that yet. I also need to try running hardwired end to end and see if I get fewer freezes.
In the mean time, if this IS at least partly a networking issue, SDRUno does not fail at all gracefully when / if a packet gets dropped or delayed. By comparison, SDR-Console is totally unaffected by network issues in identical use cases (ie., using RDP) other than occasionally dropping a packet or two with a resulting pause in the waterfall and audio dropout.
Reason: No reason
Yesterday I discovered that I had checked the LOCK FRACTIONAL RESAMPLER option some time ago when I was trying to get DMR to decode. I thought that the lock resampler option self-cancelled when the program was closed but I found it still checked so I guess not. I un-checked it and at least so far, all the RDP related instabilities have gone away. The audio still develops more and more latency as time goes on but at least the program remains as stable over RDP as it is locally. Too bad the threshold where SDRUno clears the resample buffer is not adjustable..... the latency can grow to a second or more, making tuning a little difficult. It would be nice if a maximum latency threshold could be set where SDRUno flushed the buffer.
Reason: No reason