SDB:Audio troubleshooting

Jump to: navigation, search

Tested on openSUSE

Icon-checked.png

Recommended articles

Icon-manual.png

Related articles

Icon-help.png


This guide is intended to help provide basic sound to openSUSE users whose sound does not work at all after a new openSUSE install. This guide is not intended to show how to install codecs.

General

Not all of the steps in this troubleshooting guide will be necessary. Just work your way from STEP-1 to the end, stopping when your audio starts to work.

This guide is written generically. It has the greatest likelihood of helping a user if they do not deviate from the nominal openSUSE packaged drivers; desktop and kernel. That is, if one installs a custom kernel or updates to a factory KDE version (as opposed to remaining with the nominal KDE version), or applies a manufacturer-provided sound driver, there is an increased probability that this guide will not be of help.

Cause

After openSUSE installation, in some cases it is necessary to adjust the audio [1] settings in order to get sound. For some sound codecs, the RPM "alsa-firmware" (which is not installed by default) is needed to provide sound functionality. In other cases where the audio hardware is newer, a more up-to-date version of ALSA is required. Due to the very large number of audio cards on the market, sometimes YaST may not able to configure the card automatically, and hence manual configuration is necessary.

PulseAudio Volume Control

Since openSUSE 11.4, KDE has had PulseAudio installed and active by default. Gnome has had PulseAudio even before then. In such a case, it can be useful for KDE users to install the application PulseAudio Volume Control (pavucontrol) and use that application to tune one's audio for each multimedia application. Gnome users may find pauvcontrol already installed by default. LXDE users will find that they will first need to install PulseAudio (as PulseAudio was not automatically installed in LXDE as of openSUSE 12.1 and earlier), and subsequently install pavucontrol.

To install pavucontrol on openSUSE version 11.4 and later, type "su" (without quotes) followed by the root password to get root permissions in a konsole/xterm. Then, to install pavucontrol, type:

zypper in pavucontrol

After it is installed, type "exit" or press CTRL+D to close the root session. Then, to run pavucontrol, type "pavucontrol". The first time you run each application, tune PulseAudio for that application, ensuring you have each application tuned to use the correct audio device.

ALSA overview

Note that openSUSE ships with ALSA (Advanced Linux Sound Architecture), which is also installed by default. Users are given a chance to configure this during the openSUSE installation.

Installing alsa-firmware on openSUSE-10.3 to 11.2

Starting with openSUSE 10.3, some of the older sound cards also require the “alsa-firmware” package in addition to “alsa” and “alsa-utils”. Thus, before proceeding, ensure that you have “alsa”, “alsa-utils”, and “alsa-firmware” installed. It appears that installing the alsa-firmware package may help users with: asihpi (dspxxxx), ea (gina, indigo, layla, mona), emagic (emi), ess (maestro), mixart, multiface, pcxhr, sb16, vx, yamaha, and some other chipsets.

To see if you have alsa-firmware installed, type in a konsole/xterm:

rpm -q alsa alsa-utils alsa-firmware

and if you get: 

alsa-1.0.14-31.2
alsa-utils-1.0.14-27
package alsa-firmware is not installed

then alsa-firmware is not installed. It is useful for openSUSE 10.3 users — and possibly essential for some hardware codecs — that you install it now. For other openSUSE versions, the ALSA versions will differ slightly.

To install alsa-firmware in openSUSE-10.3–11.2, type "su" (without quotes) followed by root password to get root permissions in that konsole/xterm, and then to install alsa-firmware type:

zypper install alsa-firmware

After alsa-firmware is installed, restart your machine, or otherwise make sure the kernel's sound modules are reloaded, because rcalsasound won't do this itself. Check your sound (see STEP-1 below), and if need be, start the ALSA service with the command below, type in a konsole/xterm:

rcalsasound start

STEP-1: How to test your sound

A simple test to see if your sound works, is to open a konsole or xterm, and type or copy-paste:

speaker-test -Dplug:front -c2 -l5 -twav

Note that Linux is case sensitive, and “D” is not the same as “d”. While the konsole/xterm has mouse focus, hit CTRL-C to stop the test. Note that you should check your mixer settings (alsamixer in the terminal, though graphical programs like kmix may also be used) to ensure that PCM and Master Volume are not muted. If need be, raise the sound levels and retry until you hear sound. Note that the test for surround sound is different.

