Voice-chat on OpenBSD with nothing more than aucat and ssh

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Voice-chat on OpenBSD with nothing more than aucat and ssh

Ryan Flannery
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 ryan@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 ryan@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 | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Gilles Chehade-5
Wow, that's an interesting use of using aucat and ssh, you
made me curious and i'm going to try it :-)

Gilles

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 ryan@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 ryan@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 | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Martin Schröder
In reply to this post by Ryan Flannery
2009/6/6, Ryan Flannery <[hidden email]>:
>  ryan# grep ryan /etc/passwd

man id
id -u ryan

Best
   Martin

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Ryan Flannery
In reply to this post by Gilles Chehade-5
Well, if you'd like to test with a fellow openbsd user and play around
with some of the settings, feel free to hit me up.

ps - I'm loving smtpd... your efforts there are also greatly appreciated.

On Fri, Jun 5, 2009 at 6:05 PM, Gilles Chehade<[hidden email]> wrote:

> Wow, that's an interesting use of using aucat and ssh, you
> made me curious and i'm going to try it :-)
>
> Gilles
>
> 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 ryan@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 ryan@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 | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Francesco Vollero
In reply to this post by Ryan Flannery
Ryan Flannery ha scritto:
> With the recent work done to the audio system on OpenBSD, a buddy of
>
>  
[snip]
> audioctl, that one could play with to reduce this?
>
>  
Maybe is stupid but r just my 2 cent , but trying to use blowfish
cipher? I noticed a little difference using this cipher when i've to
move big files...

PS= Thanks for the idea of aucat :P

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

j4nKy
In reply to this post by Ryan Flannery
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 ryan@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.

not yet.  it's a bit of a can of worms ...

>
> 2. After doing the above, we would both simply do the following...
>
> ryan# aucat -b 1 -r 11000 -o - | ssh ryan@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?

you could run the aucat server process with a smaller buffer.  maybe
-b 1024.  that's pretty low latency, maybe too much even.  you could
try 8-bit encodings.

>
> Many thanks to the devs again... this rocks.   and it's in base.
>
> -ryan
>

--
[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

j4nKy
In reply to this post by Ryan Flannery
On Fri, Jun 05, 2009 at 06:02:01PM -0400, Ryan Flannery wrote:

>  Any other options, to aucat or perhaps
> audioctl, that one could play with to reduce this?

I forgot to say, audioctl isn't really useful for anything
but exploring/debugging.  you really shouldn't mess with
audioctl on a running stream.

--
[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Hannah Schroeter
In reply to this post by Ryan Flannery
Hi!

On Fri, Jun 05, 2009 at 06:02:01PM -0400, Ryan Flannery wrote:
>[...]

>"deeper" and more "muted".  Any other options, to aucat or perhaps
>audioctl, that one could play with to reduce this?

I guess you could try to reduce the buffer size on the aucat *servers*
(-b on the aucat *-l* invocations).

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Neal Hogan
cheers

On Fri, Jun 5, 2009 at 6:34 PM, Hannah Schroeter <[hidden email]> wrote:

> Hi!
>
> On Fri, Jun 05, 2009 at 06:02:01PM -0400, Ryan Flannery wrote:
> >[...]
>
> >"deeper" and more "muted".  Any other options, to aucat or perhaps
> >audioctl, that one could play with to reduce this?
>
> I guess you could try to reduce the buffer size on the aucat *servers*
> (-b on the aucat *-l* invocations).
>
> Kind regards,
>
> Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Alexandre Ratchov-2
In reply to this post by Ryan Flannery
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 ryan@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 ryan@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

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Ryan Flannery
On Sat, Jun 6, 2009 at 3:18 PM, Alexandre Ratchov<[hidden email]> 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 ryan@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 ryan@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

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Alexandre Ratchov-2
On Sat, Jun 06, 2009 at 03:34:08PM -0400, Ryan Flannery wrote:

>
> 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!)
>

oh, I never thought that this could work well enough
excellent!
:)

-- Alexandre

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

j4nKy
In reply to this post by Ryan Flannery
On Sat, Jun 06, 2009 at 03:34:08PM -0400, Ryan Flannery wrote:

