On Fri, Jun 05, 2009 at 06:02:01PM -0400, Ryan Flannery wrote:
> 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
>
if you use hard links instead of soft links, you can
``share'' your socket with another user without changing the
socket directory permissions (so you avoid giving it to all
users).
> 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.
>
no, there's no way for that. Even if we start supporting
``shared sockets'' (i hope so), they will not be usable
simultaneously by multiple users (to avoid evesdropping).
Fine grained access control might solve this problem, but is
too complicated and outside the scope of aucat.
> 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?
>
AFAIU the delay cannot be reduced this way (even with a
small -b). Delays are caused by buffering, and ssh(1), as
all the network software (and hardware, eg. your switch) in
the chain use buffers. AFAIK there's no way to set these
buffer sizes (especially the ones in the hardware of your
internet provider :).
aucat(1) has a latency control mechanism to solve similar
problems. To use it you could try to proxy the remote aucat
socket locally, ie to create a local /tmp/aucat-uid/xxx
socket that's forwarded on the remote machine (don't know if
nc(1) can do that). Then you can write a trivial program to
transfer data between your local device and the remote
``xxx'' device.
just thoughts
-- Alexandre
