
PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2 - c487bd62
https://github.com/PipeWire/pipewire/blob/0.3.0/NEWS
======
BlackLotus89
I tried getting it running and working two weeks ago and sometime today as
well. I had some real problems getting it working. The compilation ran without
a hitch, but getting jack, alsa or pulseaudio to work wasn't really possible.
Wanted zo open bug reports and read the wiki on github but they moved it to
the freedesktop gitlab, but didn't update the links. Also the pages are mostly
out of date or without any relevant information, but plans.

Can't wait to get a seamless setup for it, but I guess 0.3 is still too early
for early adopters...

------
misterbishop
Jack, while incredibly powerful has been a huge hurdle for pro audio on Linux.
I'm looking forward to Pipewire being the default audio interface. Hopefully
it drives a revival of the Linux sound engineering community and new software
projects. Specifically the lack of a user friendly loop/sample-based recording
tool like Ableton Live is glaring.

~~~
cycloptic
Can you describe what some of your hurdles have been? Pipewire is probably not
going to solve your issues as it's not a complete replacement for JACK [0] and
uses the same API anyway. Realistically, if you're writing a new DAW, you're
still going to want to use the JACK API. If your problems are driver-related,
that definitely won't be solved by switching to a different audio daemon.

And for the record, the open source audio community is not dead. There is
activity, but you have to know where to look.

[0]:
[https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...](https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#will-
pipewire-ever-be-as-good-as-jack)

~~~
PaulDavisThe1st
To be fair, as the original author of JACK and the lead author of one the main
DAWs on Linux, we no longer encourage the use of JACK with Ardour.

JACK is an exceptional powerful tool (if I do say so myself) but it is
overkill for the majority (maybe even the vast majority) of users. We try to
encourage most Ardour users to use its builtin ALSA audio/MIDI I/O support
rather than JACK these days.

~~~
bwanab
Paul, first of all, let me thank you for the great software you’re developed.
As a long time JACK user, Can you point me to a more detailed write up on why
it is overkill?

~~~
PaulDavisThe1st
There's no such writeup.

But look - most people don't actually want to connect multiple applications
together to make music. Most people don't actually want to move audio between
applications at all. As we get more and more (reasonably) good plugins
available on Linux, the "monolithic" approach - do it all inside one program
(e.g. a DAW or something a bit like it) is easier for most people (no complex
state management) and closer to their pre-existing mental models.

If you _do_ need/want to connect multiple applications together, then sure,
JACK is great and better than more or less any other possible alternative for
that purpose.

But most people don't want to do that, and increasingly do not need to either.

~~~
johnr2
> do it all inside one program (e.g. a DAW or something a bit like it) is
> easier for most people (no complex state management) and closer to their
> pre-existing mental models.

This may be a generational thing. As someone who learned recording in
traditional analogue studios, I find a modular approach using JACK to be much
closer to my own mental model.

------
hootbootscoot
Starting Jack and then patching stuff together was never an issue to me. It's
not any more complicated than your imagined use-case for it, aka "patch
program A into progam B"

ALSA is horridly complex and it's complexity is related to Linuxy stuff, not
to anything resembling the work your actual audio converters are doing nor the
task of getting data in and out of them!

A new layer added on top of ALSA will not fix this.

Nothing will fix this until some AUDIO people, who are NOT Posix Linuxy People
write a realtime audio subsystem to REPLACE ALSA.

This will not occur anytime soon, for several reasons.

Both the Bela.io system and Elk's "brand new audio OS from the ground up"
(LOL) utilize Linux but bypass ALSA to achieve their low-latency rock-solid
audio pipeline. (the CTAG interface that Heinrich Langer designed appears to
be the first example I can find of this approach)

They use Xenomai realtime kernel extensions to Linux to essentially run the
audio driver as a real-time thread and the buffers your program writes
to/reads from, are the actual buffers that DMA is moving the audio data in and
out of to the ADC and DAC.

End of the day, audio isn't a posix API, and should never be considered as
such. Want an abstraction? fine, wrap a callback as an audio server lol...

I had a Tascam USB audio interface that always sounded THIN on Linux and I
wondered why, until I saw that the ALSA channel mapping had automagically
applied a surround sound map to my 8 channels of output, which implied two
lovely high-pass filters running at 75hz because the system was quite sure
that's what everyone does with 8 channels of output... this despite the fact
that ALSA saw 4 different stereo "devices" as my hardware interface presented
itself...

IF ONLY this were merely a universally understood /etc/alsa.conf or something
file... oh no no no! Linux People have SAVED us from audio configuration! Go
look in /opt/didntknowthisfolderexisted/.confy/map.conf or maybe somewhere
else... Add x-windows and the lack of any GUI application corresponding 1-to-1
with the "handy obscure utility" it purports to configure and control, and you
have a match made in heaven!

Linux is an awesome server OS. It's a crap audio OS, and this is due to
extreme cleverness and a total lack of paying attention to how any other audio
API's in the world work except OSS... OSS isn't even an audio API FFS! it's
like a printer API... you might as well use CUPS to run your sound LOL

------
8bitsrule
Good news to see work being done on the Linux-audio 'bottleneck'. I miss the
ease-of-use and options available on other platforms (I left behind).

~~~
PaulDavisThe1st
Trust me, the device audio/MIDI APIs are not the bottleneck.

Things like JACK (which tend to draw complaints) don't exist on other
platforms (except ... by running JACK there), so complaining about its
complexities (not that you did, explicitly) isn't really fair since that is
based on an apples-to-oranges comparison.

