Pulse Audio is 'undoing' all my solutions
 

Things are going very well with my Slack setup, it's been nearly three months that I've been with it. However, one things continually gives me problems - Pulse Audio.

I have two issues that I had previously solved but now they appear to be not solved.

A few weeks ago I had an issue whereby I couldn't play two simultaneous audio stream. The thread is here. I solved it, and was able to do so. Now I find myself unable to do so. Just now I tried to use Qmplay2 and Audacious but no, I'm told that the 'device or resource is busy' in spite of the fact that the code that originally solved the issue is still in place.

I also had an issue whereby I couldn't get the keyboard volume keys to work, I solved this here. Now they do not work.

Thirdly I had an issue last night where I tried to use QMplay2 after Spotify and just got no sound on QMplay2, Pulse Audio was using 'dummy output', I had to use

to solve the problem.

Does anyone know what is going on here? Can Pulse Audio not leave evrything alone? I am playing Pulse Audio whack-a-mole. I solve one problem, solve another and the old one comes back. Can anyone help with solving these issues once and for all - am I doing something wrong?

I have followed the recipe at the end of this thread https://www.linuxquestions.org/quest...ng-4175619204/ and I'm very happy with it. There's a chance I don't have sound in Firefox, since I've read it relies on pulse, but it suits me, since I use it as web browser only, not as multimedia player.

Well, it's hard to give you a sound advice not knowing your settings, furthermore I won't try to reproduce anyway as Qmplay2 has too heavy dependencies for my taste.

However, you could just try these settings.

Allow me to chime in with my endorsement of Didier's acumen in this area. Since Pulseaudio has almost as much "heat" as systemd responses can be extremely binary and extreme. Didier helped me, and I am no newbie at controlling ALSA, in creating a strict environment where ALSA can do it's job unhampered, un-enslaved, yet allow Pulse to work where it absolutely must and then disappear till needed again.

Thank you, all. I tried this:


From Didier's linked topic, and it works for now, I can play two audio streams again.

As for the volume button, this was originally configured in config/openbox/lxde-rc.xml, but Pulse is still interfering with this. I need tell Pulse to leave it alone.

How odd that this happens. I can see why this application causes dissent now. Not a problem in Debian, but when you have more control over the system in Slack, Pulse is like the annoying Daily Mail reader at a dinner party that keeps butting in with their opinion.

This is exactly why I decided to not bother with pulseaudio years ago (Before using Slackware) and maintained my Slackware install without it since day 1. It has a horrible habit of just breaking all on its own and providing non reproducible issues that at least a few people always run into. Its not even about avoiding the bad hype, its more about reducing the number of things that get in the way and interfere with productivity. I personally don't sit down as the computer expecting to fix sound at arbitrary intervals. [/rant]

Thank-you, good solution, got me some Slack back that I had been missing.

You mention in that thread uncommenting the line
Now, in order to disable autostart at login wouldn't it be better to uncomment the line and change it to 'no'?

Is it possible that either Qmplay2 or Audacious is using ALSA as a backend and not pulse?

I've attached my config files including asound.conf This works perfectly for me and i'm able to play sources at once.

No, autospawn means "start pulseaudio when an application requests it", not "start pulseaudio when the user logs in". So, keep "yes".

In Audacious' menu, Output=>Audio=>Output plugin.

If you chose alsa (seems to be the default here) you can also set the PCM device, the mixer device and the mixer element.

I know nothing about Qmplay2 that I have not installed.

This is really, helpful, thank you. I am trying to get Pulse out the way and this helps a lot. I have alsamixer enabled and would prefer everything to go via alsa without Pulse sitting on top of it.

Is there any specific reason for not using pulseaudio?
Alsa by default locks the sound-card to a single process unless you are using dmix, which is notoriously difficult to set up and configure properly.

I have dmix set up, it was working fine until recently. When it was initially set up I was able to play more than one audio stream at once.

The reason why I think Pulse is the issue is that invoking

stopped the issue I was having.

Recently there has been more understanding as how to set up dmix. It's actually very easy. Take a look here to know how to set it up with the alsa equaliser:

https://www.linuxquestions.org/quest...4/#post5819450

and I/Eric updated Slackdocs here:

https://docs.slackware.com/howtos:ha...s_on_slackware

My question was not about this, i wanted to know whether you use any specific program that uses the alsa back-end to play music and can't be switched over to use pulseaudio.

The fact that restarting pulseaudio solved your issue means that it works, it just probably not configured properly for some reason.

So i rephrase my question:
Is there any specific reason why you need alsa to work instead of trying to fix pulseaudio properly?

Other than that, it would be good to know the following:
- number of sound cards you have (HDMI output on video card counts as well)
- graphical environment (as pulse is usually is started with start-pulseaudio-x11 )
- are you encountering this issue with a standard user or with root user (pulse does not like it when you use it as root, and using your computer as root is very bad practice anyway)

Ah ok, well, no, not especially. But why would I need to use PA if alsa ends up working well by itself?

- it's a netbook so it's integrated audio
- I'm using LXDE
- this is with the standard user, I hardly ever log in as root

