Red Hat / Fedora To Focus On Driving New Linux Video Improvements Around PipeWire

[caligula]

Yes and no.
https://github.com/wwmm/easyeffects

People were attempting to add audio effects like noise removal with pulseeffects before pipewire. So not having routing graphs and DSP effects in pulseaudio was leading to some horrible work around as well.

Horrible workarounds? Do you even realize how pulseaudio works? The sink/source model is pretty easy to comprehend as well as the PA LADSPA plugins. The same plugins also work for ALSA. First, learn how PA and ALSA differ here. Then we can discuss what this horrible workaround is that you're referring to. The main difference between PW and PA here is PW supports lower latency and has a bit different behavior wrt rewinds and buffers.

See the yes and no. Yes it is slightly more complex but over all its not more complex because you don't have horrible hackly solutions for like pulseeffects was to add in functionality. Pipewire might be just at the ideal sweet spot for a audio sound server on complexity. The hard problem of being complex enough to perform the tasks required and not too complex to use.

The issue I'm talking about is that modern workstations are inherently more complex than those simple SB16 era ISA sound cards. An average user doesn't want to know about multiple devices, multiple output ports (e.g. for a pair a stereo speakers you now have 4 different audio jacks in the mobo), or switching of audio streams between multiple sinks/sources/ports. For example, it might be easier to redirect all sound to device A or B, application specific controls may seem too complex for a simple use case. For instance, now each browser tab has a separate entry in the mixer. PW makes this even worse because you can control each channel separately, you can reroute channel L from stream 10 to port 2 in device A and channel R to port 3 in device B. You can even clone the streams and whatnot. The carla GUI interface is totally useless if you have 200 tabs and 5 audio devices with 20 ports. It's good for pro audio, but I don't get how normal users work with PW. Maybe they'll still use the Pulseaudio pavucontrol?

[Charlie68]

If you want professional audio on Linux you need your head examined.

You don't know what you're talking about ...

I have a professional musician friend who uses the vanilla kernel and makes professional audio, today it is no longer necessary in the vast majority of cases to use the low latency kernel, the difference is then the hardware in use and its compatibility with the linux kernel .

[oiaohm]

What does it mean that "Linux systems also report lower latency in audio recording"? Who are they reporting to and in what fashion?

The article also fails to mention that Linux can only really be used for serious DAW if you swap out the default kernel and instead use a low latency or real time kernel. Comparing such a modified Linux based distro against a default Windows or OSX setup is dishonest.

That article is right for the current state. What you said was true about 5 years back. If you have not swap out the default kernel you are still ahead using Linux over a Windows or OSX setup. Its due to how much of the real-time tree of Linux is merged mainline these days.

https://jackaudio.org/faq/realtime_v...me_kernel.html

You want to run JACK with very low latency settings that require realtime performance that can only be achieved with an RT kernel
Your hardware configuration triggers poor latency behaviour which might be improved with an RT kernel

There are only 2 cases to use a real-time kernel of Linux for audio work these days. Yes hardware issues is highest reason. Very low latency setting is past what default Linux kernel will give you and that Linux default kernel is ahead of Windows or OSX setup already.

The direction on usage of a realtime kernel changed about 4 years back with jack audio that you need to think twice about using it. Hard realtime that the RT kernels of Linux can give you can cause more problems than what they are worth in fact. The Linux kernel soft realtime has been improving leaps and bounds as the real-time tree patches have merged mainline.

sophisticles basically stock Linux kernel beats windows and mac os in that department these days. Then real-time patched versions of Linux can slightly beat Linux. Real-time scheduler is include in the default Linux kernels for over 5 years and over the past 5 years more and more of the real-time tree is merging into the mainline kernel causing quite a marked change in position.

https://www.phoronix.com/scan.php?pa...g-In-Linux-515 yes even more RT patches merged with 5.15. This has progressive result in less and less cases you should use a specialist real-time kernel with Linux. And this has also lead to a progressively growing gap in default functionality for audio between Linux and other OS options in Linux favour of course.

Part of the reason for the pipewire work is due to the fact you don't need specialist kernel in 99.9% for audio work any more with Linux. So the problem between pulseaudio and jack had to be solved.

[sophisticles]

https://www.musicianwave.com/best-da...ntu-free-paid/
Linux systems also report lower latency in audio recording than hardware-equivalent Windows and Mac systems, which is a great advantage when it comes to recording heavy sessions with dozens of inputs.

What does it mean that "Linux systems also report lower latency in audio recording"? Who are they reporting to and in what fashion?

The article also fails to mention that Linux can only really be used for serious DAW if you swap out the default kernel and instead use a low latency or real time kernel. Comparing such a modified Linux based distro against a default Windows or OSX setup is dishonest.

[oiaohm]

I'm on pulseaudio (like most Linux users) and I don't recall experiencing any issues. What problems were so common that it warranted Pipewire development as a replacement?

You have pal666 list

no video support? mutual exclusion with jack? not designed for containers?

This is very undetails. Video support is that pipewire can use the audio sync interface in alignment with the video sync interfaces making it simpler to in fact get video output synced with audio.

Containers with pipewire you can have jack applications in flatpak and equal and have them authorised to access the host. Jackaudio does not support containers. Pulseaudio requires a wrapper to support containers as well. A container application that only wants audio output should not be allowed to capture audio and things like this. This is another area of pipewire increased meta data space and the fact it can process a permission system. Pipewire is more feature rich in most cases there is one exception.

One of the big ones is a feature pipewire intentionally does not have as mentioned eariler.
https://www.phoronix.com/forums/foru...10#post1282410

Pipewire lacks buffer rewinding. This means once audio is sent to output there is no changing your mind at all. This sounds like a disavantage until you wake up 99% of the cause of pulseaudio generating by it self a audio hiss/crackle requiring you to kill/restart pulseaudio to fix is in fact the rewind feature gone off the rails. Due to the way human hearing works most time will not at all notice a buffer of audio missing. But human will absolutely notice if the buffer rewind code screws up. And there are many ways buffer rewinding can screw up resulting buffer rewind that is run over play point of the output device yes this causes a messed up audio being individual crackles, hisses, pops and if it looping screw up constant crackles, hisses and pops yes those three things end users don't particularly like.

[pal666]

What problems were so common that it warranted Pipewire development as a replacement?

no video support? mutual exclusion with jack? not designed for containers?

[pal666]

Glad I dont use this crap.

browser or kernel?

[pal666]

I'm probably wrong.

that's a safe bet

[pal666]

a system component has reached a stable status

in biology stable means dead

[You-]

I'm on pulseaudio (like most Linux users) and I don't recall experiencing any issues. What problems were so common that it warranted Pipewire development as a replacement?

From what I read a lot of early pulseaudio bugs were due to canonical having misconfigured it in Ubuntu. It also exposed a lot of bugs in underlying drivers using functionalit that hadnt been used as much at that stage.

Pipewire mostly has a different focus - Pulseaudio was designed before desktop containerisation became a thing. Having to retro-fit it would have been a big challenge.

Pipewire is standing the shoulders of giants though - without all the work of pulseaudio and the fixing of bugs it exposed in alsa drivers