so ive been messing around with RemoteHams for about 3 months now and overall its pretty solid but theres this one thing thats been bugging me since day one. the audio sync is just slightly off when i use the SDR remote mode versus when im using the traditional rig control path. like maybe 200-300ms difference and it doesnt sound like much but when youre trying to copy CW at anything above 20wpm it becomes a real problem because your brain keeps trying to process it at the wrong rhythm.

my setup is a IC-7300 at the remote end running through a Raspberry Pi 4 with the RemoteHams server software, the internet link is a 25mbps upload connection which should be more than enough. ive tried tweaking the audio buffer settings in the client and gone up and down from 50ms to 200ms and nothing really fixes it, the SDR waterfall and the audio just seem to want to live in different universes.

anybody else run into this or is it something specific to the 7300 and how the server handles the IQ data versus the regular audio stream? wondering if im better off just ditching the SDR mode entirely and going back to straight audio for the CW stuff at least

yeah the SDR mode in RemoteHams has always had that lag issue in my experience, its pulling IQ data and rendering it on the client side which adds processing overhead that the normal audio path doesnt have. i actually gave up on it for anything time-sensitive and just use the waterfall for a visual reference when im hunting for signals but do all my actual operating in standard mode. the 7300 direct audio through the server is pretty clean if you get the codec settings right, i use OPUS at 32kbps and it holds together pretty well even when my upstream gets congested.

the other thing worth checking is whether youre running the RemoteHams server on the Pi alongside anything else, i had mine also doing some echolink linking stuff and the CPU contention was making everything worse than it needed to be. split it onto a dedicated Pi and things got noticeably better

not a RemoteHams user specifically but ive done a lot of remote station work over the years and the SDR waterfall sync thing is basically a known tradeoff with any system that handles the display pipeline separately from the audio. the data is going through different processing chains and unless the software explicitly timestamps and syncs them theyre going to drift relative to each other. some of the commercial systems like WebSDR deal with this by just adding artificial delay to the audio side to match the display latency but that has its own problems.

for CW work remotely ive honestly had the best luck with systems that dont try to do SDR display at all and just give me clean low latency audio, the waterfall is nice eye candy but when youre actually in a pileup or trying to copy weak DX you mostly stop looking at it anyway