... Read PulseAudio under the hood from Victor Gaydov.

It covers pretty much every topic you can think of, answers a lot of questions you may have and issues you could come across. Here is the table of contents:Happy reading!

I think if you REALLY want to understand, you'd have the analyze the brain of one of the greatest minds of our time... The brilliant, great, genius, Herr Lennart Poettering. ALL HAIL! WE'RE NOT WORTHY! WE'RE NOT WORTHY!

1 members found this post helpful.

All sound answers are welcome, pointless rants are not.

PS The duplicate post is a bug of the forum software, if I edit one of the posts the other one gets edited identically. That's the second time it happens to me.

8 members found this post helpful.

All sound answers are welcome, pointless rants are not.

PS The duplicate post is a bug of the forum software, if I edit one of the posts the other one gets edited identically. That's the second time it happens to me.

8 members found this post helpful.

Stumbled upon this unofficial additional documentation some time ago and mentioned it recently:
https://www.linuxquestions.org/quest...2/#post5943623

A pity that it doesn't cover the module options and syntax examples, that's where the most usability problems appear. But it does a great job in explaining the theoretical (in practice some components do not work) structure and functionality of this "wannabe" audio system.

The introduction & final thoughts parts are beautiful:
Not in all ... worth to remember

1 members found this post helpful.

First of all thank you Didier for posting this as I'm sure many would gain from easy access to deeper information to understand Pulseaudio better. For myself, I really dislike Pulseaudio... A LOT! it has made me go to curse-ridden, hair-pulling lengths to first try to like it and then to get rid of it, but that naturally does not extend to you or anyone who finds it useful.

My first "bone to pick" is that it's becoming a very often required default when it does nothing for me that JACK Connection Kit cannot do and with a lot less overhead as well as the ability to easily turn JACK off when I don't need nor want it. So far the biggest offender in terms of extra added work for me is Firefox which apparently could easily work just fine with ALSA with a single line of code set to "enabled" and on top of that ALSA (or some sound server like it) is still required by Pulseaudio for it to have anything to manage as it cannot interface directly with audio hardware.

The second issue which is entirely philosophical and quizzical is why should Pulseaudio even require deeper understanding when it's whole raison d'etre is to "manage sound for you" and sidestep the complexity of some ALSA setups? I'm afraid I find Pulseaudio to be very much like and even more offensive to me that systemd but both of them seem very non-Linux to me in that they offer very little gain (and in some cases like mine, an actual performance loss) for a lot of extra work and vulnerability. I truly do not understand why the Linux community embraces such Draconian software that demands to be the sole survivor (My Ball, My Rules) driving out the whole idea of options which gives Linux it's versatility at the slight cost of what some consider to be "too many options". I don't want Free Windows or Free OSX where "free" refers to cost. I want the damned freedom and Pulse is one piece trying to diminish that and it makes me sad and angry.

I am glad that it is useful and even helpful to some but why can't that simply be an option like almost everything else in Linux?

4 members found this post helpful.

Yes. This is particularly handy in laptops which have Intel HD audio (i.e. the great majority of them). Without PA, the user needs to create a special set of udev rules before sound will work. With PA, it just works.
The maintainer of your favourite distro publishes a special set of packages which enable you to entirely remove it within a few minutes... How much more optional does it need to be?

Incidentally, what are your thoughts on NetworkManager?

1 members found this post helpful.

Yes I am aware of the advantage to embedded onboard audio especially when there is more than one possibility such as with some CPUs and Video systems. That's excactly why I recognize that Pulse has value for some and am sincere in my thanks to Didier for posting access to deep data.

Firstly, that set of packages is, as of yet, only for Current and the upcoming full release whenever that will be.

However the distro is only the beginning as I've recently discovered the degree to which mainstream browsers power system "upgrades". As an experiment I created install DVDs for 14.1, 14.0, and 13.37 that already had current's kernel, patches and libraries to satisfy new hardware as well as improvements for older hardware and in every case they worked just great EXCEPTING what version browsers, especially Mozilla Firefox, would even install, and newer versions of Firefox have ALSA disabled so they must be recompiled, which requires a lot of other software upgrades and additions, just to change "disabled" to "enabled". Older browsers are routinely denied access to more and more websites, so one has little choice but to "upgrade". OTOH Steam, for example, looks for Pulseaudio first but will utilize ALSA but it remains to be seen how many will follow in Mozilla's footsteps where an "option" really isn't an option at all since it requires so much to make it viable. Does that really look like "optional" to you?