If that test yields errors, try instead this more simple test:

speaker-test -c2 -l5 -twav

If there is no sound from either test when using a konsole (or xterm) as a regular user, try as user root, i.e. type su and then try the test line. If you get sound with root permissions, but you got no sound as a regular user, then you probably have a permissions problem. See below in Step-6 for how to deal with that. Assuming you have no sound at all, go to step-2 below.

ALSA web site suggestions for testing sound

The alsa-project also has some suggestions for testing one's sound, which are located here: http://www.alsa-project.org/main/index.php/SoundcardTesting

STEP-2: Trying YaST to configure ones sound

- Try to configure your sound with YaST. (Note as soon as you have sound, do not go to the next item, but rather exit and enjoy your sound). To configure your sound go to:

  • YAST > HARDWARE > SOUND > OTHER > TEST and test your sound. If you have no sound then,
  • YAST > HARDWARE > SOUND > OTHER > VOLUME and move your PCM and Master Volume up to about 75% and test your sound. If you have no sound then,
  • YAST > HARDWARE > SOUND and select your audio card and delete it (which deletes the configuration, not the card). If you wish to ensure the sound configuration is completely deleted, you will need to delete the file /etc/modprobe.d/50-sound.conf (with root permissions). Then add the card, and configure the card. That will recreate the 50-sound.conf file. Test your sound. If you have no sound then close YaST and
  • on openSUSE-11.1 or earlier, in a konsole/xterm with root permissions (type "su " (no quotes) followed by root password to get root permissions) type:
alsaconf

and configure your sound. Do NOT try this on openSUSE-11.2. After configuring test your sound, and don't forget to check your mixers (kmix or alsamixer as appropriate).

If there is still no sound, go to step-3.

STEP-3: Checking your audio setup for detailed information

It is often useful to find out more about your sound configuration before proceeding.

Basic Konsole/xterm commands

To find your alsa version, in a konsole/xterm type:

cat /proc/asound/version

To find what sound module(s) you have loaded, in a konsole/xterm type:

cat /proc/asound/modules

To determine the audio codec used by your sound card (and this is important), in a konsole/xterm, type:

cat /proc/asound/cards

and look for your audio codec. For example, if you obtained: 

0 [nForce2        ]: NFORCE - NVidia nForce2
                     NVidia nForce2 with ALC650F at irq 18

Then for this example, we are interested in the ALC650.

Script to run to obtain detailed information

If that does not provide the codec, then another approach to obtain more information on your hardware and your sound configuration, is to run the following script.

First method to run script

The diagnostic script is the one created by user wishie from IRC #alsa. For users with 1.0.17 of alsa or newer, it is included with alsa. To run, copy and past the line below with root permissions:

/usr/sbin/alsa-info.sh

Often the first time you run this script, it will note there is an update available, and ask if you wish to update. Select YES. If you are running this in a terminal/konsole with root permissions, the script will update. Then run the script a second time. When it is complete, it will pass you a URL. Take a look at the contents of the URL, as it passes to you useful information. Also keep a record of the URL provided by the script as it can come in useful for passing to others who are trying to assist you (on one of the forums, or on an IRC channel). Then go to the next step of this guide.

Alternatively, for users with alsa 1.0.16 or older, you need to download and run the script. Do this by copying and paste the line below into a gnome-terminal/konsole) and run:

wget http://www.alsa-project.org/alsa-info.sh

then run the script alsa-info.sh (copy and paste this into a gnome-terminal/konsole):

bash alsa-info.sh

Keep a record of the URL provided by the script as it can come in useful for passing to other's who are trying to assist you (on one of the forums, or on an IRC channel).

Now take a good look at those script pages, and try to determine what audio codec your PC sound hardware has. For example, it might be an ALC650, or an ALC268, AD1986A, STAC9220, etc...

Alternative method to run script

For those who find the above instructions on running the two diagnostic scripts too challenging, then as a regular user try copying and pasting each of the two lines below (one at a time) into an xterm/konsole to both download and run the scripts. Copy the COMPLETE line. The second one (tsalsa) will prompt for root password.

