PipeWire 0.3.22 Released With Many Improvements

[angrypie]

Can you please inform your self, at least a tiny bit, before posting garbage. The pipewire and pulseaudio projects worked together to split out all the policy and audio setup code in pulseaudio to a library. So, the reason Pipewire have been able to get things working so well so fast, is because they are actually using puleaudio for the configuration and setup.

Source: trust me bro

[ix900]

Not sure it's very representative. Maybe for a 5.1 soundbar directly hooked to your graphics card or motherboard. But a sound bar still only fake surround sound.
But for actual 5.1/7.1/Atmos, you'll need an AV receiver processing and distributing the sound where it's due. And that has always been tricky on Linux. I have no clue how it's faring on other OSes.

When Pulseaudio came out, it worked mostly well, but needed some tweak to daemon.conf and default.pa for proper 5.1 or to order the channels (left and right were inverted or no 5.1, etc...). It was only solved around 2015 for me. Although I'm not sure LFE-remixing has ever been solved (bass redirecting).
Then amdgpu grew between 2017-2018 and I had a whole new lot of sound and video passthrough issues for 18 months. It finally matured enough for these to be solved.

My point is I don't think it'll be enough with headphones. Hooking to an AV receiver (for the real surround experience) has always been tricky and you can't just simulate that.

I don't get why this is so bad for you. You hook the multi-channel receiver into the hdmi out of the gpu and it should work great on any OS as long as you have a driver worth using. The software (game, entertainment player, etc) is the worst offender today. Many game devs don't include support for greater than stereo.

The best alternative to get multi-channel sound when software limits it is to have a receiver that upgrades it with processing. Fake yes, but still sounds great when a receiver does it well.

It was worse before gpu's and motherboards came with hdmi out. Not so bad since. I don't consider it tricky at all. Plug hdmi into gpu. Get good gpu driver. Profit. That's it. If it takes more than that for you, I don't get it. Your system is broken.

[Bigon]

You can tell Pipewire is a serious project when they implement in a few months stuff that took years for Poettering to fix.

Poettering is not working on pulseaudio for more than 10 years...

[RahulSundaram]

Source: trust me bro

From

https://github.com/PipeWire/pipewire

"PulseAudio applications still use the regular PulseAudio client libraries"

Any improvements done by PulseAudio developers at the ALSA kernel layer continue to be leveraged by everyone including PipeWire. Look at the architecture for details on that.

[oiaohm]

From

https://github.com/PipeWire/pipewire

"PulseAudio applications still use the regular PulseAudio client libraries"

Any improvements done by PulseAudio developers at the ALSA kernel layer continue to be leveraged by everyone including PipeWire. Look at the architecture for details on that.

I see you had miss read.
The pipewire and pulseaudio projects worked together to split out all the policy and audio setup code in pulseaudio to a library. So, the reason Pipewire have been able to get things working so well so fast, is because they are actually using puleaudio for the configuration and setup.

This is not in fact true. Pipewire has a pulseaudio replacement server. This does not use the same policy or setup as pulseaudio yes able to talk pulseaudio protocol so perfectly that client side libraries work mostly.

https://gitlab.freedesktop.org/pipew.../Configuration Fixes you have done in the pulseaudio configuration files on disc if required need to be redone in the pipewire configuration files.

Pipewire has a proper per application policy system suitable for use with flatpak and others that pipewire does not. So yes pipewire has a different policy engine just a policy engine that is mostly compatible with pulseaudio policy engine for running pulseaudio applications. Please note I said mostly compatible there are things you can do with pactl to attempt to change policy and the policy will not change with pipewire because its not supported these are fairly exotic settings but do absolute prove that the policy engines are in fact completely different. Remember pipewire policy engine is design to support most of the policy engine features of features jack audio and pulseaudio and other parts its most because there are cases where both are not doable and one has to chosen this is not all pulseaudio policy engine features are in pipewire. There are also feature pipewire has never implemented that appear to be totally not used by any normal application that were both added to jack audio and pulseaudio because some developer thought they were a good idea at the time.

