ALSA Configuration

From Elvanör's Technical Wiki
Jump to navigation Jump to search

PulseAudio

  • On recent systems PulseAudio works well and avoids the configuration of ALSA (which is way too complex). Thus as of 2020 it is recommended to actually install and use PulseAudio.
  • Microphones also seem to work out of the box, but it may be needed to click on the "Record all audio via this device" in the KDE interface. It also seems the volume is automatically adjusted by some applications (in order to reduce noise?).
  • It's important to add your user to the audio group (at least on a OpenRC setup). Else you can have some strange issues such as audio devices not appearing, or disappearing after a unplug / replug.

ALSA

ALSA (Advanced Linux Sound Architecture) is the new Linux sound system, replacing the deprecated OSS. ALSA offers advanced features such as software mixing for audio cards that don't support hardware mixing. It is thus important to get it properly working.

Kernel Configuration

  • On newer systems (especially laptops apparently), you need to include SOF (Sound Open Firmware) support to get the sound card up and running. For that, emerge sof-firmware package and include the correct files on your manually built kernel (via the usual firmware inclusion mechanism). Getting the correct firmware files can be difficult; the best way is to emerge a binary built kernel, reboot and look at dmesg which will list the SOF firmware files that have been loaded.
  • Kernel configuration for SOF can be a bit difficult and can require several tries (again make sure it is working correctly with a binary built kernel before attempting to get a manual one to work). For a Lenovo Yoga 9i Slim model, the important options were:
ALSA for SoC audio support -> Sound Open Firmware Support -> SOF Support for AlderLake (choose your correct Intel version)
ALSA for SoC audio support -> Sound Open Firmware Support -> SOF support for HDAudio codecs
ALSA for SoC audio support -> Intel Machine Drivers -> Skylake+ with HDA Codecs
HD-Audio -> Build HDMI/DisplayPort HD-audio codec support (very important as the previous option depends on this one)
  • Intel ASoC SST drivers and Intel AVS driver were not needed for this model. However, a kernel command line parameter was needed (snd-sof-intel-hda-generic.hda_model=alc287-yoga9-bass-spk-pin, or snd-sof-intel-hda-common.hda_model=alc287-yoga9-bass-spk-pin for older kernel versions, like 6.6).
  • If you have an Intel HDA soundcard (very frequent), you need to build the correct codec on the kernel. Running alsamixer usually gives you the codec used on your card. Without the correct codec, the soundcard will not work.
  • UPDATE: alsamixer can give a wrong codec it seems (or a codec name that is not clear). In that case the best method is to enable ALL codecs at first, then run alsamixer which will give you a different codec name (the right one). You can then disable the unneeded ones.
  • On Gentoo, if you compile the ALSA driver directly in the kernel (not as module), you may need to edit /etc/conf.d/alsasound to change some settings in order to avoid a warning at boot saying that the driver cannot be found / loaded.

Installation

Recent systems

  • For recent systems, everything seems to work better "by default". ALSA is automatically pulled in via the USE flags. dmix is activated, sound apps just work without any configuration. The only thing needed is to get the correct kernel setup (see previous paragraph).
  • dsnoop is not yet active by default! This means that recording on the default input source may not work out of the box.

Obsolete information

  • The first step is to follow the official Gentoo ALSA guide to get ALSA basically installed and working. The ALSA sources are now included in the kernel, which is very nice. In the normal case, it just consists of running:
emerge -a alsa-utils
rc-update add alsasound boot

Multiple cards

  • I have encountered a problem when multiple cards are detected by ALSA, as then the default settings won't work for some applications (sound will be sent to a wrong / not working sound card). The easiest fix is to disable the problematic card. If you have ALSA modules statically compiled into the kernel, you must use the following boot options (this should go into GRUB configuration, or if you are using UEFI, directly into the kernel boot parameters):
snd_hda_intel.enable=0,1
  • Sample working configuration with two cards (one PCH and one HDMI):
pcm.!default {
        type plug
        slave.pcm "mixPCH"
        hint {
                show on
                description "Default Sound (either PCH or HDMI), via dmix"
        }
}

pcm.myHDMI {
        type plug
        slave.pcm "mixHDMI"
        hint {
                show on
                description "HDMI Sound Output"
        }
}


pcm.mixPCH {
        type dmix 
        ipc_key 1234
        slave {
                pcm "hw:PCH"
                period_time 0
                period_size 1024
                buffer_size 8192
                rate 44100
        }
        bindings {
         0 0
         1 1
        }
}

pcm.mixHDMI {
        type dmix
        ipc_key 1234
        slave {
                pcm "hw:HDMI,7"
                period_time 0
                period_size 1024
                buffer_size 8192
                rate 44100
        }  
        bindings {
         0 0
         1 1
        }  
}

pcm.hwHDMI {  
    type hw  
    card 0
    device 7
}

