so ive been messing around with this for a few weeks now and i think im close but not quite there. the idea is pretty simple — use a pi zero w to control my ft-891 remotely over wifi, handle PTT via a gpio pin through a little transistor circuit i cobbled together, and pipe the audio both ways using a usb soundcard i had lying around. got rigctld running on the pi and can hit it from the shack computer no problem, PTT fires fine when i test it manually.

the problem is the audio latency is just... rough. like 400-600ms rough. ive tried messing with the alsa buffer settings and bumped the sample rate down to 8khz to ease the load but it still feels like im talking to someone on the moon. not sure if this is a pi zero limitation (probably is, single core after all) or if im doing something dumb in the audio routing. using mumble as the audio transport btw, seemed like the obvious choice.

anyone gone down this road? wondering if i should just bite the bullet and use a full pi 4 instead, or if theres some mumble config magic im missing. also open to completely different approaches if anyone has one.

yeah the zero is gonna hurt you here, its just not got the headroom for real-time audio processing plus running rigctld plus wifi all at once. i tried something similar last year and gave up on the zero pretty quick. moved to a pi 3b+ and the difference was night and day, latency dropped to under 150ms which is workable for casual use. still not great but you stop noticing it after a few minutes.

one thing that helped me a lot was switching away from mumble to just using darkice piping directly into icecast, then pulling the stream on the other end. sounds weird but the jitter buffering was more predictable. also make sure youre running the pi with a proper power supply, i had all kinds of weird audio glitches that turned out to be the crappy usb charger i was using causing voltage sag under load.

if you really want to stick with the zero, look into whether you can offload the audio to the client side more and just have the pi doing serial control. some guys just use a cheap android tablet as the audio endpoint and let the pi only handle CAT. not ideal but it works.

mumble jitter buffer is probably your enemy tbh. there's a client side setting buried in the audio options, i forget exactly where now, but you can set the jitter buffer target really low like 10ms and see if that helps. might make it crackle more but worth trying before you spend money on a new pi.

also slightly off topic but i went the arduino route for just the PTT and keyer stuff and kept the pi out of the audio chain entirely, works great and way less complexity. arduino nano reads a footswitch and key and handles all the timing, pi just does logging and cluster spotting. each device doing what its good at kind of thing.