Using alsa in parallel with pipewire

[buscon]

hi,

I am running Linux Mint 21 and successfully using pipewire.

Now I would like to run Reaper with Alsa, is that possible while pipewire is running?
If I select ALSA in Reaper I get a [audio device closed] notification and no audio can be played.

[Impostor]

Hi, I've no idea, but I do have a question, troubleshooting related:

What is the highest kernel you can install via the update manager?
I'm on Linux Mint 20.2, and for me it's kernel 5.15

[j_e_f_f_g]

I would like to run Reaper with Alsa, is that possible while pipewire is running?

No. Frankly, I uninstalled pipewire for this very reason. At least JACK and PulseAudio provide another program a way of asking "I'd like to use alsa. If you're not doing anything with the audio card, could you let me use it?". Pipewire has no such feature.

You're going to need to manually stop pipewire before you run reaper. For example, if you have some "task manager" app, run it, find the pipewire daemon in this list, and kill this predatory creature. From a command prompt, you could probably use "systemctl stop" (assuming you're using systemD) to stop the pipewire unit. But I don't personally know what pipewire lists itself as under systemD.

[buscon]

thanks for your answer.

Solution: yes, stopping pipewire with systemD was the solution for me:
$ systemctl --user stop pipewire.service
I am running Linux Mint 21 with kernel 5.15.0-46-lowlatency, which is the latest lowlatency kernel I can install.

[sysrqer]

Pipewire has an alsa interface so if you have that installed then you should be able to choose alsa from Reaper's preferences. This can be handy because you can have entirely different settings for alsa and jack and pipewire.

However, I guess that you meant using true/bare alsa alongside pipewire and I don't think that's possible.

[j_e_f_f_g]

Just to be perfectly clear to anyone else reading this thread for whom this info may be useful, here's a more detailed explanation of the original poster's problem and solution:

He has pipewire running on his Linux Mint system. Like Jack and PulseAudio and nearly every piece of crap "sound server" out there, Pipewire is misguided software that tries to completely take over your computer's sound, even to the point of blocking the linux operating system from getting access to your sound card. Once pipewire starts running it grabs your audio hardware away from the operating system, and refuses to let go of it. The only way a music app can then get to your audio hardware is through pipewire. If that app uses Pipewire, that's ok. If not, then the trouble starts...

Pipewire emulates (ie, can convincingly pretend to be) PulseAudio. So if that app uses PulseAudio, that's ok. The app should be able to work. But the app may not work properly because, although pipewire pretends to be pulseaudio, he's not the real deal. So when the app tells him to do something PulseAudio is supposed to do, pipewire may not do pulseaudio's job correctly. In fact, he may not even do the job at all. Pipewire is a bit of a con man.

What if your app doesn't use PulseAudio or Pipewire? Well, there's one more iffy option:

Pipewire also emulates Jack. So if your app uses Jack, your app should work. But again, pipewire ain't really jack, so maybe pipewire will do a crappy job at pretending to be jack too.

What if your app doesn't use PulseAudio or Pipewire or Jack? What if your app uses ALSA to achieve the lowest latency, overhead, and gain the most control over how your sound card operates? Well, you're out of luck. Pipewire not only won't help you, he'll prevent your app from getting anywhere near your audio card, even if your app politely asks him to please let go of the hardware if he's not actually using it.

The only solution is to grab a gun and shoot pulseaudio right between the eyes. You must KILL him. One way to kill him is to open a terminal window, type the following line, and then pull the trigger... um, press the Enter key:

Code: Select all

systemctl --user stop pipewire.service

And if it feels good, you're welcome to do it again. Sometimes, you just want to drive a stake through his heart, after you've shot him with a silver bullet, to make sure he's really dead.

Now, you can run your app that uses ALSA.

[Kott]

I was told on #lad that you can disable pipewire for (separate) soundacrd with pavucontrol as with pulseaudio. I don't use pipewire so can't confirm that.

[sysrqer]

.....

That's a whole lot of nonsense, scaremongering and misinformation.

What if your app doesn't use PulseAudio or Pipewire or Jack? What if your app uses ALSA to achieve the lowest latency, overhead, and gain the most control over how your sound card operates? Well, you're out of luck. Pipewire not only won't help you, he'll prevent your app from getting anywhere near your audio card, even if your app politely asks him to please let go of the hardware if he's not actually using it.

This is just plain wrong. As I mentioned, pipewire can deal with alsa in exactly the same way it deals with pulseaudio, pipewire and jack.

The only solution is to grab a gun and shoot pulseaudio right between the eyes. You must KILL him. One way to kill him is to open a terminal window, type the following line, and then pull the trigger... um, press the Enter key:

I have no idea what you are driving at here. What does pulseaudio have to do with using alsa with/without pipewire?

There's no reason that you can't use programs that use pulseaudio, jack, and alsa all at the same time in pipewire. Fair enough if you don't like it but trying to pass off a biased opinion as informed fact is not helping anyone.

[Gps]

I am a simple user far more then a specialist, but my experience with LMMS, seems to point at jeff being right.

I had to change the sound setting in LMMS, to have again sound.

If pipewire was doing a 100% emulation, then why did the sound on LMMS stopped working?

I can only hope pipewire just has a few issues that still need to be ironed out.

Right now its not working as promised, because if it was, I did have to change the sound settings in LMMS.

Wasn't that the goal of pipewire, us users not having to think or know what sound system lmms and all other programs are using ?

[sysrqer]

Which settings did you have to change? It would be expected that you would have to change the output because by default pipewire's output isn't named 'System' like it is in Jack - this can be changed in the config and if you did so you probably wouldn't have to do anything in LMMS.

[Gps]