ALL programs use ALSA since Pulse by itself is a "Conductor" waving his arms about without actual "Musicians". You do realize this, right?

This is likely true but why even have to configure it as well as ALSA when one can go direct and just configure ALSA?

I'm only speaking for myself and not OP but that question assumes fixing pulseaudio (the back seat driver) is best rather than getting down to where "the rubber actually meets the road"


-This from an actual Slackware user? I have experienced how Debian, RedHat, and even Arch (and of course Ubuntu) are progressively implementing the "Don't bother with nuts and bolts (Administration) we will take care of that for you... go chew your cud, User" attitude, but if this is your POV, and you have a perfect right to run as you see fit, I still have to ask why are you using Slackware? Running as root is a required skill for any Admin so how does that translate as "very bad practice"? It is tru that Pulse is in USERLand and should rightly not be run as root but that does not extend to a generality and IMHO saying so only adds to the agenda of the Windows and RedHat/Debian mentality.

I might be mistaken here, but as far as i know programs do not directly interface with ALSA, but rather the pulseaudio daemon.

To me it sounds like there is nothing wrong with ALSA configuration since a pulseaudio restart "pulseaudio -k" solved OP's issue, meaning ALSA is working, just pulseaudio or the actual programs are not configured properly.


see above, it seems like ALSA works fine, it is the rubber that needs fixing not the road.



I think you read too much into my response, meaning which is not there and certainly not intended.


And to add something useful to OP as well.
Does the same thing happen if you create a brand new user and log in with that?
(this assumes the new user does not have it's .asoundrc customized in anyway and the /etc/asound.conf has the below content.

/etc/asound.conf

Have you tried restoring the following files to Slackware's stock?

~/.asoundrc (remove or rename)
/etc/asound.conf

ALSA has had dmix on by default for cards that don't have hardware mixing since early 2005. I've never had a problem with dmix or had to do anything. If you ask me, I don't even know how to configure it--it just works.

Thank you for your considered response, Qury. You are correct that "programs do not directly interface with ALSA" at least once Pulseaudio is installed and takes over. My point and analogy of The Back Seat Driver is that it makes more sense to many to talk to the guy with the wheel in his hands and an unobstructed view through the windshield. ;)

I had a fight with PulseAudio too, and I ended up making it on-demand only, and restored ALSA as the sound driver.
You have to change the default asound configuration to do this. Restoring the Slackware configuration will only
undo all your changes.

The Slackware config as-distributed assumes that Pulse-Audio drives the hardware and
that ALSA is a secondary mixer-only.

My system has an AC-97, which PulseAudio would not recognize.
One of the PulseAudio support got hardware info from me, so they could fix PulseAudio to recognize and drive
the AC-97 on my hardware. From this I assume PulseAudio also has hardware drivers.

ALSA drives my AC-97 fine so I had to restore the configuration of ALSA to what it was
in older releases (before PulseAudio), and make PulseAudio as mixer-only that
delivers to ALSA.

One result of this is that the master volume of the ALSA mixer affects the PulseAudio output too.
If you use any program with an volume control, it will change the ALSA mixer volume. If you later try to use
a program that uses PulseAudio, you will have to set the PulseAudio volume control much higher.
A low ALSA-mixer volume will force the PulseAudio mixer to amplify the sounds enough that they
clip in the PulseAudio mixer, making it sound bad. You have to start-up an
ALSA-mixer program and set the ALSA volume back up, so the PulseAudio mixer can work in a comfortable volume range.

Find a program that you know is using PulseAudio.
If changing the volume controls in the PulseAudio mixer affects the sound from the program then it is going through
PulseAudio (as it should).
If your ALSA-mixer master volume also affects the sound of that program, then it is also going through ALSA.
If you are sure the program outputs to PulseAudio, then it must not have a hardware driver, and is outputting to ALSA.

Next find a program that you know is using ALSA.
If the PulseAudio mixer affects the sound level, then ALSA is outputting to PulseAudio.
If only ALSA-mixer controls the sound level, then ALSA is driving the hardware.

The above analysis assumes that configuration is somewhat sane and consistent. I would not assume any such thing
when dealing with PulseAudio programs, so distrust everything and find some confirming evidence for any discovery
that is important.

You should make sure of which actually has control of the hardware. ALSA should be locking it, but I never
could assume to know what PulseAudio was going to do.
Having two PulseAudio running at the same time, seems to be allowed, but I do not know how they manage
driving the hardware without stepping on each others settings. Then you will get different results and
setting inconsistency, depending on which program started first.

I could not tell from this discussion, if PulseAudio is driving the hardware or if ALSA was.
That makes me unsure about offering any more advice, as it is highly dependent upon that.

OK thanks for this, this looks like the preferable course of action. I really can't understand the benefit of having PA.

I think this is what happens for me too. In most cases if I use the PA control, the volume is changed accordingly. I also use alsamixer. I am using a 2009 netbook, I think the soundcard is given as Realtek ALC269 @ Intel NM10 ICH or Realtek ALC272 @ Intel 82801GBM ICH7-M, going by this page.


