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!
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.
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.
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.
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.
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 :)
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.
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.
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.
Another classic was:
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!