Such practice reminds me exactly of a similar issue and condition I once faced with Windows 95. I bought a new motherboard with an AGP slot when they first came out and to my horror Wuin95 couldn't even 'see" it. I discovered a single .dll file of 32KB was all it required but i couldn't find it anywhere so I called Microsoft. I was told "Sure... you can have that 32KB file for $50.00 USD.... but why not just spend $80.00 USD with your Win95 discount and get Win98"? With the exception of one mouse I have never bought another MS product ever again. I had the money but I don't support coercion. I find Pulseaudio to be coercive in a similar manner.

I don't see the relevance. I have NetworkManager on some installs but I don't use it on my Main. The choice is essentially effortless. There is no comparison to the force involved in Pulseaudio even though it depends on server software to even work.

2 members found this post helpful.

Yes, and with good reason. In a post Heartbleed world, I welcome security updates.

I'm against upgrading anything simply for the sake of upgrading... But any browser from before 2015 should not be used. Ever.
Of course it is. Firefox isn't the only browser for Linux.
Except for the fact that you don't have to use it.

This rant is just to tell what leaded me to the article topic of this thread.

In the next big batch of updates for Slint I will provide the software speechd-up, wich allows blind users to have speech on the console (i.e. they hear what's displayed on the screen and what they type is spelled) using the speakup kernel driver, with the added feature of being able to choose which TTS application and which associated voice will be used (as well as the language), this being managed by the speech-dispatcher server.

But some users having several sound cards also want that to specialize one of them for the speech, not necessarily the default one.

Using ALSA this can be done setting ALSA_CARD=<card_number> before running the application that produce the sound, in this case e.g.:
ALSA_CARD=<card_number> speechd-up.
But then SpeechDispatcher should include an ALSA command in the message it sends to the TTS application, to process the text to be spoken, which is not well understood by some of these TTS (or it would differ for each TTS, which would be complicated).

So I thought to use PulseAudio instead of ALSA, thus was in search of a an environment variable read by PulseAudio to set the sound card. This leaded me to the article from Victor Gaydov.

But this is not the end of the story.

Using PulseAudio, one could write
PULSE_SINK=<sink> speechd-up
but finding the name of the sink is not easy and not all applications honor the PULSE_SINK setting.

So I ended setting libao as audio output instead of ALSA or PulseAudio (I didn't try OSS...) in SpeechDispatcher main configuration file, but also writing "default_driver=alsa" in /etc/libao.conf and patching SpeechDispatcher to set "aplay" as command to include in the messages sent to the TTS in case libao is used.

Systems' integration can be fun, at times.

1 members found this post helpful.

Who in their right mind would not welcome needed security updates? AFAIK the Heartbleed vulnerability although accessible via browser is not intrinsic to older browsers but rather to OpenSSL but that is of little concern to this thread. The point was that no simple patching can make Firefox roughly post "Quantum" work with ALSA only without complete and arduous recompiling or make earlier versions on properly patched secure systems viable. The only choices are 1) Recompile new Firefox 2) Employ Pulseaudio or, 3) Switch browsers which though viable is not a trivial change. So ultimately there is considerable and unnecessary pressure to just cave in to Pulse. If you don't get that it's only because Pulse works well for you and you apparently can't understand the other position where it doesn't. No amount of configuration data can reduce it's latency to one truly useful for DAW work.


Why can't you see or admit that there is a huge difference here? If one doesn't want to use Firefox but rather another browser one can have several installed, use whichever is desired at any time, even simultaneously, with no alteration to ones system, no additional effort beyond installing. To not use Pulseaudio is a massive amount of work that involves substantially altering ones system that may well have continuing hoops to jump through for years to come.

Look... you like Pulse and that's fine but can't you see that hard dependencies, especially for non-essentials, is an important precedent and very risky as a developing "cul de sac"?

It was not my intention to disrupt or sidetrack this thread so I won't continue with this. I just wanted it noted that there are pitfalls and problems associated with Pulseaudio and the way it has been implemented. It could have been made truly optional with very little effort but it wasn't. To discover the truth in this one only has to actually do it. Telling people that it is an easy option is like telling people in Ethiopia that they needn't starve or suffer malnutrition when they could easily just go to the nearest MacDonalds.

2 members found this post helpful.

It's not difficult at all to switch browsers. Why are you so attached to Firefox?
No there isn't... Unless you stubbornly cling to software which won't work without it. This is Linux. You have many options.
That latency is inherent in ALSA.

Linux sound worked best when it used OSS. ALSA was a giant leap backward. If you want a unix based OS for DAW work, try one of the BSDs. They still use OSS. It is really much, much better than ALSA.
Right. That's what I'm saying.

