Difference between revisions of "Sound troubleshooting"

From Linuxintro
imported>ThorstenStaerk
imported>ThorstenStaerk
 
(2 intermediate revisions by the same user not shown)
Line 15: Line 15:
 
==== If you do not 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:
 
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*
+
  rm /dev/dsp*
  tweedleburg:~ # udevtrigger
+
  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.
 
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 ====
 
If you get an error message like this:
 
If you get an error message like this:
  tweedleburg:~ # dd if=/dev/urandom of=/dev/dsp
+
  dd if=/dev/urandom of=/dev/dsp
 
  dd: opening `/dev/dsp': Device or resource busy
 
  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):
 
You should find out what process blocks your sound card. Do this with the command lsof (list open files):
  tweedleburg:~ # lsof | grep dsp               
+
<source>
 +
  lsof | grep dsp               
 
  mplayer  18251      root    4w      CHR              14,35              14320 /dev/dsp2
 
  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:
 
You see, mplayer is blocking /dev/dsp2, you third soundcard. Now find out what soundcard you are using:
  tweedleburg:~ # ll /dev/dsp*
+
<source>
 +
  ll /dev/dsp*
 
  lrwxrwxrwx 1 root root      9 Jun 21 10:38 /dev/dsp -> /dev/dsp2
 
  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, 19 Jun 21 10:36 /dev/dsp1
 
  crw-rw---- 1 root audio 14, 35 Jun 21 10:36 /dev/dsp2
 
  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:
 
/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
 
  killall mplayer
Line 40: Line 44:
 
= strace'ing sound =
 
= strace'ing sound =
 
You know that the [[command]] <tt>speaker-test</tt> does some test noise. To find out if pulseaudio or also is in use, issue:
 
You know that the [[command]] <tt>speaker-test</tt> does some test noise. To find out if pulseaudio or also is in use, issue:
<abbr title="This is a prompt. The follow is a command you must enter.">#</abbr> strace <abbr title="String length should be 99 characters. It's no fun if the actual messages in strace's output are cut short.">-s 99</abbr> <abbr title="strace should follow sub-processes and show their behavior as well">-ff</abbr> speaker-test
+
<source>
 
+
strace -s 99 -ff speaker-test
 +
</source>
 
You will find a lot of lines like
 
You will find a lot of lines like
<abbr title="Process id. You get this field because you started strace with -ff">[pid 15287]</abbr> <abbr title="Syscall. Find out more with the command man 2 write.">write(6, "W", 1)            = 1</abbr>
+
<source>
<abbr title="Process id. You get this field because you started strace with -ff">[pid 15287]</abbr> <abbr title="Syscall. Find out more with the command man 2 recvmsg.">recvmsg</abbr>(<abbr title="As we can tell from man 2 recv, the following is a file descriptor. Find out more with the command cat /proc/PID/fd/7">7</abbr>, {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
<abbr title="Process id. You get this field because you started strace with -ff">[pid 15287]</abbr> <abbr title="Syscall. Find out more with the command man 2 write.">write(6, "W", 1)            = 1</abbr>
+
[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 <tt>man 2 recvmsg</tt> 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:
 
'''So what happens here?''' Obviously speaker-test calls the kernel's ''recvmsg'' method. The interesting thing we get from <tt>man 2 recvmsg</tt> 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:
<abbr title="This is a prompt. The follow is a command you must enter.">#</abbr> cd /proc/15287/fd
+
<source>
 +
cd /proc/15287/fd
 
  ls -l
 
  ls -l
 
  total 0
 
  total 0
Line 59: Line 67:
 
  l-wx------ 1 root root 64 Apr  4 22:55 6 -> 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]
 
  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:
 
Aha! file descriptor 7 is the unix socket 297495. Let's look what this is connected to:
 
+
<source>
  <abbr title="This is a prompt. The follow is a command you must enter.">#</abbr> ss -p [[piping||]] [[grep]] 297495
+
  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      /run/user/0/pulse/native 297496                * 297495  users:(("pulseaudio",2289,28))
  u_str  ESTAB      0      0                    * '''297495'''               * '''297496''' users:(("'''speaker-test'''",15286,7))
+
  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.
 
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.

Latest revision as of 03:55, 1 April 2020

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:

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.

See also