nbsp's semi-necroded brain gives you another toy to play around with. this time, it's an irc client that connects to town over ssh, then to town's internal irc, and then lets you voice chat on it. freaky stuff.
it's called hubbub and you can look at the code here. that link also includes info about how to build it and use it.
the main voice and text overflow channel is #hubbub. it used to require
two different channels, with a big warning to never ever join a voice
channel with text or vice versa, but it now uses TAGMSGs
which are fully invisible to text users. discussion of hubbub itself
takes place wherever you can catch me. there'll be a bbj thread at some
point and you can also just ping me on #tildetown.
/msg ChanServ SET #channel history off
this way no history will be kept in RAM.
hubbub is extremely experimental both as an idea but also in
implementation. ever since i reworked stuff to use TAGMSG
i hadn't really bothered to check audio works well or at all. my
experiments with RNNoise months ago showed me that it might be too slow;
i've disabled it for now, but i'm sure the issue is my loose handling
of pointers and not anything wrong with the library.
unless i change my mind for some reason, text is out of scope. hubbub Will Not have a text interface, and you Will Not be able to share a nick between your voice and text connections. i miiiight allow NickServ authorization to facilitate the latter, but most townies don't use NickServ, and why should they? this isn't an open server.
using message tags is nice because i can use around 4000 bytes instead of just around 480, but that doesn't matter for much. audio quality is already fine with base64 on 480 bytes, so there's no reason to increase the compression bitrate. increasing the bytes-per-message will only help to increase latency, since it's gonna have to wait more for a full load. my guess is that there's a goldilocks zone for latency, where magically increasing it gets rid of the overhead of sending ten dillion packets a second.