ALSA Configuration: Difference between revisions
Jump to navigation
Jump to search
(→ALSA) |
|||
(12 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= 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 = | ||
ALSA (Advanced Linux Sound Architecture) is the new Linux sound system, replacing the deprecated OSS. | 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 [http://www.gentoo.org/doc/en/alsa-guide.xml 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: | * The first step is to follow the [http://www.gentoo.org/doc/en/alsa-guide.xml 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: | ||
Line 10: | Line 37: | ||
rc-update add alsasound boot | rc-update add alsasound boot | ||
* If you have | == 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 | |||
* [http://alsa.opensrc.org/MultipleCards Interesting link] with lots of information about multiple cards configuration. | |||
* Sample working configuration with two cards (one PCH and one HDMI): | |||
<pre> | |||
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 | |||
} | |||
</pre> | |||
== 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 == | == USB headsets or microphones == | ||
Line 21: | Line 118: | ||
== Configuration == | == 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 [http://gentoo-wiki.com/HOWTO_ALSA_Complete_%28includes_dmix%29 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). | * 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 [http://gentoo-wiki.com/HOWTO_ALSA_Complete_%28includes_dmix%29 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). | ||
Line 157: | Line 260: | ||
* Analog Mix is *not* necessary for recording with a microphone. | * 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". [http://www.alsa-project.org/alsa-doc/alsa-lib/conf.html More information here.] | ||
= Sound Frameworks = | = 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). | * 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). | ||
* [https://bugs.kde.org/show_bug.cgi?id=194902 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). |
Latest revision as of 18:50, 20 September 2024
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
- Interesting link with lots of information about multiple cards configuration.
- 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).