daemon/server side of pulseaudio and pipewire there are lots of differences. The way the buffers internally are done in pipewire is way different to pulseaudio resulting in the daemon/server configuration being very different. Yes this is the bug pulseaudio picked up from the first developer starting on a defective audio driver and thinking that is how audio should work. True Low latency with pipewire is either direct pipewire or jackaudio interfaces not the pulseaudio interfaces.

Yes pipewire picks up a lot from the work Pulseaudio developers have like like the Alsa driver improvements but the policy engine and configuration is not one of these things.

[AnAccount]

Source: trust me bro

Or you could learn how to use a search engine, there are multiple options out there. But since you seems totally incapable of even the simplest tasks I'll be nice:

https://blogs.gnome.org/uraeus/2020/09/04/pipewire-late-summer-update-2020/

With the relevant part:

Wim took the code and configuration data in Pulse Audio for ALSA Card Profiles and created a standalone library that can be shared between PipeWire and PulseAudio. This library handles ALSA sound card profiles, devices, mixers and UCM (use case manager used to configure the newer audio chips (like the Lenovo X1 Carbon) and lets PipeWire provide the correct information to provide to things like GNOME Control Center or pavucontrol. Using the same code as has been used in PulseAudio for this has the added benefit that when you switch from PulseAudio to PipeWire your devices don’t change names. So everything should look and feel just like PulseAudio from an application perspective. In fact just below is a screenshot of pavucontrol, the Pulse Audio mixer application running on top of Pipewire without a problem.

You are welcome!

[RahulSundaram]

[QUOTE=oiaohm;n1240457]

I see you had miss read.
The pipewire and pulseaudio projects worked together to split out all the policy and audio setup code in pulseaudio to a library. So, the reason Pipewire have been able to get things working so well so fast, is because they are actually using puleaudio for the configuration and setup.

"This is not in fact true. "

Just to be clear, I didn't make this claim.

[AnAccount]

I see you had miss read.
The pipewire and pulseaudio projects worked together to split out all the policy and audio setup code in pulseaudio to a library. So, the reason Pipewire have been able to get things working so well so fast, is because they are actually using puleaudio for the configuration and setup.

This is not in fact true. Pipewire has a pulseaudio replacement server. This does not use the same policy or setup as pulseaudio yes able to talk pulseaudio protocol so perfectly that client side libraries work mostly.

See my post for reference:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1240086-pipewire-0-3-22-released-with-many-improvements?p=1240488#post1240488

[oiaohm]

See my post for reference:
https://www.phoronix.com/forums/foru...88#post1240488

Audio setup code/quirk database stuff was split out. Not the policy engine or the complete policy. Pipewire and pulseaudio have different policy engines what results in very different server configuration come from the same hardware starting data.

29 May, 2020 first commit https://gitlab.freedesktop.org/wtaym...commits/master

There is a problem here 29 May 2020 pipewire has already been doing audio for quite some time at this point.

https://lac2020.sciencesconf.org/307881/document

Pipewire policy engine include a full blown security engine and proper low latency design. Remember pipewire is proper low latency design so Pulseaudio and Pipewire policy engine gets the same card information yet pipewire policy engine may be allocating a smaller buffers than Pulseaudio would have used.

split out all the policy

Its the this bit that wrong because its not all. Part of Pulseaudio policy has been split out to make migration simpler and hardware quirk handling simpler. But this is not all of the pulseaudio policy. There are part of the Pulseaudio policy that make sense with a pulseaudio that make absolutely no sense in the Pipewire and the reverse is also true.

Its also to be aware that you could have a pipewire hissing with a particular audio out because by pipewire engine its choosen a smaller buffer size that pulseaudio engine because the shared policy information is being processed differently. So you need to adjust pipewire policy so it works right at times. Yes this sometimes can be that the alsa quirk information is wrong but users with pulseaudio would not have a problem because pulseaudio policy engine would never pick that small buffer size.

The shared policy has not been as major of a boost as it first appears because there is still lots of checking and correcting required due to the engine differences.

[angrypie]

You are welcome!

Thank you, self-important anonymous poster, but you've already been proven wrong.