alsa-info.sh

wget -O alsa-info.sh http://www.alsa-project.org/alsa-info.sh && bash alsa-info.sh

Search the alsa site for codec info

Now, armed with that codec information, go to the alsa web site, and do a search to see if there is any relevant information on that codec:

http://www.alsa-project.org/main/index.php/Main_Page

There is a search box on the left hand side of that page (part way down). Lets say your audio codec was ALC268. Then a search for that might indicate:

http://www.alsa-project.org/main/index.php/Special:Search?search=ALC268&go=Go

If, for example, your openSUSE has alsa-1.0.14, from that one can see that there were many updates to the ALC268 between alsa-1.0.14 and alsa-1.0.15, which is relevant in this example case. There may be further updates in alsa-1.0.16.

You can confirm that further by going to the detailed release note for alsa-1.0.15 here: http://www.alsa-project.org/main/index.php/Changes_v1.0.14_v1.0.15_detail or by looking at the alsa-1.0.16 release note: http://www.alsa-project.org/main/index.php/Changes_v1.0.15_v1.0.16_detail

Doing a search on that page will indicate many changes with this new alsa version for ALC268. In that case, one should consider updating to alsa-1.0.16 (see below for hints on updating to alsa-1.0.16).

If after doing those searches, it appears that alsa-1.0.14 (or what ever alsa version your openSUSE has) appears adequate, then it is possible you need to do a custom hand edit to your /etc/modprobe.d/sound file and add a model specification (and jump to Step-5 below). But if update to alsa-1.0.14 appears useful, then go to Step-4 below:

STEP-4: Updating alsa in openSUSE

If updating alsa is deemed necessary, then this can be done either via rpm or via a tarball. As always, the average openSUSE user should typically try updating via an rpm first, prior to trying via a tarball.

Updating alsa via rpm

For openSUSE, the openSUSE alsa packager / alsa developer also packages the latest alsa as openSUSE rpms, in order to help users whose sound is not functioning appropriately, by providing cutting edge sound drivers.

The rpm applications that are typically updated include alsa, alsa-utils, alsa-tools, and libasound2 alsa-firmware. Note alsa-firmware is in the “noarch” section of that rpm URL. In addition, there are ALSA driver kernel modules to update.

It is often easiest to add the URL of the repository noted in the next section to one's package manager, and install the rpm applications through one's package manager.

RPM commands to update alsa for openSUSE-11.0 to 11.2 (various kernels)

Specific examples for various openSUSE versions, and for various kernel versions, with specific zypper commands for openSUSE-11.0 thru to 11.2 are provided here: SDB:Alsa-update

if after rebooting, the rpms installed after following that URL do not help, then there are also daily alsa snapshots packaged and available here: SDB:Alsa-update-snapshot

The examples in the above URL are important, PLEASE check out that link to see the exact rpm/zypper installation commands you need to use. Again, this is IMPORTANT.

Please check out the above noted URL. It provides a link with exact command examples for various openSUSE and various kernel versions. Note also you can check your kernel (before running the above zypper commands documented in the provided link/URL) by typing:

uname -a

To determine your openSuSE version and your system architecture version you can type:

cat /etc/SuSE-release

Also note, for these "cutting edge" alsa rpms to install without dependency problems, you should ensure you have updated to the latest kernel for your openSUSE provided by, and recommended by Novell/SuSE-GmbH. If you chose not to update to the latest kernel, then you will need to modify the zypper commands, making reference to a different repository directory, that supports your PC's older (original) openSUSE-10.3 kernel.

For all openSUSE users, after installing this latest alsa, its easiest to reboot (to reload this updated alsa driver) then again go through all of the previous steps in this page, to see if you can get your sound working under the new alsa. Note one may still not have sound, and you may need to edit your /etc/modprobe.d/sound file (see STEP-5 below), and add a model specification. Also, if the above alsa update restores your sound, then be careful about applying further updates of alsa. The alsa rpms on this web site are very "cutting edge", they are built regularly, and they could have recently introduced bugs that have not been fixed yet. Hence once you get your sound working, you should remove this "cutting edge" multimedia repository (while still keeping the installed rpms).