HDMI

  • To get HDMI output, it is necessary to have the correct kernel modules compiled. You can check if your HDMI card appears with aplay -l or aplay -L.
  • Once it appears in the list, you can check with amixer contents -c1 (for card #1) if an HDMI cable is connected. But it is very important to understand that just plugging in the cable will NOT update the results of amixer contents (or the value of /proc/asound/cards/1/eld#0.0 for instance). It seems necessary to actually activate the HDMI display via video to get sound. Thus, for instance in KDE, you must go to System Settings -> Display and activate it. Note that Ubuntu this process seems to happen automatically (maybe via polling?), so there would probably be a way to improve this process and even to get it working without actually sending video output to the monitor (for instance if the computer is just connected to an audio receiver / amplificator).
  • With a laptop, on the Configure Audio Devices panel of KDE, I had to change the Profile to be able to switch to HDMI output rather than analog output / integrated speakers. It worked with the Digital Stereo (HDMI 2) Output + Analog Stereo Input choice, but not with Digital Stereo (HDMI) Output + Analog Stereo Input.
  • Also note that the ELD values necessary for ALSA are parsed from the monitor's EDID value. So with audio HDMI, the video driver plays a very important part. If it is buggy, the system / ALSA won't know about the HDMI audio output.

USB headsets or microphones

  • You need to compile ALSA support for USB devices in the kernel. After that it will appear as a separate sound device in alsamixer for instance. Be careful that many USB devices (such as webcams) also provide sound recording, so you may end up with quite a few sound devices on the system.

Configuration

  • A good way to test out is via the speaker-test command. It is used as such:
speaker-test -c 2 -D myHDMI

The argument after -D (myHDMI, here) is the PCM name defined in asound.conf. Note that sometimes it can fail because of the requested rate (if it does not go through a type plug module, which performs autoconversion).

  • After that, you need to get dmix working, both for ALSA and for OSS (through ALSA emulation). dmix is a plugin to get software sound mixing. Follow this guide on the Gentoo Wiki. Be careful so that you get dmix working correctly with OSS, else some important applications using OSS (Firefox) won't work properly with ALSA applications (Amarok). On AMD64, make sure the 32-bits ALSA emulation libraries are new enough (last section of the wiki).
  • Note that since version 9, Flash Player uses ALSA. There is no more reason to setup Firefox to use OSS. By the way, Firefox by itself does not know at all about sound.
  • To get audio recording working correctly, you need to unmute levels correctly in alsamixer. You also need to choose the correct input sources. In alsamixer, type tab to get to the capture PCMs, else you don't see them in the basic view. Make sure everything is setup correctly and unmuted. You can then test if your microphone is correctly working by running the command:
arecord -f cd -d 2 -t wav -N test.wav

Be careful to specify a record source such as (hw0:0). Sometimes the default record source will not work.

  • IMPORTANT: you need to set to "Capture" your correct source. This means the word CAPTURE in red should appear below, not "----". To toggle the capture status, hit the space bar. If you don't do that, the mic will be unmuted but the computer won't capture/record the sound.
  • If you use dmix, to record correctly you need to setup the asym plugin and the dsnoop plugin. dsnoop is for input what dmix is for output, eg it should mix several input sources into one. I don't think it is as useful as dmix (the really important thing is to have the asym plugin setup), however I've configured it on my system. For Skype to work with dsnoop you need to add some magic values to your /etc/asound.conf file, as shown below.
  • My sample asound.conf file:
# etc/asound.conf:

# We route OSS through dmix

pcm.dsp0 {
    type plug
    slave.pcm "duplex"
}

ctl.dsp0 {
     type plug
     slave.pcm "duplex"
}

# This is just an alias for hw:0,0

pcm.sound_card {
     type hw
     card 0
     device 0
}

# We route everything through the asym plugin by default

pcm.!default {
     type plug
     slave.pcm "duplex"
}

pcm.duplex {
        type asym
                capture.pcm "input"
                playback.pcm "output"
}

# Dmix plugin

pcm.output {
     type dmix
     ipc_key 1024
     slave.pcm "sound_card"

     slave {
          # This stuff provides some fixes for latency issues.
          # buffer_size should be set for your audio chipset.
          period_time 0
          period_size 1024
          buffer_size 8192
     }

     bindings {
          0 0
          1 1
     }
}

# Dsnoop plugin

pcm.input {
        type dsnoop
                ipc_key 1133
                #slave.pcm "sound_card"
                slave {
      # "Magic" buffer values to get Skype audio to work
      # If these are not set, Skype recording (microphone) WILL NOT WORK.
                pcm "sound_card"
                period_size 256
                periods 16
                buffer_size 16384
                }
        bindings {
        0 0
        1 1
        }
}
  • For Wine to work correctly with ALSA, you apparently need to change some sections, reproduced below:
ctl.!default {
        @args [ CARD ]
        @args.CARD {
                type integer
                default 0
        }

        type hw
        card $CARD
}

pcm.!default {
        @args [ CARD DEVICE ]
        @args.CARD {
                type integer
                default 0
        }
        @args.DEVICE {
                type integer
                default 0
        }
        type plug
        slave.pcm "duplex"
}

Note that it is very important that the ctl.!default has only the CARD argument, and that the pcm.!default has both CARD and DEVICE.

ALSA Input Sources

  • They are located at the end of the playback view. Be sure that the Input Source (the first one) is set to whatever you need. You can switch sources by pressing the 'w' or 'x' keys.

ALSA Mixer Levels

  • Everything marked as IEC958 is for digital sound output / input. You usually don't need this.
  • Analog Mix is *not* necessary for recording with a microphone.

asound.conf

  • If you add "!" before a PCM name, it means to override the previously defined PCM (instead of, by default, merging it). This is useful for the generic, defined PCM names such as "default". More information here.

Sound Frameworks

Phonon

  • Because of a bug in Phonon (present in phonon-4.4.x), the Xine backend does not access correctly the dmix (default ALSA) device. Thus until that bug is resolved it is mandatory to use the gstreamer backend in Phonon (or use PulseAudio).
  • Bug link.
  • With current Phonon version (0.8.3), it seems that choosing a source in System Settings does not work correctly. It seems that the "!default" ALSA channel is always used. Also note that KDE / Phonon updates the list available in System Settings, but in a rather strange way (sometimes added configured channels do not appear, if they are not correct, sometimes they don't appear at all).