PipeWire 0.3.22 Released With Many Improvements

[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/...r-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/foru...88#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.

[s_j_newbury]

I use pulseaudio system-wide with 5.1 DTS encoding via ALSA to my receiver. This allows me to output best quality with remixing and minimal resampling since I try to make sure I have everything configured to the native 48000Hz. I use system-wide because I want to have things like mpd working without needing a running desktop session, and be able to mix session sound and games etc as needed with access controls.

I know it never has been a recommended setup, but with a few tweaks this setup works perfectly with the sole exception of clicks when changing volume as the buffers get rewound, and even as a network sink.

I would like to have pipewire working too or instead of pulseaudio if it could replicate this setup, but there appears no way to have pipewire either connect to a system pulseaudio, or itself run in system mode. Am I missing something or just completely out of luck?