search

lwvmobile / dsd-fme

Digital Speech Decoder - Florida Man Edition
Other
162 stars 31 forks source link

[tcp] Restart network connection after disconnect? #119

Closed rlex closed 1 year ago

rlex commented 1 year ago

Hello! Just started using DSD-FME. I noticed that after you connect TCP (i use SDRAngel) and DSD, in case of connection timeouts or goes down (ie i switched something in SDRAngel that took several seconds to apply) DSD-FME falls back to pulseaudio input. I wonder if it's possible keep checking for connection instead of going to menu and restarting TCP (or restarting DSD-FME).

lwvmobile commented 1 year ago

Currently, there is no connection retry in DSD-FME, so once it detects the connection is dropped, it switches to pulse audio input (which was a quick way to keep FME from crashing when the connection dropped when the user quit or closed the network sink, etc)

Actually, I haven't tried out SDRAngel in quite a long time, never could get a feel for using it. I wasn't aware that it had a TCP audio sink. I may have to go and try it out again.

Anyways, I'll look into it sometime and see if I can implement some sort of retry feature, or at the very least, add a keyboard shortcut to let you attempt to reconnect to it without having to close out and/or open the menu and navigate to it.

lwvmobile commented 1 year ago

Okay, so what I've done, is if DSD-FME detects that the TCP audio sink server connection has been disconnected, then it will sleep 3 seconds, and then reattempt to open the connection with the same parameters it had previously opened it with on start up. If it fails at that point, it will revert to pulse audio input (if it is available) or just simply exit (Aero if using OSS).

Also, I've added a keyboard shortcut (numberal 8) to the ncurses terminal that will either do an initial connection with all default values (localhost:7355) or let the user do a reattempt manually AFTER the initial failure using the parameters supplied by the user at start up or in the menu.

To test both additions, I simply had an active connection to SDR++, and simulated the drop by stopping the TCP network sink inside of SDR++, waited a second, and then turned it back on. DSD-FME was able to reconnect without issue. I also tested the 8 key inside of ncurses terminal to make it both initially connect with default values to a TCP Audio Sink, and also to have it retry the connection after initial connection, turning the sink off inside of SDR++, and then making it wait past the retry before connecting it again.

I hope this is helpful for your case, but if SDRAngel is constantly dropping the connection (I'm unclear on if that is what is happening, or if this is you changing parameters and stopping and restarting, etc) but if the connection with SDRAngel isn't stable locally and randomly disconnecting, may be an issue somewhere else. Its pretty rock solid when using SDR++ as long as the TCP Sink is left alone.

lwvmobile commented 1 year ago

In the next batch of commits, I'm also going to add a keyboard shortcut '9' to allow a connection to the default RIGCTL settings for SDR++ (localhost:4532), I figure, if we have one for TCP Audio, and one for trunking, we might as well make it a 3 key combo to go from initial startup with all defaults to potentially trunking something. ala, 8-9-t combo.

lwvmobile commented 1 year ago

Well, I haven't heard anything back, and my own testing shows the code in place now will work okay with simple disconnects and reconnects, so I am going to go ahead and close this issue as completed. If you have any other questions, concerns, issues, etc, always feel free to continue on this issue, re-open, or create a new one.

rlex commented 1 year ago

Sorry, was AFK for a bit. Changes seems good and look like they will partially solve the issue. Maybe make timeout configurable via arguments as well?