LMMS has a setting were you pick the audio interface.

https://docs.lmms.io/user-manual/getting-started/setup

Sound stopped working, LMMS (on Linux) supports:

ALSA, JACK, and Pulse Audio, PortAudio ( dont know what this is) and SDL (Simple DirectMedia Layer)

Having to look at those setting proofs to me, that in the best case pipewire is not finished yet.

[j_e_f_f_g]

That's a whole lot of nonsense, scaremongering and misinformation.

Given my track record of being knowledgeable about the inner workings of linux's audio systems, you may want to make sure you've fully verified your contentions before you dismiss mine.

Because I'm about to publically prove I'm right, and you're wrong.

pipewire can deal with alsa in exactly the same way it deals with pulseaudio, pipewire and jack.

You mean in a less than 100% compatible way that introduces its own set of problems?

I'll give you that.

The only solution is to grab a gun and shoot pulseaudio right between the eyes.

I have no idea what you are driving at here. What does pulseaudio have to do with using alsa with/without pipewire?

"pulseaudio" should be "pipewire" obviously (because the systemctl command I give kills pipewire). You really had "no idea" that's a typo?? Come on.

There's no reason that you can't use programs that use pulseaudio, jack, and alsa all at the same time in pipewire.

There is a reason.

Pipewire does not emulate ALSA's memory-mapped (MMAP) API. It also doesn't emulate its rawmidi API. In fact, while pipewire is running, it prevents all other software from using these APIs.

I know this for a fact. How? Because I tested it with actual working code. I have "proof of concept" examples for my observations. snd_pcm_open() for example will fail if you try to open a device with MMAP I/O, while pipewire is holding that device. Even if pipewire is doing nothing with the device, other than locking it.

Stop pipewire, and it then works. Restart pipewire and it fails again.

Now, I have not tested whether pipewire seeks to emulate alsa's "file read/write" API. Unlike MMAP, that wouldn't be a nightmare to try to emulate. All you'd have to do is subvert the operating system's sound system, just like malware would do, and create a shim dll that replaces alsa's... well let's just say that it's horrifying if they did that. Because it shows malware authors exactly how to hack around the OS security to capture audio streams.

But no music app is going to use the read/write API because that's a low-end audio API meant for programs for which audio is incidental. (ie, Your spreadsheet making a beep when you enter a bad value).

If pipewire intercepts alsa's read/write api, but definitely not its MMAP API, then what we've got here folks is a partially compatible version of alsa installed on our systems. And isn't that great? Now when you configure an app to use alsa, and it doesn't work, you don't need to troubleshoot only that app, and the real alsa. Now you get to also troubleshoot pipewire's alsa emulation. Yep. These audio servers just keep making linux audio configuration and trouble-shooting easier and easier, don't they? I mean, I'm just spouting fud and misinformation, aren't?

Let's test that theory. But first I need to answer Gps' valid and logical question:

If pipewire was doing a 100% (alsa) emulation, then why did the sound on LMMS stopped working?

Because LMMS no doubt uses alsa's MMAP API, and pipewire prevents that from succeeding.

Gps, if I may ask your assistance, I'd like you to help demonstrate the veracity of my statement. Please open a terminal window and type the following line to stop pipewire.

Code: Select all

systemctl --user stop pipewire.service

Now run LMMS and set it to use alsa. Does sound work?

Save your LMMS settings, then close down LMMS. Go back to that terminal window and restart pipewire as so:

Code: Select all

systemctl --user start pipewire.service

Run LMMS again, with your saved settings. Does sound now fail?

Repeat the above as many times as you like to convince yourself that pipewire does indeed block access to alsa's MMAP.

Now come back here and post a message telling sysrqer that what I said is not "misinformation", but instead the truth, and in fact, what he said is misinformation.

by default pipewire's output isn't named 'System' like it is in Jack

The above is not a typo, so I have to ask: What are talking about????

There's is no "System" device in alsa. To use MMAP, you'll reference a device using the hardware interface (ie, "hw:"). You're just making this up. Now this is "misinformation".

[folderol]

Just to add a little. It seems neither pipewire nor pulseaudio want to use my machine's, built-in Audio, if there's a USB audio unit plugged in. However they will both stop anything else from using that interface

On my music setup, that no problem because I just clear them both out (with extreme prejudice), but for my general purpose setup it is a problem as it seems no {cough}modern{cough} browser can use ALSA whereas they used to be able to (and ALSA hasn't changed much). Just about everything else I run is quite happy talking to ALSA.

[sysrqer]

LMMS has a setting were you pick the audio interface.

https://docs.lmms.io/user-manual/getting-started/setup

Sound stopped working, LMMS (on Linux) supports:

ALSA, JACK, and Pulse Audio, PortAudio ( dont know what this is) and SDL (Simple DirectMedia Layer)

Having to look at those setting proofs to me, that in the best case pipewire is not finished yet.

Why, because it doesn't say pipewire? You can select Jack or whatever and it will still use pipewire. Pipewire has interfaces so if a program needs to use jack then it thinks it is outputting to jack but really it is going to pipewire. Each interface/layer can have its own configuration so you can set low latency for jack and high latency for pulseaudio for example.

I just installed lmms and it worked without doing anything, both sdl and jack produced sound for me (only ones I tried).

[sysrqer]

Just to add a little. It seems neither pipewire nor pulseaudio want to use my machine's, built-in Audio, if there's a USB audio unit plugged in. However they will both stop anything else from using that interface

That's interesting. Do you see the built-in Audio on the qpwgraph? You can definitely use multiple outputs/cards. The few times I've tried to use the alsa part of pipewire things like what you describe happen but that's always been the case for me with alsa, I've never really got on with it.