Arch Linux

scot

Member

Registered: 2017-04-22

Posts: 23

ALSA wiki ==> very basic ALSA/Pulseaudio confusion

I have become so confused as a result of reading https://wiki.archlinux.org/index.php/Ad … chitecture that I'm not even sure any more *if* I have a problem . So here, I would like to ask for confirmation of my current understanding of just a few basic facts. If what follows is correct, I will add just a sentence or two to the wiki article I just cited; I believe just a few clarifications there will reduce drastically the number of new threads in this section of the bbs.

Please confirm: If a user installs  ALSA and then PulseAudio, then the default ALSA soundcard will in fact be "pulseaudio". In effect, without any other modification, installing pulseaudio on top of ALSA causes many of the the user-visible functionality that ALSA provides to be in fact implemented by pulseaudio.

Please confirm: One example of this is saving and restoring the state of the audio system. For example, it is normal that if one installs ALSA and then pulseaudio, the BOTH alsa-state.service and alsa-restore.service will fail. This is because that function (of storing and restoring system state) is done by pulseaudio, and not ALSA (as a result of installing pulseaudio).

Please confirm: In fact, if one installs both ALSA and then pulseaudio, there will not be any file /var/lib/alsa/asound.state.

And finally, a question: From the bbs here I learn of the existence of a service alsa-store.service, which seems to be the "sister service" of alsa-restore.service. But I do not have this service on my machine. Is that a sign that something was incorrectly or incompletely installed? Thanks.

Thanks for confirming or anti-confirming the above assertions!

