[nullc]

Since you're not realtime you could also have a configurable playback speed on the rx side or processing that removes gaps to make it go faster. This would improve the latency while maintaining the whole store/forward design, and would also let a recipient get more than 100% audio (e.g. from multiple people sending to them).

You're using opus but you might be interested in abusing the DRED error correcting scheme (which is an experimental part of opus) in it as a codec, as it does pretty good sounding speech at 2kbit/sec. You could send the dred first then the opus compressed audio so that if tor craps out before the transmission completes the receiver still get the audio. (A step further would be to run automatic speech recognition, a send text, dred, then opus. :P ).

[smalltorch]

I am totally interested in a 2kbs encoding if that's possible. I didn't think opus could encode below 6. Making this as slim as possible is definitely what I'm aiming for. Really though the latency basically all coming from Tor.

Someone also suggested that you can configure Tor to take only one hop. You loose anonimity but gain speed right away. May be something to look into as optional setting.

I also learned today I can pipe direct binary without encoding base64. This will chop overhead right away. I didn't think it was possible to pipe through bash but I was using the wrong command.

I do plan to continue to optimize that's great feedback thanks!