scairns@citib.com (Scott Cairns) (06/07/91)
I posted something the other day about how one could take stdout from something like record(6) and pipe it out over the network to another host's audio device. The following was suggested by <barmar@Think.COM>: > % record | rsh [hostname] play > > This should turn the two hosts and the network into telephones. > > -- > Barry Margolin, Thinking Machines Corp. 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? > 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. So I'm not sure if I can answer the bandwidth question (i.e. it may be a moot point). Does anyone have any comments regarding the bandwidth issue and also is it possible to remove the delay inherent in the above example? BTW, I haven't figured out a practical application yet for any of this yet. I suppose you could announce something like "The server is coming down..." but you'd need to be able to rsh to multiple hosts at the same time. Any suggestions would be welcome... +-----------------------------------------------------------------+ | Scott Cairns, AVP email: scairns@bank.citib.com | | Citicorp Credit Services Inc. phone: (718) 248-5366 | | Long Island City, NY 11120 fax: (718) 248-6855 | +-----------------------------------------------------------------+ | Disclaimer: I speak for myself only - not that anyone here | | would understand what I'm saying anyway. | +-----------------------------------------------------------------+
torek@elf.ee.lbl.gov (Chris Torek) (06/09/91)
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
caserta@athena.mit.edu (Francesco Caserta) (06/15/91)
In article <14083@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) writes: |> 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 It's all very neat! But here `play' returns "play: error opening /dev/audio: Permission denied". And indeed to play sounds here I can only to use `soundtool'. Any help, please? Thanks, Francesco Caserta