Talk:Advanced Linux Sound Architecture

From ArchWiki
Latest comment: 5 December 2023 by Yetanothergeek in topic List of bands in Using_mbeq section

Manually reloading settings from ~/.asoundrc

Since the old "sudo rc.d restart alsa" and "sudo alsa force-reload" commands don't work anymore, it took me a bit of time the other day to figure out how to restart alsa without restarting the whole machine. Sometimes I make changes to ~/.asoundrc and want to make them effective without rebooting and this was the only command I found that could acheive this:

alsactl kill rescan

This should probably be added to the wiki somewhere but I wasn't sure where the best spot for it would be. Should it be a new section? There's a few areas of the alsa wiki that just say to "restart alsa" without specifying how to do so. These could probably be updated as well.

Mynis (talk) 10:04, 14 May 2013 (UTC) mynisReply[reply]

One year later, just in case somebody else with that problem gets here: ~/.asoundrc is loaded by the ALSA library, not the kernel part. You can’t actually “restart ALSA” because it is not a daemon—you could reload the driver module but that is not going to have any other effect. ALSA configuration is loaded for each instance of the library, so to reload it, all you have to do is restart the programs that are using it. --Lachs0r (talk) 13:03, 29 May 2014 (UTC)Reply[reply]

Alternatively, run $ alsactl nrestore. -- Alad (talk) 13:29, 10 August 2014 (UTC)Reply[reply]

On high quality resampling

I’m not actually an Arch user and I don’t know what the default configuration is like, but to be honest, I believe the ALSA setup should use the libspeex-derived resampler by default, which offers much better quality than dumb linear interpolation, but without the performance implications of libsamplerate’s best converter.

I don’t think any human being is able to tell the difference between libspeex and libsamplerate’s sinc resamplers because they both have about the same noise floor, which is actually lower than what 16-bit PCM audio can even represent. Thus, using the slower one is completely pointless.

To support my claims, I’ve used the linear interpolation as well as some of the libspeex and libsamplerate converters. The test file was an 8 second 1-22050 Hz sine sweep generated with SoX as 32-bit signed integer PCM with 44.1 kHz sample rate. The output sample rate was 48 kHz, hence the most common conversion by far. The results were obtained by playing the test file through an ALSA rate device with a file device as its slave.

These are the spectrograms of the results: [1]

As you can see, all of these are way better than linear interpolation. The speexrate resampler might look bad at first in comparison to the others, but notice that the visible aliasing lines are actually very close to the noise floor, and certainly not bad enough to be noticeable. Not on this sine sweep, and certainly not on typical audio content. This is not a bad result at all, especially considering how fast this resampler is!

Well, how fast is it? My tests have shown it to be roughly twice as fast as the corresponding libsamplerate resampler, and the trend continues with the higher quality modes:

linear:             0.01s user 0.04s system 0% cpu 8.138 total

samplerate:         0.38s user 0.01s system 4% cpu 8.147 total
speexrate:          0.24s user 0.01s system 2% cpu 8.137 total

samplerate_medium:  0.60s user 0.01s system 7% cpu 8.149 total
speexrate_medium:   0.32s user 0.06s system 4% cpu 8.143 total

samplerate_best:    1.36s user 0.01s system 16% cpu 8.204 total
speexrate_best:     0.79s user 0.01s system 9% cpu 8.166 total

Given these facts, it seems more like the common recommendation of using samplerate_best is based on a cargo cult myth rather than actual testing. --Lachs0r (talk) 13:06, 29 May 2014 (UTC)Reply[reply]

