Talk:Advanced Linux Sound Architecture

From ArchWiki
Jump to: navigation, search

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) mynis

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)

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

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)

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)
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)

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)
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)

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)

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)Pyroh
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)
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)
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)
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)

Adding a brief section on terminology

This article seems to assume that readers are familiar with many of the terms and concepts used by ALSA. For example, this page extensively uses the term "PCM," but never defines it. I propose we add a short section called "Terminology" to the beginning of this page. Some points of interest might include:

  • What is a "PCM"? And what does it stand for?
  • How does a "card" differ from a "device"? (The amixer program suggests they are not synonymous.)
  • Is a "device," in the context of ALSA, in fact a device in the context of Linux (i.e. a block/character special file located in /dev)?
  • What is a "mixer"? Is it a "device" itself, some kind of pseudo-device, or something else entirely?
  • "S/PDIF"?

I'm not suggesting that we recreate the entire ALSA documentation here, but rather that we define some of the terms used by this article, in order to make the article more approachable by readers who are not necessarily familiar with the language and concepts of ALSA. Thoughts? EscapedNull (talk) 13:26, 24 October 2014 (UTC)

I second the need to explain the non-obvious terms used in the article, however if this could be addressed through simple external links anchored at the proper keywords, it would be the best solution. For example PCM and S/PDIF are not specific to ALSA, and a link to e.g. their Wikipedia articles would be a cleaner solution. About the rest, I admit I haven't done any searches to see if ALSA's docs can be linked to specific sections that explain the concepts in details; if really it wouldn't be possible, I'd still like to avoid a "Terminology" section, whose expansion limits would be very unclear, and instead I'd suggest explaining the concepts (e.g. how a "card" differs from a "device") where they first appear in the article. -- Kynikos (talk) 02:55, 25 October 2014 (UTC)
Thanks for the feedback. That solution sounds good to me. I'll skim over the ALSA documentation as well as Wikipedia to see if I can find some of the appropriate links. I'm afraid, however, that I'm not qualified to handle some of the more detailed tasks (i.e. "card" vs "device"). After all, that's why I asked. I'll begin by outlinking some terms that have a suitable page elsewhere, and leave the structure to be modified by those who understand ALSA a little better.
Additionally, I'm not sure how much of this article also applies to other sound infrastructures, such as OSS and PulseAudio, as I've never used anything else. With that being said, I wonder if it would be beneficial to move some of the broader topics to Sound or the like. That may have to be a project for another day, however. EscapedNull (talk) 13:17, 25 October 2014 (UTC)
If you feel a section is lacking some details but you can't fix it yourself, fell free to mark it with Template:Expansion with a proper reason message.
About splitting generic content, I'm not sure either, but it would certainly require a separate discussion with a more specific plan.
-- Kynikos (talk) 03:31, 26 October 2014 (UTC)

Split up article into Main/Troubleshoot sections and reorganize Troubleshooting

Lets move the Troubleshoot section to a new https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture/Trobleshooting section and reorganize the Troubleshoot section similar to https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting I can do it, but I would prefer to do everything in one step, otherwise I loose focus on too many commit changes. Btw. should we add https://wiki.archlinux.org/index.php/Pro_Audio to "Related Articles"? --T.ask (talk) 16:19, 18 December 2014 (UTC)

+1 for moving Advanced Linux Sound Architecture#Troubleshooting to Advanced Linux Sound Architecture/Troubleshooting. I'm not sure what you mean with "one step", but to help you not lose focus, I've taken the chance to finally create a page with check lists when performing complex operations: you are interested in Help:Procedures#Split section to a new subpage.
About the link to Pro Audio, there's already a link to Sound system in the Related box, which in turn does link to Pro Audio, but I wouldn't have objections if you added a direct link to Pro Audio also from this very article.
-- Kynikos (talk) 01:45, 20 December 2014 (UTC)

Usage of "Advanced Linux Sound Architecture ...X..Y..Z..." lowers readability

Please, use the well known abbreviation ALSA inside the article/for references. It's already difficult enough to read this page. Instead of using long names as "Advanced Linux Sound Architecture/Example Configurations" or " Advanced Linux Sound Architecture/Troubleshooting" please use short and easy readable "ALSA Configurations" and "ALSA Troubleshooting" instead. The term ALSA is widely used AND known in written and spoken terms. Besides, who would enter "Advanced Linux Sound Architecture/Example Configurations/Troubleshooting" or it's words as a search term?! It's fine once for the main article. Please, don't make it more complicated as it already is. --T.ask (talk) 16:07, 10 March 2015 (UTC)

I couldn't find any links in this page using the full title, except for the two in the related box, is this meant to be only a generic reminder? — Kynikos (talk) 03:23, 12 March 2015 (UTC)
Yes. I just read that its probably not possible to flip the current wording. If we can change it, then I would suggest to flip the wording for those three entries. --T.ask (talk) 12:59, 12 March 2015 (UTC)
It does not matter how long the titles are, redirect pages such as ALSA/Troubleshooting can be used for references where long titles are not desired. It's just a matter of using them...
In the "Related articles" box, I don't know if it's better to use redirects with more readable title or the full name, making it clear that the target is a subpage of the main page. I've recently applied the latter choice, but I'm open for discussing it further.
-- Lahwaacz (talk) 13:12, 12 March 2015 (UTC)
I too prefer the full title in the related box for the same reason, while in the body of the article it's indeed better to use the short redirect. Do we need to keep this discussion open? — Kynikos (talk) 13:23, 13 March 2015 (UTC)

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)