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

Reply via email to