> aucat -b 1 -l

this '-b 1' bugs me.  you're telling aucat to process each frame
individually ... sort of.

it really means "as small as possible".  in server mode, you'll
get the smallest buffer that the hardware supports, so the results
may be inconsistent on different hardware.

--
[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Ryan Flannery
On Sat, Jun 6, 2009 at 4:43 PM, Jacob Meuser<[hidden email]> wrote:

> On Sat, Jun 06, 2009 at 03:34:08PM -0400, Ryan Flannery wrote:
>
>> aucat -b 1 -l
>
> this '-b 1' bugs me.  you're telling aucat to process each frame
> individually ... sort of.
>
> it really means "as small as possible".  in server mode, you'll
> get the smallest buffer that the hardware supports, so the results
> may be inconsistent on different hardware.
>

I had thought that we both might have to specify a format/encoding for
aucat to work correctly between our two machines, but never considered
the buffer size.  From our dmesg's, it appears we may both have the
same audio hardware:

my machine (lenovo T61):
azalia0 at pci0 dev 27 function 0 "Intel 82801H HD Audio" rev 0x03:
apic 1 int 17 (irq 11)
azalia0: RIRB time out
azalia0: codecs: Analog Devices AD1984, Conexant/0x2bfa, using Analog
Devices AD1984
audio0 at azalia0


buddy's machine (lenovo T400... I think):
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03:
apic 1 int 17 (irq 11)
azalia0: codecs: Conexant CX20561
audio0 at azalia0

Could that be why "-b 1" is working?

Also, with "-b 1024", the delay is around a half-second... not too bad.

-ryan

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

j4nKy
On Sat, Jun 06, 2009 at 05:01:26PM -0400, Ryan Flannery wrote:

> On Sat, Jun 6, 2009 at 4:43 PM, Jacob Meuser<[hidden email]> wrote:
> > On Sat, Jun 06, 2009 at 03:34:08PM -0400, Ryan Flannery wrote:
> >
> >> aucat -b 1 -l
> >
> > this '-b 1' bugs me.  you're telling aucat to process each frame
> > individually ... sort of.
> >
> > it really means "as small as possible".  in server mode, you'll
> > get the smallest buffer that the hardware supports, so the results
> > may be inconsistent on different hardware.
> >
>
> I had thought that we both might have to specify a format/encoding for
> aucat to work correctly between our two machines, but never considered
> the buffer size.  From our dmesg's, it appears we may both have the
> same audio hardware:
>
> my machine (lenovo T61):
> azalia0 at pci0 dev 27 function 0 "Intel 82801H HD Audio" rev 0x03:
> apic 1 int 17 (irq 11)
> azalia0: RIRB time out
> azalia0: codecs: Analog Devices AD1984, Conexant/0x2bfa, using Analog
> Devices AD1984
> audio0 at azalia0
>
>
> buddy's machine (lenovo T400... I think):
> azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03:
> apic 1 int 17 (irq 11)
> azalia0: codecs: Conexant CX20561
> audio0 at azalia0
>
> Could that be why "-b 1" is working?

I guess I need to explain better ;)

the buffer sizes do not need to match.  the buffer sizes only affect
the latency.  so when I said "the results may be inconsistent", I
meant that with '-b 1', there may be too little buffering to keep
the audio smooth, depending on the hardware.

anyway, azalia(4) rounds block sizes (there are one or more whole
blocks in the hardware buffer) to multiples of 128 bytes.  other
drivers have different rounding requirements.

> Also, with "-b 1024", the delay is around a half-second... not too bad.

'aucat -l -b 1' on azalia will get you a 512 byte hardware buffer
(two blocks of 256 bytes each), which is 2.9 ms, timewise.
'aucat -l -b 1024' gets a 2048 byte buffer, which is 11.6 ms
timewise.  'aucat -l' gets a 23296 byte buffer, or ~130 ms.  since
you are recording then playing back, you will have at least 2x
the audio hardware buffer size latency ...