Updating alsa via tarball

One can also custom compile alsa for their PC by going to the URL below and downloading the alsa tarballs alsa-driver, alsa-firmware, alsa-lib, alsa-utils, and alsa-tools: http://www.alsa-project.org/main/index.php/Download A note of caution, ... this sort of update via a custom compile of alsa from tarball is typically not for new users. Try instead to follow the rpm update method via zypper command, described above.

The readme.txt and install.txt provide instructions for compiling from tarball. In addition, custom installation instructions can also be found on the alsa web site. In our case, for the ALC268, the kernel sound module for this is the: snd-hda-intel (which we learned above when typing: cat /proc/asound/modules ). Searching the alsa site for snd-hda-intel gives this page which provides custom instructions for compiling alsa: http://www.alsa-project.org/main/index.php/Matrix:Module-hda-intel

The same is true for most sound modules. Once alsa is compiled and installed, restart one's PC to load the sound module, then again go through all of the previous steps in this page, to see if you can get your sound working under the new alsa. Note one may still not have sound, and one may wish to modify their /etc/modprobe.d/sound file per the recommendations of the alsa page, or one may wish to try and edit to their /etc/modprobe.d/sound file (by adding a model specification) as noted below.

STEP-5: Add “model” to /etc/modprobe.d/<file> file

To specify the model of your sound card in the /etc/modprobe.d/sound file (/etc/modprobe.d/50-sound.conf on openSUSE-11.2,11.3), you first need to determine what model specification to apply. There is an ALSA-Configuration.txt file on your PC that you can examine (in a directory something like the following, dependent on your kernel version): /usr/src/linux-2.6.22.13-0.3/Documentation/sound/alsa/ALSA-Configuration.txt

There is also an up to date ALSA-Configuration.txt file here: http://hg.alsa-project.org/alsa-kernel/raw-file/5082de4abb26/Documentation/ALSA-Configuration.txt

As of 1.0.19 of alsa, the HD-Audio-Models options are listed in the HD-Audio-Models.txt file.

There is an excellent example how to do this manual configuration here: SDB:Intel-HDA_sound_problems

In our example of the ALC268, you will see: 

ALC268
  3stack        3-stack model
  toshiba       Toshiba A205
  acer          Acer laptops
  dell          Dell OEM laptops (Vostro 1200)
  zepto         Zepto laptops
  test          for testing/debugging purpose, almost all controls can
                adjusted.  Appearing only when compiled with
                $CONFIG_SND_DEBUG=y
  auto          auto-config reading BIOS (default)

Now go into your /etc/modprobe.d/sound file (/etc/modprobe.d/50-sound.conf on openSUSE-11.2) and look for a line that looks something like: "options snd-hda-intel enable=1 index=0" and add a model specification on the end of that line. If you last attempted to configure your sound with "alsaconf" (on openSUSE-11.1 or earlier), its possible there will be no line at all like that, in which case you will need to add a line similar to the example below. For the ALC268 codec, if you clearly have an “acer” or “toshiba” laptop computer, then the choice as to what you can try first is clear. But its still possible one of those will work with your audio, even if your hardware is not that of an “acer” nor “toshiba” and you should iteratively still try those models.

So for example (to use the toshiba model option) add the line to the file: options snd-hda-intel model=toshiba

Save the file, and restart your alsa driver, by typing in a konsole/xterm, with root permissions:

rcalsasound restart

Then test your sound with the sound test provided at the start of this web page. Don't forget to check your mixer is not muting nor blocking the sound.

If that doesn't work, then edit your /etc/modprobe.d/sound file again (/etc/modprobe.d/50-sound.conf on openSUSE-11.2), trying the different options (ie “acer” and “3stack”) being certain to restart your alsa between each edit.

In some of the more complex hardware codec examples, for example the ALC880: 

