On Sat, Jun 6, 2009 at 3:18 PM, Alexandre Ratchov<a...@caoua.org> wrote:
> 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).
A much better idea, thanks!
>> 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.
>
I had forgot to mention the following in my original post...
Obviously, when piping the aucat output through ssh, ssh itself is
going to introduce some delay. However, just trying the following...
aucat -l
aucat -o - | aucat -i -
There is still a ~1 second delay, so it seems that the "bulk" of the
delay was from aucat.
Using
aucat -b 1 -r 11000 -o - | aucat -b 1 -r 11000 -i -
Reduced this somewhat, but not significantly.
Following Hannah Schroeter's advice, reducing the buffer size on the
server instances of aucat reduces the delay dramatically. There is
only a very, very small delay (even through ssh!)
i.e.
aucat -b 1 -l
aucat -b 1 -r 11000 -o - | aucat -b 1 -r 11000 -i -
Works beautifully. Thanks for all the tips.
-Ryan
