I'm slowly starting to understand the whole @pipewire issue.
-
I'm slowly starting to understand the whole @pipewire issue.
Here is my take: People experience different problems, which is specific to a specific kind of use (like midi-issues, lack of pipewire support in apps, unsupported interface), and therefore keep using/recommending Jack.
Long time Linux users are used to using Jack, can't see the issue of using it, so vendors like Reaper keeps thinking "ALSA/Jack works fine, no need for Pipewire, it's not working properly"
-
I'm slowly starting to understand the whole @pipewire issue.
Here is my take: People experience different problems, which is specific to a specific kind of use (like midi-issues, lack of pipewire support in apps, unsupported interface), and therefore keep using/recommending Jack.
Long time Linux users are used to using Jack, can't see the issue of using it, so vendors like Reaper keeps thinking "ALSA/Jack works fine, no need for Pipewire, it's not working properly"
In comes music producers new til Linux, install Bitwig (with native pipewire support), flip the "Pro audio" switch in the audio settings app and starts producing without any trouble. We open a browser in the background, listen to a little music, while still in Bitwig (because this is what we're used to on MacOS), and thinks pipewire is awesome. No specific needs, just a class compliant audio interface which is found and routed without much trouble.
-
In comes music producers new til Linux, install Bitwig (with native pipewire support), flip the "Pro audio" switch in the audio settings app and starts producing without any trouble. We open a browser in the background, listen to a little music, while still in Bitwig (because this is what we're used to on MacOS), and thinks pipewire is awesome. No specific needs, just a class compliant audio interface which is found and routed without much trouble.
Then another might be trying out Reaper, using ALSA, and suddenly all other sound of the computer stops working, when Reaper is taking control of the audio interface.
We look into Jack, ALSA, Pipewire. Get confused. What's the driver we would normally get from the interface vendor. We don't know?
We find articles (or comments) of people still using Jack. It's the low latency standard. Or ALSA, so there is direct connection between software and interface.
-
Then another might be trying out Reaper, using ALSA, and suddenly all other sound of the computer stops working, when Reaper is taking control of the audio interface.
We look into Jack, ALSA, Pipewire. Get confused. What's the driver we would normally get from the interface vendor. We don't know?
We find articles (or comments) of people still using Jack. It's the low latency standard. Or ALSA, so there is direct connection between software and interface.
It becomes this negative circle, where vendors don't support the transition to Pipewire, by supporting in natively. But all the distros turn to Pipewire, so it just keeps getting more confusing.
And when the longtime software users don't need pipewire, because it doesn't support their specific needs, then they wont support suggestions from new users to get native pipewire - because you can do all that already, and pipewire has all the flaws.
-
It becomes this negative circle, where vendors don't support the transition to Pipewire, by supporting in natively. But all the distros turn to Pipewire, so it just keeps getting more confusing.
And when the longtime software users don't need pipewire, because it doesn't support their specific needs, then they wont support suggestions from new users to get native pipewire - because you can do all that already, and pipewire has all the flaws.
So software vendors: Support Pipewire already. Support the transition of these functions in the development of Linux.
This seems like the Xorg / Wayland fight all over.
"We can't support it, it's not good enough yet"
- But then support it and make it good. You are missing out on competent people joining (y)our community because the price of joining is too high.
-
So software vendors: Support Pipewire already. Support the transition of these functions in the development of Linux.
This seems like the Xorg / Wayland fight all over.
"We can't support it, it's not good enough yet"
- But then support it and make it good. You are missing out on competent people joining (y)our community because the price of joining is too high.
And if you think this whole discussion is worthy of your time. Take a look at this really great forum thread from the Reaper forum. It says it all.
(Like the user who would rather have a dedicated interface for Youtube sound, so it's not going through the reaper-used interface...)
-
I'm slowly starting to understand the whole @pipewire issue.
Here is my take: People experience different problems, which is specific to a specific kind of use (like midi-issues, lack of pipewire support in apps, unsupported interface), and therefore keep using/recommending Jack.
Long time Linux users are used to using Jack, can't see the issue of using it, so vendors like Reaper keeps thinking "ALSA/Jack works fine, no need for Pipewire, it's not working properly"
-
So software vendors: Support Pipewire already. Support the transition of these functions in the development of Linux.
This seems like the Xorg / Wayland fight all over.
"We can't support it, it's not good enough yet"
- But then support it and make it good. You are missing out on competent people joining (y)our community because the price of joining is too high.
@mosgaard
Applications doing audio (or MIDI) I/O should not, in general, be using any API provided by pipewire itself. So there's really nothing "to support" unless:* you're a distro provider
* you're creating control and configuration apps for audio/MIDI on Linux
* you're working on a very unique application that for some reason needs to use Pipewire APIsUnlike the Wayland/X11 situation, Pipewire intends to fully support existing APIs (ALSA, JACK, PulseAudio) and does (fairly well!)
-
S simonjust@mstdn.dk shared this topic