ALC880
  3stack        3-jack in back and a headphone out
  3stack-digout 3-jack in back, a HP out and a SPDIF out
  5stack        5-jack in back, 2-jack in front
  5stack-digout 5-jack in back, 2-jack in front, a SPDIF out
  6stack        6-jack in back, 2-jack in front
  6stack-digout 6-jack with a SPDIF out
  w810          3-jack
  z71v          3-jack (HP shared SPDIF)
  asus          3-jack (ASUS Mobo)
  asus-w1v      ASUS W1V
  asus-dig      ASUS with SPDIF out
  asus-dig2     ASUS with SPDIF out (using GPIO2)
  uniwill       3-jack
  fujitsu       Fujitsu Laptops (Pi1536)
  F1734         2-jack
  lg            LG laptop (m1 express dual)
  lg-lw         LG LW20/LW25 laptop
  tcl           TCL S700
  clevo         Clevo laptops (m520G, m665n)
  test          for testing/debugging purpose, almost all controls can be
                adjusted.  Appearing only when compiled with
                $CONFIG_SND_DEBUG=y
  auto          auto-config reading BIOS (default)

You need to determine how many jacks your hardware has (take a look) to see if it is applicable to try the 3-stack, or the 5stack, or the 6-stack, or an S/PDIF output interface ... then you may be able to narrow down what options you try, to find the optimal setting earlier.

And then try each of the model options by adding "model= ...... " to the /etc/modprobe.d/sound file (/etc/modprobe.d/50-sound.conf on openSUSE-11.2). Don't forget to restart alsa after each attempt.

Warning! Don't put any backup files of 'sound' (or backups of anything else) in /etc/modprobe.d/ as this would also be read and loaded! Put your backups somewhere else.

STEP-6: How to fix a permissions problem