1 members found this post helpful.

enorbet and rkelsen both make valid points, but I'd like to point out that the problem is fairly specific to stable release 14.2.

This laptop I'm typing this post on right now is still running 14.1, and it's the system I use for viewing multimedia. It's pure ALSA, and has always been, so avoids the PA glitchiness. Pale Moon still supports ALSA by default, and is less buggy and (I believe) more secure than Firefox. It works great.

The next stable release, 15.0, will incorporate the easy ALSA reversion option already in -current. Your 15.0 system should be completely free of PA headaches, if you so choose.

So, it's only 14.2 which suffers from the narrow defect of defaulting to PA and requiring some effort to revert everything to ALSA, and 15.0 seems likely to come fairly soon.

This makes it a transient problem, unworthy (IMO) of strenuous complaint. The issue was recognized, a good solution is already developed, and soon it will just be a bad memory.

IMO we should chill out and focus on doing the right thing with what's in front of us.

2 members found this post helpful.

No the latency is not inherent in ALSA. Where did you ever get such a ridiculous notion? That is pure FUD. Under ideal circumstances I can achieve 1ms latency with pure ALSA. Under actual recording circumstances I never exceed 8-10ms and 4-6ms is common. If I use Pulseaudio that number exceeds 20. I didn't read this somewhere. I tested it with a specific loopback arrangement used industry wide by professionals to determine system wide latency.

As for the next sentence BSD is not a viable alternative for many reasons but more importantly to the gist of this thread that you would even propose such a massive change only adds to my point that Pulse is in fact coercive causing a need for substantial hoops to jump through. Why should Linux accede to such a Draconian hard dependency?


Re: The ease of switching between browsers as an example of other softwares compared to the difficulty of removing pulseaudio you replied....
No. You aren't getting the point. I merely prefer to use Firefox if possible because I have used it literally since it's inception on numerous operating systems. I am actually in the process of converting to Vivaldi or Palemoon but it is a slow process because it is a considerable learning curve with little gain when considering that had not Mozilla chosen to make Pulse a hard dependency (with one simple line of code) none of that work would be required for primarily the gain of just getting back to Square One, to use what audio driver/server I want to continue to use.

I like ALSA and you don't and I very much don't like diminishing options and you don't seem to mind. End of discussion.

2 members found this post helpful.

@ ttk - I agree with you that 14.2 is presently the focus of the problem BUT if you look at the removal process for Current and I assume that will still be necessary in the next Full Release, please note that very important packages are altered including MPlayer, Xfce, ffmpeg, GStreamer plugins, Phonon, xine and kde-runtime as well as ALSA itself. People including me are already asking in LQN what future difficulties will such alterations create for additions and upgrades? I severely doubt this is a trivial issue and it never had to occur at all since there is no solid justification for Pulseaudio to require shoving all the others to the side as if it was some nemesis in The Highlander bellowing "There can only be one!" It should be a simple choice and easily could have been so. Instead it is a royal PITA.

FWIW I don't desire that Pulseaudoio disappear.. only that it be made to play nice with others.

1 members found this post helpful.

After having written post #9 I made more tests. Alas, using libao set as audio backend of speech-dispatcher, libao in turn using its alsa driver, I realized that I had still an issue: I couldn't at the same time run a speech application relying on SpeechDispatcher and some classical music on YouTube from Firefox. This is on Slint and there Firefox is a repackaging of the official binary, so relying on PulseAudio.

Then I built apulse, mentioned by Victor Gaydov in his article, installed it and... bingo! I can hear Orca (a screen reader) spelling what I type Firefox, and a classical tune on YouTube at the same time. And also speechd-ul reading the screen of tty2.

tl;dr build and install apulse and try this command:
apulse <any app linked to libpulse.so.0>

I adapted a PKGBUILD from Arch instead of writing a SlackBuild, but basically:
HTH some,

PS Maybe APULSEPATH should be more hidden, I'm afraid that with this setting its own "fake" libpulse.so.0 will be used by applications linked to the shared library even if the wrapper script /usr/bin/apulse is not used to start them, but you get the idea.

PPS. Something spawns pulse as soon as Xstarted in Maté (I still have to find what, even with the mixer removed from the top panel, puzzled) to be sure I removed pulse. I still hear the music. Also, I have now APULSEPATH and APULSE_SEARCH_PATHS set to /usr/share/lib64/apulse. I think the linker won't look there, unless told to.

PPPS. Removing pulsaudio made me discover that kpat is linked to it. Why? Anyway it works started by "apulse kpat".

3 members found this post helpful.