Using subjective and pejorative terms like "placebo-quality" and "cult" that have no technical meaning whatsoever and only flame is highly discouraged. [Sampling] frequency is expressed in hertz, so it should be (in the article) 48000 Hz or better yet 48 kHz (there is a space in between the unit and the value, as suggested by several standards and norms). You used that here correctly, so why not in the article? I would also suggest you create a new page with the results you presented here and please include the exact procedure you used, so that others can reproduce it. Usually one should experiment with different scenarios, so testing several different input audio files, different resolutions and resampling converters with 96 kHz and 192 kHz as output SR would be nice. I appreciate your work, but the form you present it in could be better. --Emeres (talk) 12:26, 6 June 2014 (UTC)Reply[reply]
Oh, I just left the first line of the section intact when I edited it. Yes, should have been 48 kHz. The results when resampling to different resolutions are very similar. The sine sweep was chosen because it shows certain characteristics such as aliasing, quantization noise and so on very clearly in the spectrograms (or actual listening tests), and using different input samples would serve no real purpose for that particular demonstration (hell, even the sine sweep is really hard to ABX with these resamplers). Some other graphs would be worthy additions, but actually that work has already been done by somebody else[2], just lacking the results for the lower quality modes of the Speex resampler (note: on that site, libsamplerate is referred to by its code name “Secret Rabbit Code”). Sorry about the language I’ve employed here and in the summaries for some of my other edits; I was just disgruntled with the state of the Arch Wiki and the fact that I often had to tech support people who just followed some bad/outdated advice given in various articles. I tend to speak my mind in the wrong place when something like that happens. --Lachs0r (talk) 14:26, 6 June 2014 (UTC)Reply[reply]

General Article Cleanup

As stated in the section title, I think this page could use a large cleanup. Currently the troubleshooting section is quite a bit larger than the core article itself, and has some questionable advice, a lack of any sort of ordering, and just a big lack of consistency/concision in general. Just some examples:

Advanced_Linux_Sound_Architecture#Getting_S.2FPDIF_output

Starts off referencing Gnome, when it should probably start the section off with the desktop agnostic method referenced below it. This has been addressed.

Advanced_Linux_Sound_Architecture#No_sound_with_Audigy_2_ZS

This is arguably a bad solution. I'd be surprised if amixer could not accomplish this.

It looks like amixer could be used, but a confirmation from someone, who actually has the hardware would be better:
amixer sset 'Audigy Analog/Digital Output Jack' unmute # or on
Source 1, source 2. The meq note should be expanded why it is relevant for headphones. It does cut in higher frequencies quite a bit, so I guess the author meant 2.0 in comparison to > 4.0, where higher frequencies are often the main aspect of the overall sound. Dmix references need to be inspected. Maybe a configuration like this one should be emphasized, instead of the ever returning pcm.dmixed. The trouble shooting section could use a 'general troubleshooting' subsection on the top. I have a few lines written already, but the default section comes first.
-- Emeres (talk) 21:36, 13 September 2014 (UTC)Reply[reply]
I've owned an Audigy 2, and alsamixer had no problem unmuting the card. Removed the section. -- Alad (talk) 14:48, 25 November 2014 (UTC)Reply[reply]

Advanced_Linux_Sound_Architecture#Using_mbeq

I'm not sure how the note regarding stereophonic sound is relevant.

These are obviously small issues, but the page is full of them. The troubleshooting section could most likely be trimmed down quite a bit just by combining similar problem cases and their respective solutions. Given the state of the troubleshooting section, I wouldn't be surprised if at least a few of the issues are fixed in current ALSA/Linux revisions. --Pyroh (talk) 01:42, 25 July 2014 (UTC)Reply[reply]

