With the recent work done to the audio system on OpenBSD, a buddy of mine and I figured it should be easy to setup two-way voice-chat between two OpenBSD clients using nothing more than aucat(1) and ssh(1). As we found out, it is both very easy and very usable! We have telephone-quality chatting working with a <= 1 second delay in the audio (after a few minutes of chatting, this is unnoticeable).
First, a hearty thanks to Jacob Meuser and the other OpenBSD developers who have worked hard on this recently. Your efforts are both noticed and greatly appreciated. Second, I have a couple of questions... 1. We, the two users chatting (users neal and ryan) have ssh accounts on each other's machines. To voice-chat with each other, what we did boils down to the following: ryan# aucat -l ryan# aucat -o - | ssh r...@neals-machine aucat -i - User neal would do the same, only to my (ryan's) machine. When aucat is run in server-mode ('aucat -l') it creates a socket in "/tmp/aucat-USERID/default" where USERID is the uid of the user who ran the command (aucat -l). For another user (neal) to bind to this socket, we had to make this socket available to the other user, namely ryan# grep ryan /etc/passwd (find ryan's uid, call it RYANSID) ryan# grep neal /etc/passwd (find neal's uid, call it NEALSID) ryan# aucat -l ryan# cd /tmp/ ryan# chmod 755 aucat-RYANSID ryan# ln -s aucat-RYANSID aucat-NEALSID Neal would do the same on his machine, only reversed. Question: is it possible to run aucat(1) in such a way that the socket it creates in 'global', such that other users can connect to it? A quick perusing of the man/archives and the source says no... but I may be missing something. 2. After doing the above, we would both simply do the following... ryan# aucat -b 1 -r 11000 -o - | ssh r...@neals-machine aucat -b 1 -r 11000 -i - With the above -b and -r flags, the audio was not choppy at all, quite high-quality (equal to telephone quality), and overall very nice. We had about a ~1 second delay in the audio, however (neal's in Chicago, I'm in Cincinnati... we expected this), but could any of the developers familiar with the audio system see a way to perhaps decrease this delay? We played with other rates (-r values), but below 11000 the delay was about the same, and the audio became "deeper" and more "muted". Any other options, to aucat or perhaps audioctl, that one could play with to reduce this? Many thanks to the devs again... this rocks. and it's in base. -ryan