Codec2 One-way Contact
Simon took me up on my offer in the last post, and after a bit of fiddling, I could hear his codec2-encoded voice reach across the Internet from Crowsnet Pass in Alberta to the Bay of Fundy. Great fun!
I noted that at first his voice had a sort of 'auto-tune' effect, locking on a given tone unnaturally, until I asked him to reduce his audio gain a bit. I'd observed this effect in our home-based experiments, too. It might be useful to put some audio gain profiling code in the input pipeline so that we can manually optimize this.
Second, I think some sort of UDP NAT traversal code is going to be needed. I still want a very lightweight, tool-based approach that I think will port easily to small linux devices, but it took Simon and me quite a while to get the UDP ports worked out, and even then we couldn't get my packets to him.
It looks like nat-traverse, a perl script, will do the job. I'd rather not add a dependency on perl, but it's a good start, and cleanly separates out the task of nat traversal from the UDP packet handling and decoding.
Finally, c2qso.sh takes a half-duplex approach to communications: it doesn't perform transmit and receive across the same UDP link, because I wanted a client with low computing power to be able to safely close its transmitting port and then open the receiving one. But this is probably an unnecessary complication, and seem likely to make nat traversal more difficult.
I noted that at first his voice had a sort of 'auto-tune' effect, locking on a given tone unnaturally, until I asked him to reduce his audio gain a bit. I'd observed this effect in our home-based experiments, too. It might be useful to put some audio gain profiling code in the input pipeline so that we can manually optimize this.
Second, I think some sort of UDP NAT traversal code is going to be needed. I still want a very lightweight, tool-based approach that I think will port easily to small linux devices, but it took Simon and me quite a while to get the UDP ports worked out, and even then we couldn't get my packets to him.
It looks like nat-traverse, a perl script, will do the job. I'd rather not add a dependency on perl, but it's a good start, and cleanly separates out the task of nat traversal from the UDP packet handling and decoding.
Finally, c2qso.sh takes a half-duplex approach to communications: it doesn't perform transmit and receive across the same UDP link, because I wanted a client with low computing power to be able to safely close its transmitting port and then open the receiving one. But this is probably an unnecessary complication, and seem likely to make nat traversal more difficult.
Comments
Post a Comment