In some cases user root will have sound, but a regular user will not have sound. Typically this is due to a permissions problem being experienced by the regular user. HAL/ConsoleKit/PolicyKit will automatically grant permission to the user by adding appropriate ACL entries on /dev/snd/* (and other device files) for local logins(you don't want users logging in remotely play sound on your box, really) — console, gdm, kdm. With one exception: xdm lacks PolicyKit support as of Xorg 7.4.

Given that HAL will do this in most common cases, adding yourself to the "audio" group should not be necessary under normal circumstances. If adding to the group is deemed necessary, it can be done with either:

  • YAST » Security and Users » User Management » “select your user” » Edit » Details » Groups » check “audio” and then click on “ACCEPT”

or run as root

usermod -a -G audio yourusername

if you are running openSUSE 12.3 or newer. Otherwise, on openSUSE <= 12.2, run

# usermod -A audio yourusername

The new group membership will be available to processes started from the next login.

STEP-7: PulseAudio problems

Commencing with openSUSE-11.0, PulseAudio was introduced in openSUSE. This initial PulseAudio introduction, created some problems with Gnome users and KDE4 users (KDE-3.5.9 users were mostly unaffected). For guidance on how to deal with some Pulse Audio problems, please refer to

On openSUSE-11.1 and 11.2, PulseAudio works much better.

A possible fix to choppy / skipping sound

The PulseAudio sound server was written to use timer-based audio scheduling instead of the traditional interrupt-driven approach. This is the approach that is taken by other systems such as Apples CoreAudio and the Windows Vista audio subsystem and has a number of advantages, not the least in reduced power consumption, minimization of drop-outs and flexible adjustment of the latency to the needs of the application. However, timer-based scheduling may expose issues in some Alsa drivers. To turn timer-based scheduling off, replace the line load-module module-hal-detect in /etc/pulse/default.pa by load-module module-hal-detect tsched=0

Alternatively, in cases where udvev is used instead of hal, try replacing the line load-module module-udev-detect in /etc/pulse/default.pa by (or adding if that line not present) load-module module-udev-detect tsched=0

In other cases, choppy sound in pulsaudio can result from wrong settings for the sample rate in /etc/pulse/daemon.conf . Try changing the line default-sample-rate = 44100 in /etc/pulse/daemon.conf by default-sample-rate = 48000 and restart the PulseAudio server.

STEP-8: KDE4 Phonon audio problems

Phonon was introduced on openSUSE-11.0 with KDE4, and it can on occasion cause problems. For guidance in dealing audio problems related to Phonon, please refer to the kde.org phonon audio troubleshooting page: http://phonon.kde.org/cms/1032

STEP-9: Determine the order of sound devices

With the advent of video cards with HDMI outputs, a lot of computers now have more than one sound device. If the wrong sound device was configured first, then the sound may be getting sent to the wrong device. While Phonon allows you to determine which sound device should be used "first" in KDE4, not all applications obey this preference, and Gnome users don't have the benefit of Phonon anyways. If this is the case, the easiest thing to do is change the order of the sound devices manually in YAST. The following directions are based on openSUSE 11.2, but are probably the same for any earlier versions too;

First, start up YAST and open up the "Sound" module in the "Hardware" section. If there are multiple sound devices, they'll be listed here. The "Index" column starts at 0 for the first sound device, then 1 for the second, 2 for the third, and etc. In some cases, the wrong device may be set as index 0, which would cause sound problems in many applications.

Sound-order-wrong.jpg

The goal is to have your preferred sound device as index 0 to make sure all applications use it as the default. You can do this by selecting each sound device, then clicking the "Delete" button at the bottom of the window to delete each device's configuration. This changes that device's Index to "Not configured" and moves it to the bottom of the list.

Once they've all been deleted, select your preferred device (the one you actually want to hear sound from) and click the "Edit" button to configure it. If it was already configured automatically during openSUSE installation, then choosing "Quick automatic setup" in the next window should work fine. Once configured, that device will be at index 0 and at the top of the list. You can choose to leave any other devices un-configured, or you can configure them too in case you ever intend to use them. In my case, I don't ever intend to use my video card's HDMI audio output, so I left it un-configured.

Sound-order-right.jpg

If you're not sure which device is the one you want first on the list, then try each one at index 0 until it works, one at a time. You may have to log out and log back into your account to make sure the changes were successfully applied after each attempt.

Intel HDA chipset

When you use the built-in audio of your Intel Haswell processor the default audio order is first HDMI and then "PCH" (analog). Changing the order via the OpenSuse 13.2 Sound configuration of the Yast Control Center probably will not work as Yast will try to set the order using:

options snd slots=snd-hda-intel,snd-hda-intel

To fix this, open /etc/modprobe.d/50-sound.conf and change it to:

alias snd-card-1 snd-hda-intel
alias snd-card-0 snd-hda-intel

options snd-hda-intel id=PCH index=0
options snd-hda-intel id=HDMI index=1

For the "id" to use, see the output of "aplay -l".

Configuring the microphone

Careful attention should be applied to the settings in one's mixer when trying to use the microphone. In KDE typically "kmix" is the mixer, and in gnome typically "alsamixer" is the mixer. For further guidance on testing one's microphone, check out Microphone

Configuring a bluetooth headset

For openSUSE-11.1 users, here is a guide for configuring your bluetooth headset with openSUSE-11.1: SDB:Bluetooth headphones

Configuring USB headphones

KDE3 users can following the following to obtain guidance for configuring their USB headphones: SDB:USB_headphones KDE4 steps may differ.

Configuring a laptops multimedia keys

One approach to providing basic functionality in a laptop's multimedia keys (such as volume up, volume down) can be implemented by the application Keytouch (packaged by Packman packagers for openSUSE) adding calls to the alsa application amixer. There is a guide with an example how to do such a configuration here: http://akoskm.blogspot.com/2009/01/laptop-extra-keys-howto.html and a wiki under development: SDB:Keytouch

Determining which application is using sound device

Sometimes, when one has basic sound functioning, but then it appears to stop in the middle of a session (to be restored after a reboot) it may be because an application has seized your audio device, and the application is not sharing nor letting go the audio device. To determine what application is using one's sound device, copy and paste the following into a terminal or a konsole:

lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*

If one runs the above line at different times, when one's sound is working and not working, one can learn better as to what the output means, and be better able to " point one's finger " at the offending application that has seized the audio device.

ALSA driver documentation

One can read up on the technical aspects of alsa by installing the rpm "alsa-docs" and then copying into one's web browser: file:///usr/share/doc/packages/alsa-docs/index.html

Some magic

to test your sound from command line

aplay -vv /usr/share/sounds/alsa/Front_*

to test the microphone

arecord -d 10 myrecording.wav

and

aplay -vv myrecording.wav

to check the recording.

External links

Retrieved from "https://en.opensuse.org/index.php?title=SDB:Audio_troubleshooting&oldid=130184"