That reminds me of a couple tricks I used to use in the old days. As an alarm clock I'd do:

  $ sleep 28800; while :; do cat /etc/termcap; done >/dev/audio

I found that termcap had just the right mix of structure and randomness to make an annoying noise that was really hard to sleep through.

Another classic was:

  $ ping -f hostname >/dev/audio

When you have zero packet loss, "ping -f" would generate an endless sequence of '.' and '\b' characters, resulting in a constant tone. When there is 100% loss you only get the '.' characters and the sound will stop. In between, you'll get a progressively noisier sound. Then just turn the speakers on your SPARCstation all the way up and crawl around the lab, flexing the 10base2 cabling until you find what segment is causing that irritating intermittent problem!

rsh coworkersbox "cat /dev/audio" > /dev/audio

Or vice-versa. Not sure what systems it'd still work on, but it was a lot of fun on pre-Solaris SunOS machines.

  ssh otherbox cat /dev/dsp > /dev/dsp

should work on a Linux system with OSS emulation enabled. Or, if you have alsa-utils installed on both systems:

  ssh otherbox arecord -D plughw | aplay -D plughw

You can also hear the sound of any phrase:

    $ yes hacker news  >/dev/audio

We had a lot of fun with this in University 20 years ago. Our computer lab had a handful of shiny new Sun Sparcstations. The freshmen would regularly end up hogging them (no timelimit) and we needed them for project work, so we'd just remote login to them and cat some pre-recorded messages out to /dev/audio. A very official-sounding "Please log out now, system going down for maintenance" usually worked wonders, although occasionally more serious messing with people's minds was done. Some of the 1st year students had literally no idea what a computer was capable of and would believe anything that came out of its speakers. :D

On a tangent... I remotely logged into my computer at the dorms once and opened up the webcam and microsoft speech assistant thing. I started talking to my roommate based on how he responded, and played some rage against the machine really loud. He thought the computer was possessed (he wasn't that bright overall). Anyways, when I saw him pick up the web cam and slam it into the desk I figured I better start running back the half mile to the dorms before he destroyed the whole thing. I wish I would have recorded it.

On Mac OS X a common trick is to ssh into the box and use `say(1)`.

From July 19, 2000: "Catting weird things to /dev/audio"

http://everything2.com/user/mcc/writeups/catting+weird+thing...

The eleven-year-old MP3 link in this article is dead, of course. I probably still have the files on a hard drive somewhere, but they're exactly what you would expect: weird looping noise.

that very node had me catting my hard drive into my speakers for weeks!

Only mildly related, but I have fond memories of my friend and I needing to wake each other up at different points in the 90's, and we had our neat-o Linux boxes next to our beds, and we would create loops that would echo ^G's to a tty on the console.

But if you sent them too fast the sound would completely cease, so we would have to put a sleep 1 in the loop to make a nice consistent beep-beep-beep-beep, etc.

That always amused us, and sure was useful.

I found people had posted audio interpretations of binary files on YouTube.

shell32.dll: http://www.youtube.com/watch?v=mqNLuunxp0o itunes.exe: http://www.youtube.com/watch?v=iY-lJrX2VD0&;

Probably been posted before, but this reminds me of this rather awesome article about one-liner algorithms outputting to /dev/audio to create some really quite cool "compositions": http://createdigitalmusic.com/2011/10/entire-musical-composi...

There's a site to try your own at: http://wurstcaptures.untergrund.net/music/

Alas, OS X doesn't seem to support anything like this.

Neither does modern Linux, sadly. The older SunOS-style audio devices still exist in the kernel as an emulation, but aren't loaded by default (and tend to have weird behavior vs. other parts of your distro's audio stack). The ALSA framework is the modern equivalent. It's much more featureful, but its device API is frustratingly opaque. So much so that the only "supported" interface to the driver is the libasound userspace library. This, too, is low level and opaque. So you're really supposed to use the pulseaudio middleware to actually play and mix your audio stream. And even then, the pulse API is basically PCM-only, and your stream is probably sourced from something encoded. So you really want to be using gstreamer to generate your stream and take advantage of existing codec plugins (and hardware acceleration, etc...). And even then gstreamer is opaque, so all the toolkits have wrapper APIs.

Sigh. The days of being able to spit sounds to a char device are basically over. We have more powerful software now with far more capability. And that kind of sucks, sometimes.

Try using `padsp tee /dev/audio` >& /dev/null

For example: sudo cat /dev/mem | `padsp tee /dev/audio` >& /dev/null

Yes yes. The existence of that silliness is kind of my point. There's nothing "wrong" with Linux audio from a technical/feature standpoint. But the aesthetics are a frothing mess. It's not a clean design.

The /dev/audio device on SunOS 4.1 was a clean design (albeit one that solved a much simpler problem). That sanity wasn't preserved in the march to modernity, and it sucks.

The design is pretty similar to how every other modern OS does it, I think - what would you change if you had the choice?

I mean, it's not as clean as things were, but we've come a long way since then in terms of features so obviously simplicity is going to suffer. Worth the trade off, in my opinion :)

You can also use pacat

Example: `cat /dev/urandom | pacat`

I followed along the examples by piping into the command line ALSA player 'aplay', which is I think included in all ALSA installs.

It can be done on OS X with sox:

    cat /dev/urandom | sox -traw -r44100 -b16 -u - -tcoreaudio

sox isn't part of core Mac OS X, and the homebrew package appears to be broken at the moment.

I don't think there's a built-in method to play raw audio like this.

    brew update

Fixed all my ills.

Conveniently, the sox project on sourceforge has Mac OS X binaries available.

http://sox.sourceforge.net/

Excellent, thanks!

Actually, while we're on the topic(ish), how does one do it back the other way? Ie, stream from audio input to a file (I was looking into it earlier today). Best I could find, you had to install some wrapper drivers or something.

If you run pulseaudio you can use parec. It's fiddly but there is an example script here http://www.outflux.net/blog/archives/2009/04/19/recording-fr...

Related from HN a few years ago: http://news.ycombinator.com/item?id=564568 (not a dupe, but extra awesome stuff on the same topic)

I believe this is specific to OSS, which was deprecated after it went closed source for a bit and ALSA replaced it:

http://en.wikipedia.org/wiki/Open_Sound_System

I'm fairly happy using the OpenAL API instead to generate audio cross-platform at the moment.

ALSA emulates the OSS devices.

Not by default in arch linux, debian, ubuntu, etc. Requires an extra module.

A while ago I did a bit of reverse-engineering on this and figured out how to get it to play music.

https://github.com/caoilteguiry/dev_music

Explanation of how it works is pretty scant at the moment, I'll try to expand it a little when I get a chance.

How hard is it to output /dev/audio to a file instead of hardware? For example, to capture the output of streaming audio.

That's so simple and old school !!

cat /dev/audio > record.au

Here you will get Sun .au, which is mulaw IIRC.

/dev/dsp is different.

EDIT - after a quick google search, here are some details on the encoding difference : OSS has three kind of device files for audio programming. The only difference between these device files is the default sample encoding used after opening the device. /dev/dsp uses 8 bit unsigned encoding while /dev/dspW uses 16 bit signed little endian (Intel) encoding and /dev/audio uses logarithmic mu-Law encoding. There are no other differences between the devices. All of them work in 8 kHz mono mode after opening them.

http://www.opensound.com/pguide/audio.html

That will capture the microphone input; it won't capture the sound that the computer is playing, which is what I think the comment you are replying to wants.

Oops, I thought the original poster to record, like a dictaphone.

Thank you!

Try the directory /dev/input/ for your input devices.

does any of this sound like a pots modem baud negotiation?