CLI Quickies (II): Fiddling with Sound

The same way you can use the GNU/Linux command line to troubleshoot the brightness of your laptop backlight, it is also possible to discover a lot about your audio card from a text terminal. This can come in handy when trying to figure out the cause of problems with the sound system.

Conventions used in this guide

Throughout our command line tutorials, we use $ to indicate you can run the command shown as a regular user, and # to indicate you must run the instruction as superuser/root or using sudo.

When we show both the instruction and its output, what you have to actually type is shown in bold.

To quickly check if there is basic sound support on your computer, the easiest thing to do is to play an audio file, and there’s a (CLI) app for that:

$ play youraudiofile.ogg

The play program works with most audio formats, including OGG, MP3, FLAC, AIFF and so on. If you don’t have it installed, it is part of the SoX suite of audio tools, so look for that in your package manager.

On a side note, all the SoX tools, including play, allow for many interesting options and variations. Try for example

$ play youraudiofile.ogg chorus 0.7 0.9 55 0.4 0.25 2 -t

and see what you get. SoX is so full-featured that it deserves an article in its own right, something we will get round to one of these days. Promise.

play-2015-09-22_12.30.34Volume Control

If you have problems running play and your system chokes on some error, skip to the Identifying Hardware section below. If you don’t get any errors, but you still can’t hear anything, you should check the volume with amixer.

Without any options, amixer prints out the available controls for the default card with a brief summary for each:

$ amixer
 Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Front Left: Playback 55708 [85%] [on]
  Front Right: Playback 55708 [85%] [on]
 Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch cswitch-joined
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 65536
  Front Left: Capture 65540 [100%] [on]
  Front Right: Capture 65540 [100%] [on]

In this case, changing the volume of the Master control, will change the volume of the sound the computer produces. Changing the volume of the Capture control will change the volume at which the computer records audio, for example, from a microphone.

The 0 after each of the control labels in the output above means the data refers to the default sound card. If you have more than one card, 0 will be the first card, 1 the second, and so on. It so happens that it is reasonably common to have more than one sound card identified. You can check what audio devices your system sees by doing:

$ cat /proc/asound/cards
 0 [HDMI    ]: HDA-Intel - HDA Intel HDMI
               HDA Intel HDMI at 0xf7414000 irq 36
 1 [PCH     ]: HDA-Intel - HDA Intel PCH
               HDA Intel PCH at 0xf7410000 irq 32

This gives you some valuable information! In the case shown above, the first thing you see is that the device that outputs audio through the built in sound system (PCH) is NOT the first, default device. The first device, device 0, is actually used to pipe audio over the HDMI port to an external monitor. The PCH device is the second device, device 1.

So, if your setup looks something like what’s shown above, to get the information on channels and volume using amixer for the PCH card, you would have to do:

$ amixer -c 1

And add the -c 1 flag to every amixer command if you want it to affect the second card.

For now and for simplicity’s sake, let’s assume the PCH card is the first default card (0).

You can control the volume by using the sset option. To set the Master control to 50% of its maximum volume, you can use

$ amixer sset 'Master' 50%

Notice, however, how the output from amixer shown a bit higher up lists two channels, Front left and Front right, on the Master control. You can manipulate the volume of each channel independently. For example, to set the Front left channel volume to 80% and the Front right channel volume to 20%, you can do:

$ amixer sset 'Master' 80%,20%

And so on.

Identifying Hardware

Notice how the dump of the /proc/asound/cards file shown above gives us some information of the hardware. However, you can get more information using aplay with the -l (list) option:

$ aplay -l
 **** List of PLAYBACK Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
 card 0: PCH [HDA Intel PCH], device 1: ALC269VB Digital [ALC269VB Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

In this case, the “card” is an Intel that controls both the internal and HDMI audio cards from one device (card 0). I use the quotes, because a bit of research reveals that the so-called “card” is not a card at all, but an IC (Integrated Chip) that acts as an interface between the true cards and the audio subsystem. The true cards are the ALC269VB shown above (which is a Realtek device), and the HDMI device. This kind of configuration is extremely common in modern Intel-based laptops.

The lspci will tell you whether there is a driver loaded for your hardware. First do:

# lspci | grep -i audio
 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)

to get the device number (00:1b.0). Then use lspci again, along with the -s and -v options to get the information about the drivers:

# lspci -s 00:1b.0 -v
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
   DeviceName: Onboard Audio
   Subsystem: ASUSTeK Computer Inc. Device 1a33
   Flags: bus master, fast devsel, latency 0, IRQ 29
   Memory at df000000 (64-bit, non-prefetchable) [size=16K]
   Capabilities: [50] Power Management version 2
   Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
   Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
   Capabilities: [100] Virtual Channel
   Capabilities: [130] Root Complex Link
   Kernel driver in use: snd_hda_intel
   Kernel modules: snd_hda_intel

The last two lines tell you that the driver assigned to your hardware is snd_hda_intel and that, indeed, it is loaded into the kernel and working.

It is quite common for audio drivers to have the string snd in their name, so when you search the list of modules/drivers loaded into the kernel using lsmod, you can filter the results using grep like so:

# lsmod | grep snd
 snd_hda_codec_hdmi      57344  1
 snd_hda_codec_realtek   90112  1
 snd_hda_codec_generic   86016  1 snd_hda_codec_realtek
 snd_hda_intel           36864  5
 snd_hda_controller      36864  1 snd_hda_intel
 snd_hda_codec          135168  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
 snd_hda_core            36864  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_controller
 snd_hwdep               16384  1 snd_hda_codec
 snd_pcm                135168  5 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller
 snd_seq                 77824  0
 snd_seq_device          16384  1 snd_seq
 snd_timer               36864  2 snd_pcm,snd_seq
 snd                     94208 19 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device
 soundcore               16384  1 snd

… and you’ll notice the word “realtek” pops up several times.


All of the above shows healthy sound systems. In fact it is quite hard to find sound hardware that won’t work out of the box with a modern GNU/Linux distro nowadays. But problems do pop up from time to time, especially with or very new, or very old, or very exotic hardware. However, as usual, there are several things you can do to find out what’s wrong, which is the first step to getting the issue solved.

To summarize, your audio troubleshooting checklist would look something like this:

  1. See if the problem is system wide and not only affecting your desktop by using play (found in the SoX package) from the command line to try and play an audio file.
  2. Look in /proc/asound/cards to find out how many card you have installed (many systems identify more than one) and take note of the number the system has assigned to the one you’re testing (look for PCH for the internal audio system).
  3. Use amixer with the -c parameter to see if the volume on your soundcard is up, and, if it is not, to pump it up. Then try play again.
  4. Still no sound, or some, or all of the above failed? Us lspci to see if there is a driver associated with your hardware. If there’s no driver, that’s your problem.
  5. If there is a driver, but still no sound, you can identify your hardware with aplay -l and then use online resources to ask the community experts.

Yes, I know: the last item is another way of saying “Use Google!”. This is something you had probably already considered. Heck! It may even be how you ended up here. That would be ironic.

But, seriously, the steps I describe above will help you troubleshoot, oh, I don’t know, 80% of problems with sound? And even if they don’t get you all the way to having music pouring out of your speakers, they’ll give you the answers to many of the questions community members will ask you when they try to help.

Cover Image: Saxophone Gold Gloss by Schuetz-Mediendesign for