Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently I have been exploring the enchanted /dev folder. I want to write some random data to an audio device in order to generate some noise.

I am using ALSA.

So I instruct cat to pipe some random data to the playback file in the /dev folder...

 cat file-of-random-data > /dev/snd/pcmC0D0p

then I recieve what seems to be an error from cat

 cat: write error: File descriptor in bad state

How can I fix this so I can hear some delicious static play from my sound card?

share|improve this question
I think you need to send random PCM data, or maybe you need to set up the device with a few ioctls first — you can't just dump random bytes. – Gilles May 25 '11 at 7:22
@Gilles According to Wikipedia, .wav is PCM and I get exactly the same result when replace the random file with a .wav file. I will investigate setting up some in/out controls. – jones May 25 '11 at 8:52
Does someone have a pointer for a tutorial on how to set up some ioctls? For something called ioctls, I thought ALSA as an API should provide the interface for input and output? – jones May 25 '11 at 10:20
up vote 32 down vote accepted

I think the reason this isn't working for you is because that interface has been deprecated. You normally can't write audio using /dev/dsp anymore, at least without being tricky.

There is a program that will accomplish this for you on your system: padsp. This will map the /dev/audio or /dev/dsp file to the new Audio Server system.

Fire up the terminal and get into root mode with sudo su.

Then, I'm going to cat /dev/urandom and pipe the output into padsp and use the tee command to send the data to /dev/audio. You'll get a ton of garbage in your terminal, so you may want to redirect to /dev/null.

Once you're in superuser, try this command:

cat /dev/urandom | padsp tee /dev/audio > /dev/null

You may even want to try with other devices, like your mouse: Use: /dev/psaux, for instance or the usb driver. You can even run your memory through it: /dev/mem

Hope this clarifies why it wasn't working before.

Personally, I found the mouse and memory to be way more interesting than playing random static!

share|improve this answer
Thanks a lot! This is what I was looking for. Answered a full 7 months after posting the question! :-) – jones Jan 28 '12 at 9:50
It seems that sudo privileges are not required for this. – iyrin May 8 '15 at 18:03
thanks very much. i found binaries to be weirdly interesting. things like /usr/bin/ls /usr/bin/gnome-terminal /usr/bin/mysql – don bright Jun 5 '15 at 5:59

Try /dev/audio or one of the other devices under /dev/snd. Not all of them are audio data sinks, you might have caught a mixer, microphone, or something

share|improve this answer
thanks for the reply. According to /proc/asound/devices /dev/snd/pcmC0D0p is the right device for audio playback (hence the 'p') – jones May 25 '11 at 10:06
Also, I am not sure, but can there be multiple dev "files" for playback? I don't have a '/dev/audio' I think '/dev/audio' has something to do with OSS which is used on older kernels (before 2.5) – jones May 25 '11 at 10:14

cat /dev/urandom | padsp tee | aplay is the command that needs to be typed. If you aren't in "audio" group, you could prefix aplay with sudo. This also doesn't interfere with any daemons (I was running pulseaudio while this command was active and correctly heard the "noise".

share|improve this answer
I use ALSA, and "padsp tee" isn't necessary. – Geremia Jan 11 '14 at 23:31
In my pulseaudio experiences (and whatever Ubuntu is using when PA is down) that padsp tee was required (I had precise 12.04.2 at that time) The thing is you shouldn't try to dump data directly into devices, even if you were root (as far as I know few files are readable and none writable in the /dev folder), because you could either get an error (in the best case, which gets more common with each update), crash the kernel or even break the device, in rare cases. One should use unprivileged elements, like aplay, to do this (audio group or root required, unfortunately). @geremia – Paul Stelian Feb 3 '14 at 2:12

Is a sound daemon (e.g. pulseaudio) holding a lock on the device? I think you can find out if anything else has a handle on it via lsof.

share|improve this answer
Thanks for the helpful suggestion. I had a check, using grep and lsof. pulseaudio is using /dev/snd/controlC0 but it isn't on /dev/snd/pcmC0D0p . I had a double check by going to /var/lock to find if there was a file for a lock on the device. ls -al tells that the folder is empty. So I guess there is no lock on pcmC0D0p – jones May 31 '11 at 12:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.