Sound troubleshooting
So you want your Linux system to play sound, but it does not? Follow these steps to analyze and solve the problem:
Contents
The Methodology
If your cables and volume are okay
- Test if your sound card driver and cables are okay; play a test sound:
speaker-test
If you hear a sound
If you hear a sound, your cables and drivers are okay.
If you do not hear a sound
If you do not hear a sound, see if you get an error message.
If you do not get an error message
If you do not get an error message, it can be a driver issue. To find out, delete all sound devices and re-create them:
rm /dev/dsp* udevtrigger
Check again with dd if=/dev/urandom of=/dev/dsp. If you still do neither get an error message nor sound, it is most probably a driver issue. Get yourself a USB soundcard and proceed.
If you get an error message
If you get an error message like this:
dd if=/dev/urandom of=/dev/dsp dd: opening `/dev/dsp': Device or resource busy
You should find out what process blocks your sound card. Do this with the command lsof (list open files): <source>
lsof | grep dsp mplayer 18251 root 4w CHR 14,35 14320 /dev/dsp2
</source> You see, mplayer is blocking /dev/dsp2, you third soundcard. Now find out what soundcard you are using: <source>
ll /dev/dsp* lrwxrwxrwx 1 root root 9 Jun 21 10:38 /dev/dsp -> /dev/dsp2 crw-rw---- 1 root audio 14, 19 Jun 21 10:36 /dev/dsp1 crw-rw---- 1 root audio 14, 35 Jun 21 10:36 /dev/dsp2
</source> /dev/dsp points to /dev/dsp2, so the soundcard you are using is blocked by mplayer. So, kill mplayer if you are sure that is what you want:
killall mplayer
Knoppix
When there is no sound under Knoppix try
/etc/init.d/alsa-utils start
strace'ing sound
You know that the command speaker-test does some test noise. To find out if pulseaudio or also is in use, issue: <source> strace -s 99 -ff speaker-test </source> You will find a lot of lines like <source> [pid 15287] write(6, "W", 1) = 1 [pid 15287] recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"L\0\0\0\2L\0\0\2+U\0\0\0\0\0\31vqU\0\0\0\0\0\0\0\0001TU \240\326\0\4\252\354TU \240\326\0\4\262%r\0\0\0\0\0\20\0\0r\0\0\0\0\0\2\260\220R\0\0\0\0\0\0\0\0R\0\0\0\0\0\2\260\220", 83}], msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS{pid=2289, uid=0, gid=0}}, msg_flags=0}, 0) = 83 [pid 15287] write(6, "W", 1) = 1 </source>
So what happens here? Obviously speaker-test calls the kernel's recvmsg method. The interesting thing we get from man 2 recvmsg is that the first parameter is sockfd, the file descriptor of a socket. So it hands over a socket as a parameter. Let's look at process' file descriptors: <source>
cd /proc/15287/fd ls -l total 0 lrwx------ 1 root root 64 Apr 4 22:55 0 -> /dev/pts/4 lrwx------ 1 root root 64 Apr 4 22:55 1 -> /dev/pts/4 lrwx------ 1 root root 64 Apr 4 22:55 2 -> /dev/pts/4 lr-x------ 1 root root 64 Apr 4 22:55 3 -> pipe:[297487] l-wx------ 1 root root 64 Apr 4 22:55 4 -> pipe:[297487] lr-x------ 1 root root 64 Apr 4 22:55 5 -> pipe:[297488] l-wx------ 1 root root 64 Apr 4 22:55 6 -> pipe:[297488] lrwx------ 1 root root 64 Apr 4 22:55 7 -> socket:[297495]
</source> Aha! file descriptor 7 is the unix socket 297495. Let's look what this is connected to: <source>
ss -p | grep 297495
u_str ESTAB 0 0 /run/user/0/pulse/native 297496 * 297495 users:(("pulseaudio",2289,28))
u_str ESTAB 0 0 * 297495 * 297496 users:(("speaker-test",15286,7))
</source>
We see - the socket 297495 is connected to the socket 297496. What is written into 297495 will be readable from 297496 and the other way round. This couple of sockets connects the speaker-test process with the pulseaudio process. 2289 is pulseaudio's process id, and 15286 is the root process id of speaker-test. This system is using pulseaudio for sound which is an important information for troubleshooting sound.
