Using alsa in parallel with pipewire

[sunrat]

... pipewire is not finished yet.

I think that sums up this whole topic.
I tried it once recently and it worked ok for most things, except for one thing I rely on. I have PA > JACK > ALSA working much better.

It took at least 10 years of Pulseaudio development for it to work adequately for most use cases. I expect Pipewire will take a few years still to be useful for me.

[Kirtai]

Yeah, Pipewire is still a thing in progress. Not long ago, any program using rtaudio would crash on recent versions of Pipewire. (This is on EndeavourOS)

[k410]

[deleted by poster]

[Audiojunkie]

Some thoughts, most of which have already been reflected by others’ comments in this theead already:

1. The full vision is for pipewire to never have to be disabled. Pipewire is meant to run on top of ALSA, and run all available and future ALSA, PulseAudio, and JACK applications. It is meant to be a solution that meets everyone’s needs.
2. Pipewire is a young program that is not feature complete—the developers just barely got Bluetooth working a week or so ago in their latest release—only currently available (to my knowledge) in Fedora and rolling releases. While much of pipewire works great (I use pipewire directly using pipewire-jack, pipewire-pulseaudio, and pipewire-alsa, and have no jack components installed), there are almost certainly things that are not yet implemented, and there are almost certainly bugs.
3. I agree with pipewire developers’ vision—the ideal goal of pipewire being everything for everyone is a noble and steep goal, but it will take time and patience, and most of all, the developers count on our well written bug reports and constructive criticism to help resolve problems and to help them know what features are important to us. I’ve read elsewhere, and I tend to agree that there are many archaic components of ALSA that would be better if done away with—for example, I see no need for ALSA effects or a mixer—pipewire will be a better overall solution, once it has had time to mature. I recognize that not everyone will share my enthusiasm or agree with my opinion—and that’s perfectly fine—that’s why we all have our preferred distros and philosophies with Linux.
4. We need, instead of arguing with one another and complaining how this feature or that feature doesn’t work, to be engaging directly with the developers. I was amazed at how easy it is to sign up for Github to report problems I have with certain open source projects I use. While I admit that I am not a member of Gitlab, I would imagine that signing up would be similar to my Github experience.

To sum up my thoughts: Pipewire is meant to work with all ALSA, PulseAudio and JACK applications. While pipewire isn’t complete, it is quite usable to many already. It is likely to be the future of most Linux distros going forward. And we need to do our part by reporting the problems and oversights that we notice, directly to the developers so that our problems can be resolved.

Linux is wonderful!

[Linuxmusician01]

Some thoughts, most of which have already been reflected by others’ comments in this theead already:

1. The full vision is for pipewire to never have to be disabled. Pipewire is meant to run on top of ALSA, and run all available and future ALSA, PulseAudio, and JACK applications. It is meant to be a solution that meets everyone’s needs.
2. Pipewire is a young program that is not feature complete—the developers just barely got Bluetooth working a week or so ago in their latest release—only currently available (to my knowledge) in Fedora and rolling releases. While much of pipewire works great (I use pipewire directly using pipewire-jack, pipewire-pulseaudio, and pipewire-alsa, and have no jack components installed), there are almost certainly things that are not yet implemented, and there are almost certainly bugs.
3. I agree with pipewire developers’ vision—the ideal goal of pipewire being everything for everyone is a noble and steep goal, but it will take time and patience, and most of all, the developers count on our well written bug reports and constructive criticism to help resolve problems and to help them know what features are important to us. I’ve read elsewhere, and I tend to agree that there are many archaic components of ALSA that would be better if done away with—for example, I see no need for ALSA effects or a mixer—pipewire will be a better overall solution, once it has had time to mature. I recognize that not everyone will share my enthusiasm or agree with my opinion—and that’s perfectly fine—that’s why we all have our preferred distros and philosophies with Linux.
4. We need, instead of arguing with one another and complaining how this feature or that feature doesn’t work, to be engaging directly with the developers. I was amazed at how easy it is to sign up for Github to report problems I have with certain open source projects I use. While I admit that I am not a member of Gitlab, I would imagine that signing up would be similar to my Github experience.

To sum up my thoughts: Pipewire is meant to work with all ALSA, PulseAudio and JACK applications. While pipewire isn’t complete, it is quite usable to many already. It is likely to be the future of most Linux distros going forward. And we need to do our part by reporting the problems and oversights that we notice, directly to the developers so that our problems can be resolved.

Linux is wonderful!

Well written.

You write - and rightly so - that much depends on us users reporting bugs. I'm sorry, but I stopped doing that. The websites where you need to do that have an incomprehensible interface. And when you do report a bug in forum or bug-report website it's never enough. You get negativity because your report isn't extensive enough. You have to jump through hoops to find unfindable log files which are to big to post so you have to find a way to share them etc. etc. And in no way developers help you do that. They've been on github or something for so long that they think it's easy. Developers should try to solve a bug based on a short post in a forum every now and then. And thank us for it. But instead they tell you to report it on github or something. You have to make an account, remember your password etc. all for something you already "reported" or "told about" in a forum topic. No, thank you very much.

[sysrqer]

They've been on github or something for so long that they think it's easy. Developers should try to solve a bug based on a short post in a forum every now and then.

This is an interesting point. I use VCV Rack and from v2 they have stopped using a public bug tracker and rather request you to email support. I have to say that, although it is good to be able to discuss the problem with someone who perhaps isn't a developer but knows what information is needed, it is very frustrating not being able to see what, if any, progress has been made with an issue. This has made me very much in favour of open bug trackers.

There are many developers who do solve bugs based on forum posts, many of VCV Rack's module devs do, and there are at least a few here such as the yabridge dev, the scarlett mixer UI dev.

The problem with large projects like pipewire is that there would be too many posts in many different places which would make it next to impossible to track the issues. Should they be monitoring linuxmusicians? reddit.com/r/linuxaudio? reddit.com/r/linux? reddit.com/r/linuxnoobs? Distro specific forums and subreddits?

I do agree that often you are met with questions/answers which are incomprehensible though. This is what I think VCV got right, it's rare that you hear from Andrew these days for various reasons, and it often works better to have an intermediary between devs and users.

[tseaver]

I am enormously puzzled by those (including the core Ardour devs) who insist that "just use ALSA" is the way forward: do none of them ever need to have more than one sound-producing/consuming application running simultaneously? Is running Guitarix, Pianoteq, Yoshimi as standalone apps (versus plugins into the DAW), and still being able to record from them not a valid usecase? What about recording a sample / reference track from YouTube (running in the browser, which pretty much has to talk to PulseAudio these days)? Or using your DAW to compose / play music while screenrecording with OBS?

Complaints that pipwire / jack / etc. "hog" the audio device sound to me exactly the same as the issue with any app which uses raw ALSA: such applications lock the device, blocking access for any other clients, for the lifetime of the raw-ALSA-using application. The Highlander Syndrome ("there can be only one") is, indeed, the problem that a "sound server" is supposed to address.

I *do* understand that the support burden for developers of audio apps is higher in an environment where those apps cannot use raw ALSA: as a career FLOSS developer, I've been tempted (and even succumbed, at times) to blow off bug reports which rely on weird / non-reproducible environments, and the "connect-anything-to-anything" benefit of a "sound server" is certainly ripe for generating such an environment.