--
[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Ted Walther-4
In reply to this post by Ryan Flannery
On Sat, Jun 06, 2009 at 05:01:26PM -0400, Ryan Flannery wrote:
>Could that be why "-b 1" is working?
>
>Also, with "-b 1024", the delay is around a half-second... not too bad.

Counter-intuitive as it seems, keep your buffer -b 1024, and increase
the sampling rate to 44100.  Tell me if latency doesn't drop
dramatically. :-)

Ted

--
           There's a party in your skull.  And you're invited!

Name:    Ted Walther
Phone:   604-755-7732
Skype:   tederific
Email:   [hidden email]
Address: 1755 246 St, LANGLEY BC  V2Z1G4

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

Nick Guenther
In reply to this post by Alexandre Ratchov-2
On Sat, Jun 6, 2009 at 3:18 PM, Alexandre Ratchov<[hidden email]> 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 ryan@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).
>

Classy! I was looking for a way to do this but the manpage didn't
mention anything.

>> 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.


What good are shared sockets if they aren't usable simultaneously??

use case: I'm always wanting to set up and audio-studio box, and right
now aucat lets me, but what if I want to have myself and a hundred of
my closest friends play a midi-orchestra all routed through the one
box with everyone running their own session on a (remote) frontend? I
could just make a shared 'music' account but that's a workaround for
an awkward system.

Please, don't necessarily make a -g(lobal) flag for aucat, but don't
restrict its flexibility by forcing restrictions in the name of
security. The OS is perfectly competent as handling security with file
permissions like it's designed to. Just add a way for each user to
specify what socket they want sndio to talk to? Like a /etc/sndiorc
and ~/.sndiorc pair. Then to make a global socket you would set it in
your global /etc/sndiorc and then sound would Just Work for every user
and you'd only have to start aucat -l once, but users would still have
to be in the audio group or whatever to use this. Conversely, if
you're actually worried about eavesdropping you can run aucat -l like
usual.

Actually, you could hack this now: make an 'audio' user, at boot do
"sudo -u audio aucat -l" and also create links to the socket that made
for each user on the system. I don't know what's worse: recreating
links at each boot or having to have a config file.

-Nick

Reply | Threaded
Open this post in threaded view
|

Re: Voice-chat on OpenBSD with nothing more than aucat and ssh

j4nKy
On Sat, Jun 06, 2009 at 11:10:29PM -0400, Nick Guenther wrote:

> On Sat, Jun 6, 2009 at 3:18 PM, Alexandre Ratchov<[hidden email]> 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 ryan@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).
> >
>
> Classy! I was looking for a way to do this but the manpage didn't
> mention anything.
>
> >> 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.
>
>
> What good are shared sockets if they aren't usable simultaneously??
>
> use case: I'm always wanting to set up and audio-studio box, and right
> now aucat lets me, but what if I want to have myself and a hundred of
> my closest friends play a midi-orchestra all routed through the one
> box with everyone running their own session on a (remote) frontend? I
> could just make a shared 'music' account but that's a workaround for
> an awkward system.

you could do this more easily with jackd/netjack.

> Please, don't necessarily make a -g(lobal) flag for aucat, but don't
> restrict its flexibility by forcing restrictions in the name of
> security. The OS is perfectly competent as handling security with file
> permissions like it's designed to. Just add a way for each user to
> specify what socket they want sndio to talk to? Like a /etc/sndiorc
> and ~/.sndiorc pair. Then to make a global socket you would set it in
> your global /etc/sndiorc and then sound would Just Work for every user
> and you'd only have to start aucat -l once, but users would still have
> to be in the audio group or whatever to use this.

so, by default, it would work for noone.  I really don't like
such solutions.

> Conversely, if
> you're actually worried about eavesdropping you can run aucat -l like
> usual.

I think most people don't realise how easy it is to eavesdrop (or
even that it's possible).

> Actually, you could hack this now: make an 'audio' user, at boot do
> "sudo -u audio aucat -l" and also create links to the socket that made
> for each user on the system. I don't know what's worse: recreating
> links at each boot or having to have a config file.

config file and the extra code/complexity it would force onto
everyone, imo.

--
[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org