Sound troubleshooting

So you want your Linux system to play sound, but it does not? Follow these steps to analyze and solve the problem:

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:

tweedleburg:~ # rm /dev/dsp*
tweedleburg:~ # 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:

tweedleburg:~ # 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):

tweedleburg:~ # lsof | grep dsp              
mplayer   18251       root    4w      CHR              14,35               14320 /dev/dsp2

You see, mplayer is blocking /dev/dsp2, you third soundcard. Now find out what soundcard you are using:

tweedleburg:~ # 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

/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:

# strace -s 99 -ff speaker-test

You will find a lot of lines like

[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

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:

# 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]

Aha! file descriptor 7 is the unix socket 297495. Let's look what this is connected to:

# 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))

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.

See also

• stRace