so ive been running my home station remotely for about a year now using a pretty janky combination of a raspberry pi, some port forwarding, and teamviewer for the screen and it works but its kind of a mess honestly. audio latency is all over the place and half the time my XYL accidentally closes the laptop and kills my session mid-QSO which is fun.

anyway a buddy of mine at the club keeps pushing me toward RemoteHams and specifically the SDR remote stuff they have going. i played with it briefly at his shack and it seemed solid but i honestly couldnt tell if the latency i was hearing was the setup or just his internet. hes on some kind of rural DSL which doesnt help. my home connection is fiber so im thinking that part would at least be better on my end.

main thing im trying to figure out is whether the RemoteHams client handles the audio compression in a way that doesnt murder weak signal work. im mostly doing SSB and some digital, not really CW so the latency tolerance is a bit more forgiving than it could be. but ive read a few threads elsewhere saying the codec choices matter a lot and i dont fully understand all the options in the software. also curious if anyone has tied this into any kind of internet linking setup, like using it as a node or relay point for a repeater system. probably a whole other rabbit hole but the thought crossed my mind.

the audio codec thing is real and its worth spending some time in the settings rather than just leaving it at default. i went through probably three or four different configurations before i landed on something that felt acceptable for SSB. the higher bitrate options eat more bandwidth obviously but if youre on fiber you probably wont even notice. where people run into trouble is trying to run it over congested wifi or like you said rural DSL — that introduces jitter that no codec is really going to fix cleanly.

for weak signal stuff i havent tried it personally but i know a few guys who do FT8 remote and they say the digital modes are actually more forgiving than SSB because the software is doing the decoding locally anyway, so the audio just needs to be clean enough for WSJT-X or whatever to decode, doesnt need to sound great to your ears. SSB DX chasing with lots of QSB is where it gets annoying because youre fighting both the prop and the latency when trying to snag a split pile-up.

on the internet linking question, yeah thats kind of a separate thing. some guys run echolink or IRLP nodes through a remote station but RemoteHams isnt really designed with that in mind as far as i know. you could probably hack something together but id keep those two use cases separate unless you have a specific reason to combine them.

honestly teamviewer for audio is always going to be rough, that thing wasnt made for low latency audio at all. RemoteHams at least actually thinks about the RF control side of things not just screen sharing. i switched maybe two years ago and dont really look back. the rig control integration is what got me — being able to actually change the VFO and see the waterfall respond in something close to real time rather than waiting for a screen refresh felt like a completely different experience.

the XYL closing the laptop thing is a real problem lol, no software fixes that one