I've already gotten started on the most egregious offenses, though there's still quite a
bit to do in terms of converting the page to a consistent writing style. I suppose this post
could be considered a bump, as I don't want to larger changes without some community
consultation. --Pyroh (talk) 02:30, 26 July 2014 (UTC)PyrohReply[reply]
Hi, first of all please take care when removing nowiki tags from templates, I've had to restore some you removed.
Troubleshooting sections tend to become outdated in all articles, so it's very welcome if you try to update this article; it seems you're doing a good job in summarizing all your edits, so it's easy to understand what you're doing.
-- Kynikos (talk) 03:00, 26 July 2014 (UTC)Reply[reply]
Thanks. I initially just removed all of the (nowiki tags) and then changed '1=' to '2=' and vice versa until there were no more Template Error: messages. I assume you are implying that a lack of said error messages are not necessarily indicative of codified text being correctly displayed? I took a quick look over everything and it seemed to look fine, but I might have missed something as I was mainly checking the second portion of {{hc/{{bc references and I saw that you added nowiki tags around only the first portions.
--Pyroh (talk) 07:04, 26 July 2014 (UTC)Reply[reply]
Correct, the fact that you don't see Template Errors does not mean that everything's all right. One frequent case is when the | (pipe) symbol has to be displayed, like in the cases that I've fixed; for example writing {{bc|lsmod | grep snd}} displays:
lsmod 
-- Kynikos (talk) 03:52, 27 July 2014 (UTC)Reply[reply]
The terms of card and device can be easily explained as follows; Card is a singular sound card which has one to many Devices. A multichannel card has a different device for each of the channels so the front, center, rear, and side each have their own device number. It should probably be noted that there is a common problem with having nvidia HDMI audio. The HDMI interface will be set as the default even when adding "options snd_hda_intel index=-2" what instead works is blacklisting the snd_hda_intel. I think the article would be easier to read by using the same card names throughout the article instead of listing specific examples for each section. I'll start working on that since it has been a while since any updates have been made.
Lucid (talk) 15:04, 9 July 2016 (UTC)Reply[reply]

Mention caps package in equalizer section

I tried to follow the System-wide equalizer section (using ALSAEqual), but got the following error:

Failed to load plugin "/usr/lib/ladspa/caps.so": /usr/lib/ladspa/caps.so: cannot open shared object file: No such file or directory

It works after installing the caps package, so I guess it should be mentioned that this package is required. —LucasWerkmeister (talk) 12:36, 17 January 2016 (UTC)Reply[reply]

Set the default sound card - Given advice does not work for me

I tried the settings listed in this section without any success on my Raspberry Pi.

/etc/modprobe.d/alsa-base.conf
options snd_mia index=0
options snd_hda_intel index=1

The order of the sound cards remained unchanged even after a reboot. Can anyone confirm?

PhilippD (talk) 19:23, 26 July 2016 (UTC)Reply[reply]

I had a similar problem. Here is my working modprobe.d config file

/etc/modprobe.d/alsa-base.conf
# Focusrite Scarlett 8i6 & other usb
options snd_usb_audio index=0,1,2 model=auto vid=0x1235,0xb58e,0x0763 pid=0x8002,0x9e84,0x3102
# Intel C220 Audio Controller / HDMI - I don't care about the order of these as they are rarely used.
options snd_hda_intel index=3,4

I needed to specify the indexes, vids and pids, and prefix the ids with 0x. A note on this could go in the wiki if its correct.

--Dodj (talk) 21:38, 6 November 2018 (UTC)Reply[reply]

Replace older "index=" method with newer "slots=" method

“The slots option is especially useful for avoiding the possible hot-plugging and the resultant slot conflict.”

http://alsa.opensrc.org/MultipleCards#How_to_choose_a_particular_order_for_multiple_installed_cards

Markus00000 (talk) 06:02, 14 September 2016 (UTC)Reply[reply]

apulse

Re [3], these packages do not depend on pulseaudio? See [4] or [5]. Note that also both skypeAUR and firefox have pulseaudio listed in the depends, but as optional depends. Thus there's no installation and subsequent activation of pulseaudio.

More generally, apulse is useful to list if you're not interested in using pulseaudio but still want access to application using it directly. Similar to PulseAudio#Installation which lists pulseaudio-alsa for compability with applications using libalsa directly, or Advanced_Linux_Sound_Architecture#OSS_compatibility. -- Alad (talk) 06:22, 16 June 2017 (UTC)Reply[reply]

Hmm, I overlooked that they're just optional deps. Though the other two compatibility layers look like officially supported solutions, but apulse still seems to be a hack. -- Lahwaacz (talk) 07:24, 16 June 2017 (UTC)Reply[reply]
Sure, but it's a legitimate project and we have plenty of unofficial solutions described on the wiki. It doesn't have to be as prominent as Advanced_Linux_Sound_Architecture#OSS_compatibility, but I still think it has a place somewhere in the article. -- Alad (talk) 09:00, 16 June 2017 (UTC)Reply[reply]
I second this. It should be at least mentioned for those coming here looking for compatibility solutions. Can the content be brought back? -- Calimeroteknik (talk) 18:30, 16 June 2017 (UTC)Reply[reply]
Alright, I'm fine with it if it includes a note that apulse is not part of ALSA. Also if it appears in the installation section, it shouldn't be much more than a reference to the project and packages. -- Lahwaacz (talk) 19:16, 16 June 2017 (UTC)Reply[reply]

Enable the microphone

It would be nice to comment that people should try to see if the Capture channel is really turned on BEFORE try to listen it... In my case the channel doesn't accept the 'mute' or 'unmute' commands, just the amixer sset Capture toggle managed to turn it on, and then I could test using what this sessions tells about. Joaoantonicoardoso (talk) 20:27, 16 July 2017 (UTC)Reply[reply]

Restructure/Reorganize default card section

So I've noticed that the most common ALSA default device issue coming up on the boards is that people broke dmix or their configuration in other ways by following the alternative configuration method first and not noticing or understanding the implications of the warning, before trying the less destructive methods via the defaults node or changing the kernel module indexing order. I'm assuming this is because this is seemingly the first section that goes over general device detection/naming identification topics.

But all of these detection methods are applicable to every other way of setting the default card and are applicable to the environment variable as well as the defaults node (... any ALSA config really) and should thus be moved upwards to have a more logical cohesive of how one can manipulate various aspects of the configuration.

Similarly with the identification of the used kernel module, it's referenced earlier several times but actually discussing how it can be identified and what the implications of a loaded sound card driver are comes after the default section, where there's already a reference to the kernel modules for the purpose of manipulating the index order.

I think content-wise most of the sections are fine and they just need to be moved around so that they are in a more logical position with regards to what is going to follow them.

But this would be quite a big change in terms of the current structure so I didn't just want to go ahead and do it and instead gather some thoughts. V1del (talk) 14:12, 15 September 2020 (UTC)Reply[reply]

Seconded. This page's current organization is counter to the de-facto standard of other wiki pages. It seems to me that *every* system needs at least some configuration (some basic /etc/asoundrc or ~/.asoundrc) to function appropriately. Following the format of other wiki pages, this necessary configuration should be put in, or immediately after the Installation section. As it currently reads, this page seems to imply that once installed ALSA is likely to work "out of the box" with no configuration. The basic configuration section that should be near the top of the page need not cover any troubleshooting or less-common cases, that can come later. But it should be clear from the start that some configuration will be needed. Trilby (talk) 15:10, 11 August 2021 (UTC) Trilby 2021-08-11 15:10 UTCReply[reply]

Add pipewire to related articles

Should we add pipewire as a related article? PulseAudio is listed and pipewire can be an alternative.

- ENV25 (talk) 16:13, 4 February 2021 (UTC)Reply[reply]

ALSA, SOF, firmware... confusion!

Recently a new project has born; it is called SOF and it should allow for sound card firmware management. [6]

Probably my statement is wrong or at best, incomplete.

This mess rules, in fact I cannot find any information here on the Archwiki or elsewhere.

I would like to understand what does SOF is/works/...

So we can add it here on the ALSA archwiki page (or create a brand new SOF archwiki).

The problem is born when I learn about my hardware an old XPS laptop model [7] requires a SOF component, as the official wiki states[8].

And I was surprised about it because it is an old hardware, and current information here[9] states only recent hardware needs a such piece of software.

Anywhere, get to the point: I think we should expand the ALSA firmware section and clarify it for newer SOF addition; but the problem is the lack of information (as you can see on the SOF webpage too).

What do you think/propose?

nTia89 (talk) 07:16, 3 April 2022 (UTC)Reply[reply]

It is not recent (see the oldest release of the project) and it is already mentioned in Advanced Linux Sound Architecture#ALSA firmware and Installation guide#Install essential packages. — Lahwaacz (talk) 07:29, 3 April 2022 (UTC)Reply[reply]
Quoting from Installation guide: "[...]specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards),[...]" and from ALSA: "[...]sof-firmware and alsa-ucm-conf are required for few newer laptop models (end of 2019/2020)[...]"
IMHO it is definitively not enough (and wrong since my laptop is 2015, besides)
From a wiki, I expect more or at least a reference where get more information nTia89 (talk) 08:12, 3 April 2022 (UTC)Reply[reply]
I agree that the wording of Advanced Linux Sound Architecture#ALSA firmware is not ideal. IMHO sof-firmware should be mentioned before alsa-firmware and I also doubt alsa-ucm-conf needs to be installed manually (instead of pulled in as a dependency). Perhaps it would be better to suggest installing sof-firmware on all 2015+ Intel systems and 2020+ AMD systems and linking to https://thesofproject.github.io/latest/platforms/index.html.
If Installation guide#Install essential packages needs improvements afterwards, it can be discussed in Talk:Installation guide#Add link to ALSA firmware in the Install essentials packages section.
-- nl6720 (talk) 10:40, 3 April 2022 (UTC)Reply[reply]
I just added the years when I originally added this as that was the time frame where such HW commonly and actively appeared, to the point where every second or so audio problem thread came down to lacking this package. I'd assume such systems from 2015 to have been quite niche at the time. Using years is likely a misnomer anyway and potentially inaccurate, we could add some info to check which driver is detected from dmesg/lspci so that one knows to install that if the system tries to use sof in favor of HDA, I don't have any SoF HW so would have to dig through some threads to get relevant info, feel free to edit relevant information in. "All 2015+ systems" doesn't hold in and of itself either, I still have a laptop with a plain HDA ALC298 iirc and there are many newer boards that use integrated USB buses in favor of I2S/HDA where this wouldn't be relevant. I'd agree with adding actual information to actually check what you need, but I don't have a hands on system and originally added this in the hopes of alleviating some of the repeating support requests we've seen when this came about. V1del (talk) 19:04, 3 April 2022 (UTC)Reply[reply]
I too don't have any affected hardware to test this on. I'm guessing that it should show up in lspci -k | grep -F snd_sof. -- nl6720 (talk) 12:09, 4 April 2022 (UTC)Reply[reply]
It does for me, at least when sof-firmware is already installed. Also I'm not sure if it's best to check kernel modules or the kernel driver. Anyway, here is my output:
00:1f.3 Multimedia audio controller: Intel Corporation Comet Lake PCH-LP cAVS
	Subsystem: Hewlett-Packard Company Device 869d
	Kernel driver in use: sof-audio-pci-intel-cnl
	Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci_intel_cnl
Lahwaacz (talk) 12:26, 4 April 2022 (UTC)Reply[reply]
For example I don't have a such module in use, instead I have this snd_intel_dspcfg... anyway, I underline again the confusion around this topic due to source information lack, not our; nTia89 (talk) 15:47, 4 April 2022 (UTC)Reply[reply]
And what's your kernel driver? — Lahwaacz (talk) 15:57, 4 April 2022 (UTC)Reply[reply]
How can I check it? nTia89 (talk) 15:58, 4 April 2022 (UTC)Reply[reply]
Run the lspci -k command without grep. — Lahwaacz (talk) 16:03, 4 April 2022 (UTC)Reply[reply]
here is:
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
	Subsystem: Dell Device 0665
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
	Subsystem: Dell Device 0665
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
nTia89 (talk) 16:07, 4 April 2022 (UTC)Reply[reply]
That's weird, it does not even show the snd_intel_dspcfg you reported before... — Lahwaacz (talk) 16:18, 4 April 2022 (UTC)Reply[reply]
I know, it's unclear... I do not have any information about SOF in the dmesg , too; and this is the reason why I searched on our wiki but not having found anything useful then I started this topic... nTia89 (talk) 16:29, 4 April 2022 (UTC)Reply[reply]
snd_intel_dspcfg is not an actual driver module, the only way you "have this" if you actively created e.g. a modprobe config with options snd_intel_dspcfg dsp_driver=1 which is used to determine which driver the kernel should use for cards/codecs that actually have both. If you actively set this to 1 you completely disable the SoF framework in favor of the older HDA in which case it not appearing anymore anywhere else if you've set that is not further surprising. Whether you need that or it helps depends on a case to case basis, there used to be a time where sof-firmware was buggy and valid HDA codecs still existed, the more time passes the more this will shift to favor SoF in the cases that this distinction is relevant. And if you do not actually have a line to that effect, then sof-firmware is indeed irrelevant for you and I'd wonder based on which resource you think your system is affected/requiring SoF V1del (talk) 10:07, 12 April 2022 (UTC)Reply[reply]

Little update: this page could be useful for everybody [10]. nTia89 (talk) 15:03, 12 April 2022 (UTC)Reply[reply]

List of bands in Using_mbeq section

In the asound.conf example from the "Using mbeq" section, the comment listing the frequency bands is not quite right. Note that there are 15 entries in the control array, but only 14 bands listed in the comment (the 3500Hz band is missing). Also, the bands shown as 25000hz and 50000hz both have too many zeroes (should be 2500hz and 5000hz).

The correct list should be:

50Hz, 100Hz, 156Hz, 220Hz, 311Hz, 440Hz, 622Hz, 880Hz, 1250Hz, 1750Hz, 2500Hz, 3500Hz, 5000Hz, 10000Hz, 20000Hz

You can verify this info by running the command: analyseplugin mbeq_1197 Yetanothergeek (talk) 01:00, 5 December 2023 (UTC)Reply[reply]