I would guess that the options you miss are the result of application and
plugin developers (not) being willing to include Linux in their target
platforms. As cool as PipeWire _might_ turn out to be, it isn't going to have
much effect on those decisions.

Finally, lots of people seem to manage to forget how for years (decades,
perhaps), high performance audio software on Windows required _new device
drivers_ (ASIO) for your audio hardware, because the ones that came with
Windows couldn't do the job. This has mostly changed now, but ASIO is still
with us nevertheless.

~~~
RossBencina
I don't know whether the audio APIs are a bottleneck for programmers, but for
me complexity of _configuring_ ALSA[1] is a massive bottleneck to expecting
_average users_ to be able to do prosumer audio on Linux.

With ASIO on Windows, all the user need do is install the driver and then
select the ASIO device in their application. On Linux, if something is wrong
with your ALSA config, you need to break out the text editor and become an
expert in ALSA architecture and configuration. I've seen enough lost souls in
this situation asking questions on mailing lists that I am convinced it is a
major problem.

As someone interested in deploying an end-user application to Linux, the fact
that there is no plug-and-play "it just works" solution[2] for low-latency
audio is a big problem.

[1] More specifically: resolving misconfiguration.

[2] By this I mean a solution that works by design, not by luck.

~~~
cycloptic
Pipewire is probably not going to make your ALSA configuration issues go away.
It's built on top of ALSA just like everything else. What it might do is make
it easier to have low-latency audio across multiple devices. And it may save
you some of the hassle of having to configure JACK and LADISH.

Would you care to mention what your device and particular misconfiguration
problem is? I can't guarantee I can help, and if it turns out the issue is due
to drivers then there's not really anything a sound server like
Pulse/JACK/Pipewire can do about it. You can't design around that, it
literally is just bad luck that you happened to have a device that is badly
supported.

~~~
RossBencina
Thanks for offering to help. I'm okay at the moment. I was referring to other
users reporting issues that turn out to be ALSA configuration problems (e.g.
on the PortAudio mailing list). Sidenote: the fact that someone needs to offer
help is part of the issue that I'm pointing at. Once a driver is installed on
Windows or Mac OS I've never heard of someone experiencing misconfiguration of
the audio subsystem as a whole.

The main ALSA misconfiguration issue I've personally encountered were not
related to the audio drivers per-se, but to codec mixer configuration. It was
on RK3399 SBCs from FriendlyArm. In that case I had to read the codec data
sheet to work out how to set all the ALSA mixer flags and parameters correctly
to get audio routing to send a signal to the output jack.

~~~
cycloptic
I'm not sure what larger issue you're pointing at and I don't think it makes
sense to chalk this up to anything else; no sound server can magically figure
out how to read that data sheet either. A random userspace daemon (that is
optional) is just not the right place to put a fix for that. The burden for a
fix likely falls on your distro to ship the correct udev rules, but figuring
out what those are for all variations of hardware that use that driver is
another story. With that who knows, the Windows and Mac driver could actually
be doing something strange by default that just happens to work for most
users, but isn't worth replicating if someone writing udev rules decides they
want to do the "right" thing. See where I'm going with this? It's not just a
quick fix, and I don't even know if it's the right one. Some other distro
somewhere might even have a different way to do it. If you're really
interested to make progress on this, you'll have to ask your distro's audio
maintainers.

~~~
RossBencina
I think you put it well by writing "Pipewire is probably not going to make
your ALSA configuration issues go away."

I never claimed there was a quick fix, but I kinda hoped that Pipewire/Redhat
have the leverage to fix whatever needs to be fixed in the ALSA API to make
userspace audio a seamless experience.

My naive impression is that the ALSA driver model is "broken"[1] -- most
likely because many parts that need to seamlessly work together are atomized
into different subsystems with no one organisation held responsible. As you
seem to be suggesting, correct operation appears to depend on correct
configuration by either the distro and/or the end user.

There should be nothing to configure. The driver architecture should be
structured such that it is not possible to ship a "working driver" that then
requires individual distro maintainers to intervene for the user to experience
"working audio". For example, if the mixer hardware needs to be configured for
correct operation, that configuration should be part of the driver or kernel,
not some auxiliary file that may or may not be correct in a given distro.

[1] where by "broken" I mean that it incapable of providing the kind of zero
configuration plug and play experience that is available on Windows with ASIO,
or with CoreAudio.

~~~
PaulDavisThe1st
Ross, the main issue with ALSA these days is not the API at all. It's the
cases where the people responsible for the code cannot get (easy) access to
the information required to program whatever hardware mixer is present in the
device.

This can be true for devices following the Intel HDA "specification" (which is
still so loosely constructed when it comes to the mixer that it's barely a
specification at all). It's also true for many of the USB interfaces out there
- the audio/MIDI I/O part works flawlessly on Linux (thanks to iOS' "no
driver" requirement), but there's no way to configure the hardware mixer. MOTU
went with a web-based configuration process for some of their devices, which
is truly lovely since it works on any device with a web browser. But companies
like Focusrite (and many more) continue to refuse to openly provide the
information required for the ALSA internals to control the hardware mixer on
these devices. In some cases, they have been reverse engineered, but often
only partially.

Note that the same limitation applies when using those devices on iOS: you
cannot configure them fully, unless the manufacturer makes an iOS version of
the "device control panel".

------
techntoke
Does this mean we'll finally see Zoom screen sharing with Wayland? Hope the
Zoom team gets this resolved soon.

------
PaulHoule
Note this is developed by a Red Hat engineer, so this is an an open source IBM
contribution to Linux.