OK, will try and report back. I have no idea why I have to go through this, and why I can't just use alsa, which seems to be doing the job fine. One thing is clear, I really need to gain an understanding of how how PA and alsa work together to help solve this issue. I see that some programs require Pulse, but I wonder if it's OK to use alsamixergui instead.

At least I can play audio, but when it comes to recording things, especially VOIP, I'm going to run into more issues, I'm sure.

--------------

EDIT: This whole issue arose because I wanted an EQ for Pulse. I cannot find one in Slackware, from what I can tell it was removed from Pavucontrol because it was unstable. There is no alternative on SlackBuilds apart from alsamixer. This has caused a knock-on effect of having to configure both rather than just 'settling' with Pulse.

So to recap, the good things are:

1. I can play sound from at least one application, be it Spotify, YouTube, QMPlay2 or Audacious.
2. I have also enabled dmix which allows me - sometimes - to play more than one audio source
3. I have alsamixer working with no issue, though it does not seem to be terribly consistent, I have to keep fiddling with it across different applications. Either that or I have just not found a good 'mid ground' yet.

The bad/annoying things:

1. Sometimes after using one application, another will just not produce sound at all and Pulse will be on 'dummy output'. The only way to rectify this is to restart Pulse wih pulseaudio -k
2. In spite of the fact that dmix is enabled sometimes I cannot play more than one source at one. e.g. using QMPlay2 and using Audacious will cede a warning that the audio device is busy, HOWEVER since doing the following as recommended by Didier


I can play more than one stream again. We'll see how long this lasts, but like someone said in another topic, this could take weeks to sort out.

I see the benefit every time I plugin my headphones, listen to sound, and then unplug them. I never got that to work in a sane fashion with ALSA. YMMV, but adding and removing random audio devices works in a useful fashion for me with PA. My use cases aren't necessarily yours.

Actually, I get that in ALSA too. It's headphones with a phono jack. It works perfectly, no issue.

Maybe you should clarify what you are saying. You are plugging in USB headphones. It's another sound device. Now applications have to understand you plugging in another sound device means you want another sound device. Or you take the pulseaudio approach, and just stuff all feeds into into a single virtual device that orchestrates what it thinks you meant.

I have a USB headset myself. I've tried it with both pulseaudio and ALSA. Yes pulseaudio can switch automatically between the two devices. But then after a while, the built-in pulseaudio assumptions on switching devices got annoying.

The assumptions that PA made about my actions of plugging in the USB headset and unplugging the USB headset happen to match my assumptions about what PA should do.

ALSA never did any switching of output for me; given that most of the applications that I used at the time wanted an ALSA device for output, that ended up being changing a configuration file or some other interaction that was such a pain in the ass that I never changed my output device on my main computer once I got sound to come out of something. I never even attempted to listen to sound on my Linux laptops with ALSA.

aRts and ESD (KDE and Gnome/Enlightenment respectively) used to provide the functionality that PA now provides; I guess those two sound daemons were much easier to avoid than PA (although aRts was the KDE default, IIRC).

switch between speaker, headphone, hdmi ?
the usual user usecases, never worked for me in pre PA times without manual action, works perfect with PA, and out of the box.

The assumption you are making is that if you add another sound device by plugging one in, that you now want to have everything switch over to the new one, and continue to appear you only have one output device. That makes sense from the perspective of that you aren't acknowledging the USB headset is actually another unique output device, but it actually is. You are using a USB headset as if it is a dumb device.

But the time it takes you to plug in a usb headset is the same exact time for me to plug in a phono jack headset and just works. This time, this interaction is handled all in hardware, and no assumptions need to be made in SW. It truly does what you are asking about.

In practice it makes sense for someone to want to work off one output at a time, because that is far most people go in a typical system anyway, and that is how people actually see it work in the classic physical setting with an output jack. The problem with pulseaudio enters when I actually want two devices, or I want to access a setting that my HW exposes that pulseaudio just glosses over. This is where we are saying pulseaudio is "undoing" all our settings. The assumption that multiple devices can be one device breaks down. If pulseaudio just pretended to be another device, rather than be the orchestrator for the entire system, then my complaint will go away. But to some extent it has to make your USB thingy plug in as if it were coming out of one virtual device work seemlessly. But there is no setting that says "stay out of my way" for me. Now pulseaudio has to get pulled out completely to now get me back to a system that is plug-in-play in HW.

So when you minus a single orchestrator that is pulseaudio, what is left is ALSA as we discussed does.

No. Those are not like pulseaudio. They are more like dmix, because you could choose when to use them and not to use them, and still had control of your hardware.

Actually, I had a scenario where PA did not do the above behavior I mentioned. Running Doom3 under OpenAL would select the best device for 3D sound (the 5.1 speaker output from the on-board video card) versus the device that I wanted (the USB headset).

I'll also note that you can configure PA to send different output streams to different devices.

But, I don't really care if you use PA or not; that's up to you. You are happier without it; I'm happier with it. Let's be happy.