so ive been messing with RemoteHams for the past few weeks trying to get my remote station dialed in and honestly its been a mixed bag. the actual SDR side of things is pretty solid once you get the RCForb client configured right, but the latency on transmit control is driving me nuts. im running about 180ms round trip to the shack which should be manageable but there's this weird additional delay that happens specifically when i key up through the internet link and i cant figure out if its the software adding buffer or if its something on my router at the remote end.

the setup is a K3 at the remote end with a rigctld interface feeding into the RemoteHams server software, and i have a small SDR dongle running alongside for the audio path which i know is a bit redundant but i wanted flexibility. the audio latency is actually fine, its just the PTT that feels sluggish and its making phone operation feel really awkward. like im stepping on people without meaning to because i release the key and theres this tail that just hangs there.

has anyone run a similar hybrid setup or know if there's a configuration knob somewhere i missed that controls the PTT release timing specifically? ive gone through the docs and either im blind or its not in there

the PTT tail thing is a known annoyance with RCForb and a lot of people just live with it or switch to CW/digital where it doesnt matter as much. but there is actually a VOX tail setting buried in the server config on the remote end, not the client side, which i think trips people up. if you look in the server settings under audio there should be something like a hang time or tail delay value. default is usually way too conservative because they set it for bad internet connections.

also 180ms is on the edge for comfortable phone work in my experience. i have a similar setup to a mountain top site and i found anything over 150ms starts feeling wrong on phone even if technically the audio is fine. the brain just gets confused. for what its worth i ended up using a separate cheap VPS to relay the control data and shaved about 30ms off which actually made a noticeable difference. might be worth looking at where your routing is going geographically because sometimes the path is just dumb and adding hops locally is counterintuitive but faster

yeah i ran into something similar when i was linking my station through echolink for voice and trying to do remote control at the same time, total mess trying to get the timing right across two different latency paths. ended up just separating the functions entirely. not exactly the same as what your doing but the PTT tail issue sounds like what happens when the VOX in the audio chain and the actual PTT signal arent synchronized properly. does your rigctld setup have any keying delay configured? some rigs add a small settling delay before actually dropping carrier and if that isnt accounted for in the software side it stacks up weird