Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.shell
Subject: Re: Audio
Keywords: Audio Shell
Message-ID: <14083@dog.ee.lbl.gov>
Date: 8 Jun 91 21:11:27 GMT
Article-I.D.: dog.14083
References: <1991Jun7.134254.11485@citib.com>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Distribution: usa
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 30
X-Local-Date: Sat, 8 Jun 91 14:11:27 PDT

In article <1991Jun7.134254.11485@citib.com> scairns@citib.com
(Scott Cairns) writes:
>... The following was suggested by <barmar@Think.COM>:
>>       % record | rsh [hostname] play
>which worked just fine.  He then followed up with this question:
>>	I was curious about how well this would work.  Is the bandwidth of
>>	Ethernet good enough for real-time sound like this?

The bandwidth of Ethernet is plenty---the SparcStation /dev/audio
takes only 8000 samples per second, i.e., 8 KB/s (using ulaw encoding
to compress 12-bit samples to 8-bit values).  Ethernet is entirely
capable of sending 1.25 MB/s; 8 KB/s is trivial.

>It's not exactly "real-time" of course.  With:
>
>% record -v 50 | rsh [hostname] play -v 50
>
>you have to wait for record(6) to do a flush(3) before it pipes
>over the network to rsh(1) so there is a second or two of latency.

This just means you have to write more code; the provided shell-level
tools will not do the trick.

>BTW, I haven't figured out a practical application yet for any of
>this yet.

Audio, and eventually video, conferencing.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov