SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Didn't I pick up somewhere, that Slackware 15 is "delayed", because Pat's now building on systemD?
That is a very dangerous rumour to spread, even in jest, and must be quashed right now. There is absolutely no evidence for that which I have seen. If you have something solid, please provide it.
I know your post was a joke but such jokes can have nasty consequences.
Please do not bring systemd into this thread unnecessarily. We do not need more arguments about that.
Last edited by Lysander666; 05-24-2019 at 12:07 PM.
Where to start? OK, Didier first. I am not complaining because I had to install extra packages. I am perfectly well aware that if you do not do a full install, you will have to deal with dependencies by hand. And I know how to do that. I found them all, didn't I? What I am complaining about is that one of those dependencies turned out to be PA, a package that I've heard very little good about on this forum and that seems not to be the kind of thing I expected to find as a compulsory dependency on Slackware.
While there have been some complaints on the forum for pulseaudio, there have also been a lot of people who are happy it's included (and probably many more who weren't even aware it had been included because it just worked). The complaints usually stem from people having unique audio requirements or they're against it for philosophical reasons. For most people, using pulse is easier than alsa and requires little to no tweaking (and that "tweaking" is usually just adjusting the audio out device in a GUI).
If you haven't already tried it, I would recommend it, just so you can decide whether to use it based on your own usage rather than posts on a forum. It may work out great for you or you may decide, as others have, to remove it from your system.
Distribution: Slackware/Salix while testing others
Posts: 1,718
Rep:
When PA first came out I hated it. It was over engineered sloppiness, lately, however, it does seem to work fine, especially for most use cases.
But whether I like it or not does not matter, the OP does not like it nor want it. Once again the Slackware community has risen to the task, PV is providing an option for Alsa only (-current and 15.0), several people offered ways to deal with the problem, one member offered to ship the DVD's since bandwidth is an issue and another provided links to packages to solve the problem. This community is just as much the heart of Slackware as PV and the dev. team are. Sniff, got something in my eye, really...lol kudos all.
But whether I like it or not does not matter, the OP does not like it nor want it.
This could just be because he's read posts on the forum complaining about it and hasn't actually tried it personally. That is why I encouraged, on my previous post, to try it so they can make the decision personally.
The main benefit of pulseaudio over pure ALSA is lower cpu usage which makes for a smoother desktop experience.
If that was anything more than your feeling about response (as in actually measured and found accurate) then you didn't have ALSA setup properly. I am certain of this because ALSA is still working on your system,. ALSA has not been replaced since PA is NOT a sound server. PA is just working in addition to ALSA and that requires ram and cpu cycles.
Quote:
Originally Posted by Fat_Elvis
Yo, this is actually relevant to my interests. What is this about Pulseaudio and audio quality? I'm looking for a good reason to dump the Pulse packages and spend a week (lol) trying to make USB audio work properly. (Not joking).
The main problem with PA is latency overhead. This is not a huge deal in playback. It has some effect but it is absolutely trivial. Where latency becomes a huge problem is in recording and especially multi-track type recording where overdubs and "punch-ins" are required to have extreme precision. The level of latency for a single signal is bad enough but in successive work latency is cumulative. Without getting deeper into it until you say you do or want to do recording work, it is not a problem for you. No worries.
If that was anything more than your feeling about response (as in actually measured and found accurate) then you didn't have ALSA setup properly. I am certain of this because ALSA is still working on your system,. ALSA has not been replaced since PA is NOT a sound server. PA is just working in addition to ALSA and that requires ram and cpu cycles.
ALSA + DMIX the default for most non puleasaudio setups uses more resources then ALSA + pulseaudio on most sound cards(chips) that do not have hardware mixing it's simple.
arTs, ESD, etc. all predate alsa back to the OSS-Free days -- which could only output one stream at a time. That problem was resolved by alsa's 'dmix' plugin.
The main benefit of pulseaudio is that it provides on the fly sound routing. The downside is that it's designed around a per-user userspace daemon which can suffer cpu starvation and can introduce latency, and/or stuttering when the system is under heavy load.
Odd that ESounD is still in 14.2 in that case.
Quote:
The per-user design can be a problem if multiple pulseaudio daemons running for separate users fight over access to the hardware: only one can use the hardware device at once unless you reconfigure pulse to run on top of alsa's dmix to avoid that issue (which is how I do it).
Personally, I find the pure-alsa stuff Pat provides in extra/ unnecessary as one can easily configure to bypass pulse if that is what one wants/needs, but I suppose some folks like the purity of having a pulse free system.
In all honesty, despite its 'only one stream at a time' drawback, I think I preferred the OSS-Free days.
Sound was practically unusable to me in those days, so I don't miss that at all. YMMV and obviously does.
Personally, I've never had any problems with Pulse Audio. That doesn't mean I'm a fan thereof. It means exactly what it says--I've never had any issues playing audio with Pulse Audio.
You don't have to like the creator of Pulse Audio to admit that the darn thing seems to work, as does his other creation, SystemD. And I must admit that, as far as I am concerned, pavucontrol (the Pulse Audio Mixer) is a nice piece of work.
Speaking of SystemD, I have friend who sysadmins a thin client Linux network in a medium-sized (about 250 clients) business network. He sees benefits in his network environment that home users cannot see. He doesn't "like" SystemD either, but he will testify that his server's boot is much smoother with SystemD than it was with SysVinit. But he is annoyed at having to figure out journalctl to read logs.
I think part of the issue with both Pulse Audio and SystemD is the perceived arrogance of their creator. I say "perceived" because I've heard him interviewed and, in the interview, he came across as not at all arrogant.
And some persons--I'm one--just don't like change, because it means work.
Speaking of how an average Linux user arrives today to need "to switch audio interfaces on the fly", I would like to note that today exists PC speakers which are powered over USB, and they also get the audio signal over USB, exposing themselves to computer as an USB audio card. Some random examples:
Every time when an average Linux user insert his headphones like this in computer, and happens to use also speakers as shown, he needs to switch the 2 USB audio interfaces on fly.
It is trivial to do that with PulseAudio, I am not sure if it's so simple under pure ALSA.
And as a side note about "old ladies" from my vague knowledge about the Russian slang, they are the WWW2 veterans, now in their 90, and having today an all-knowing attitude, considering themselves the fathers of the nation and who should have always the last word in any issue. At least this is how they are seen today by the younger ones, who greatly respect them, but also giving some good chuckles about their gramps behavior.
Ah, so these are basically USB interfaces with integrated speakers that possibly offer nicer output than the some random OEM chip.
That does make sense.
If the gramps and old ladies thing is a dig a me, I don't get it. I don't install many of the default Slackware packages that I never use. I'm not taking the position that my use case should be the default distribution or anything.
The main problem with PA is latency overhead. This is not a huge deal in playback. It has some effect but it is absolutely trivial. Where latency becomes a huge problem is in recording and especially multi-track type recording where overdubs and "punch-ins" are required to have extreme precision. The level of latency for a single signal is bad enough but in successive work latency is cumulative. Without getting deeper into it until you say you do or want to do recording work, it is not a problem for you. No worries.
Good info, thanks!
I used to do a lot of recording stuff, and still keep all my gear. But I have so far only been able to do some very basic recording, with no plug-ins, eq, etc. on Slackware through Audacity.
I have been meaning to get back into that, but it's a whole thing to set that up, as I'm sure we are all aware.
To clarify, do these issues exist on raw ALSA, or would I need to set up something like JACK for an improvement?
pulseaudio seems to do what it is supposed to do, but did have an annoyance on another computer (but that computer is gone now), what it would do is everyday it would reconfigure itself to pipe the audio to the HDMI video to my monitor, that would be great if i was using a HUGE LCD HDTV for gaming or something like that but i just have a regular 24 inch monitor without speakers in it, so everyday i would have to open the pulseaudio mixer and point the audio output back to the audio-out ports at the back of the computer
there was supposed some workarounds for this in /etc/pulseaudio/* but pulse would ignore them, probably just weird hardware
Last edited by Okie; 05-25-2019 at 04:23 AM.
Reason: fix spelling error
I have set the cat among the pigeons, haven't I! In the mean time, I just took Didier's advice, removed the /etc/asound.conf file and uninstalled pulseaudio. And sound still works. So it seems that I don't need the "pure" alsa library files provided in current after all.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.