(If you're curious as to what my issues with the ALSA wiki article are, one example is the paragraph called "ALSA and Systemd".  The main body of this section - which is four sentences long - is correct but thoroughly misleading. The two services alsa-state.service and alsa-restore.service are indeed installed and activated during installation, and the user need do nothing. And the user can check their status using systemctl. Of course, if the user does this, she will find that the service is always dead and always failed. (once pulseaudio is installed). And in fact, since neither service ever actually ran even once, the specially-emphasized "Note:" in this paragraph is false.

Call me a noob if you will, but someone who is seeing some very subtle low-level errors might well decide to start reading the basic documentation from the beginning. The questions above are the result of the differences between that documentation and reality.

Thanks in advance for confirmations (or corrections) and the answer.

scott

Last edited by scot (2019-05-09 08:14:12)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,659

Re: ALSA wiki ==> very basic ALSA/Pulseaudio confusion

Please confirm: If a user installs  ALSA and then PulseAudio, then the default ALSA soundcard will in fact be "pulseaudio". In effect, without any other modification, installing pulseaudio on top of ALSA causes many of the the user-visible functionality that ALSA provides to be in fact implemented by pulseaudio.

No. The default ALSA soundcard remains on the default of hw:0 (this distinction is mostly important for applications that do not have a direct pulseaudio backend and use ALSA's library instead) . When you install pulseaudio-alsa however a configuration will be set up in /etc/asound.conf that will make this true. The second part of the sentence is correct to some degree, as pulseaudio will take over control of the sound cards and provide these functionalities.

An important notion in this regard, that seems to confuse people to no end: When talking about ALSA there are two components you have to think about, the actual kernel drivers that provide you with audio support for your hardware, and alsa-lib an userspace library applications can use to have abstracted access to these kernel drivers. Pulse plugs into the kernel driver layer and for most intents and purposes replaces ALSA's userspace. What you are configuring in asound.conf and co is the behaviour for the userspace ALSA component. For the few applications not yet providing native pulseaudio support pulseaudio-alsa (or rather the pulse plugin of alsa-plugins)  will wrap alsa-lib calls to pulse.

Please confirm: One example of this is saving and restoring the state of the audio system. For example, it is normal that if one installs ALSA and then pulseaudio, the BOTH alsa-state.service and alsa-restore.service will fail. This is because that function (of storing and restoring system state) is done by pulseaudio, and not ALSA (as a result of installing pulseaudio).

Yes, both will fail, but no pulseaudio has nothing to do with this, first off, they are mutually exclusive, for mutually exclusive usecases (alsa-state enables a daemon that constantly keeps track of volume changes, alsa-restore loads them once at boot and saves them once at shutdown), and both usecases require some prior and conscious alsactl action to have taken place the default would indeed not run either. Regardless all of that should happen before pulseaudio is started. However the impact they have will be minimal, as relevant volume adjustments will be redone by pulseaudio according to it's own database. Either way you should look at the information of the status output, as reason for failure will be clearly indicated.

Please confirm: In fact, if one installs both ALSA and then pulseaudio, there will not be any file /var/lib/alsa/asound.state.

Nothing to do with pulseaudio, everything to do with how you've configured it. That file will be read and updated by alsa-restore if it exists, which will AFAIK only be true  if you've manually ran alsactl store at some point, regardless of whether you run pulseaudio or not, and reloaded on reboot.

And finally, a question: From the bbs here I learn of the existence of a service alsa-store.service, which seems to be the "sister service" of alsa-restore.service. But I do not have this service on my machine. Is that a sign that something was incorrectly or incompletely installed? Thanks.

That might've been true in an older time, however right now alsa-restore.service should handle both, re- and storing of asound state.

(If you're curious as to what my issues with the ALSA wiki article are, one example is the paragraph called "ALSA and Systemd".  The main body of this section - which is four sentences long - is correct but thoroughly misleading. The two services alsa-state.service and alsa-restore.service are indeed installed and activated during installation, and the user need do nothing. And the user can check their status using systemctl. Of course, if the user does this, she will find that the service is always dead and always failed. (once pulseaudio is installed). And in fact, since neither service ever actually ran even once, the specially-emphasized "Note:" in this paragraph is false.

As aluded to earlier, I agree a clarification should be made regarding the mutual exclusitivity of the two files. However  pulseaudio should not have any influence at the stage these two files are potentially run, so the fact that both of them have failed, does not make any statement over whether there's a conflict with pulseaudio.

However of the two service files, if alsa-state.service is the one that runs (if it runs and manages to start alsactl), then you do have a conflict with pulseaudio, as alsa-state will open alsactl in daemon mode. So now you would have two daemons both actively trying to change sound state.

In general, you are assuming pulse to have way more effect on ALSA handling than it has. While it is generally a good idea, especially regarding sound states, to keep to one "sound state provider" during runtime (if you are using pulse contol your state using pulse, if not alsamixer/amixer) pulseaudio just by itself, cannot possibly have any effect on any static ALSA configuration you are making. It does not touch any of these files itself and even if it would, as pulse should normally run in your user's context it will literally be prohibited from doing so because your normal user should not have write access to the directories and files you are mentioning.

Also is this really just wiki clarification, or do you have an actual underlying issue here? You might want to post about that if you actually have an issue. If you actually want to use pulseaudio you should in most cases be able to ignore the ALSA article and focus on the pulse one instead.

Last edited by V1del (2019-05-09 15:41:08)

scot

Member

Registered: 2017-04-22

Posts: 23

Re: ALSA wiki ==> very basic ALSA/Pulseaudio confusion

Thanks for all that, I  truly appreciate it. It's unfortunate that I'm not sure I am now clarified. My "underlying" issue is that both also and pulse seem to half work, in ways that are  incomprehensible to me, nothing really works as described in the wiki, and the result is a spaghetti of such complexity that I'm more depressed than annoyed. My example above about the four sentences on alsa-state and alsa-restore are just tiny examples of an overwhelming problem. I started reading the wiki on alsa, and reading down, I read about these services alsa-state and alsa-restore, and that I could check their status. I did so and found that both are dead. The reason? In one case because /etc/alsa/state-daemon.conf doesn't exist and in the other /var/lib/alsa/asound.state doesn't exist.  What are these files? why don't they exist? what is their format? Is the reason things dont' work because these two basic services have failed? Not at all of course, because now i know that they are not very important in the grand scheme of things. But I didn't know that when they were mentioned as the two  services whose status i could check when i read the wiki. 

But thanks for your reply, If i can ever get handle of something reproducible, i'll post a specific question. Until then, i'll just have to suffer with the exceedingly poor sound experience I am getting (when it works at all).