https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
== Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email: wim.taymans@gmail.com
== Detailed Description == Currently, all desktop audio is handled by the PulseAudio daemon. Applications make use of the PulseAudio client library to communicate with the PulseAudio daemon that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel (gnome-control-panel) both use the Pulseaudio client libraries to manage the volume and configuration of the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to the JACK server. This proposal will install a JACK client library replacement that talks directly to PipeWire. All existing PRO audio jack applications will then work on top of PipeWire.
For legacy ALSA clients, we will install an ALSA plugin that routes the audio directly to PipeWire.
With these 3 changes, all audio will be routed to PipeWire. There will then be no more need to install the PulseAudio and JACK daemons.
== Feedback == The owner of this proposal has been in context with both the PulseAudio and JACK maintainers and community. PipeWire is considered to be the successor of both projects.
== Benefit to Fedora == The end goal is to end up with one audio infrastructure for both Desktop and Pro audio use cases. This will end the fragmentation of the audio landscape.
Some of the benefits that PipeWire will bring:
* PRO Audio features
PipeWire can support both Desktop and PRO Audio use cases. PRO Audio application tend to use the JACK API and JACK daemon, which is hard to setup and integrates poorly with the rest of the system (and PulseAudio in particular).
With a replacement libjack library, PRO Audio application can run directly on PipeWire and integrate seamlessly with other ALSA and PulseAudio applications. This would bring Fedora closer to the experience of other operating systems.
* Flexibility/Integration
PipeWire is designed to be multiprocess. It separates the processing of the multimedia graph and the management into separate processes. This makes it possible to better integrate with the other system components or swap out the default policy for a highly customized one (such as for automotive or embedded). This is in contrast to PulseAudio, which has all logic embedded into the daemon with limited configuration options.
In the next phase we expect to greatly expand the user experience and configuration of the audio infrastructure with better integration throughout the system.
* Performance
PipeWire was designed for high performance and low-latency, using much of the same design as JACK. JACK application should run with comparable performance even in low-latency situations.
* Security
PipeWire enforces per client security. Object visibility and the actions on them can be configured independently per client. This makes it possible to enforce a security policy for sandboxed applications (Flatpak) such as denying access to certain audio capture devices or block them from interfering with other applications.
* Maintainability
Both PulseAudio and JACK have very slow development cycles with few new features. The more flexible and distributed nature of the design of PipeWire should encourage more new features and use-cases.
== Scope == * Proposal owners: We would make a pipewire-pulse package that provides the same features as the pulseaudio (daemon) package. We would only provide a drop-in replacement daemon, the pulseaudio client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio package is removed and replaced by the pipewire-pulse implementation. In the same way, installing the pulseaudio package would remove the pipewire-pulse package, making it possible to switch between implementations. This will also allow for an easy rollback.
We also need to check and correct the dependencies of other packages. As of this writing, some packages do not state their dependencies correctly and get removed when pulseaudio is removed. We also need to check the JACK to make sure they still install with the replacement JACK client library.
The JACK client libraries will be installed in the same way, removing the old JACK client libraries.
* Other developers: The distribution needs to default to the pipewire-pulse package instead of pulseaudio. JACK applications need to install the pipewire-libjack client library.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) * Policies and guidelines: * Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34
* avahi network discovery and audio routing. This is not enabled by default but can be activated with paprefs. this includes TCP and RTP transport of audio. * make devices available as UPNP media servers. Not enabled by default, paprefs can be used. * easy configuration of combining all sinks. Questionable feature but possible via paprefs.
User scripts will still work but custom configurations of the pulseaudio daemon will not be used anymore.
Most of the JACK workflow of managing the JACK daemon is not going to be needed anymore as things will work out-of-the-box. As of this writing, these things are missing from the JACK implementation, we hope to implement them before fedora 34:
* latency reporting: useful to align streams * freewheeling: used when rendering a project * jackdbus: used by some tools to manage the graph
== How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package).
To test the JACK support, one needs to install pipewire-libjack, which removes the original JACK client and server.
After these changes, a restart is needed to make sure the new pipewire-pulse daemon is running.
Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x) - gnome-control-center: check the audio tab, check the volume sliders and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch. - pavucontrol: check volumes in the input devices tabs and check the microphone volumes - firefox: check out a website with audio/video such as youtube and verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111). - rhythmbox: check if playback works as expected - bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc. - Regular system usage and performance should not change. - JACK tools such as catia, carla should run and can be used to inspect the graph.
== User Experience == In general, users should not be able to see any change when using PulseAudio applications.
The big change is when using JACK application:
- They will start without having to configure and start the daemon. this includes the period size and sample rates. - All devices will be visible in the graph with meaningful names. Devices will be automatically slaved when needed without needing any configuration. - bluetooth devices will be usable as well.
== Dependencies == Other packages might need to have their requirements fixed to work with the replacement packages but this is under our control.
== Contingency Plan == * Contingency mechanism: Keep existing pulseaudio and JACK client libraries as defaults * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No
== Documentation == [https://pipewire.org%5D(PipeWire website) [https://www.youtube.com/watch?v=8LZt4loZu64&t=14s%5D(Video with Current status) [https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md%5D... guide) [https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md%5D(... to use/test)
On 20.11.2020 17:26, Ben Cotton wrote:
This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
IMO, too early. PipeWire is too unstable yet. I suggest postpone this proposal to Fedora 35.
On Fri, 2020-11-20 at 17:36 +0100, Vitaly Zaitsev via devel wrote:
On 20.11.2020 17:26, Ben Cotton wrote:
This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
IMO, too early. PipeWire is too unstable yet. I suggest postpone this proposal to Fedora 35.
Do you have any data to support this assertion?
On 20.11.2020 19:55, Adam Williamson wrote:
Do you have any data to support this assertion?
PipeWire is still in early development. Some features are not implemented and well-tested yet.
We shouldn't break the working audio configuration for end users. They should be able to easily roll back to their previous behavior, if necessary.
Things like bluetooth support, audio for flatpak applications, and the new pulse server were just added in the last month or so and there are issues with stability and audio playback (look at the issue tracker [1]), for example HSP is still marked as WIP [2]. It seems premature to commit to this change before the core features have been stabilized and more testing has been done. Audio is an area where users really have no tolerance for it misbehaving. Pushing a change like this too early can create a negative perception of the project which is something we should try to avoid (within reason).
I also don't know of any current documentation on switching to and testing pipewire with F33 or rawhide since the deprecation of pipewire-libpulse and the introduction of pipewire-pulseaudio, as the old guide relies on libpulse [3]. I think at the very least bluetooth support needs to mature, and pipewire-pulseaudio needs to be tested for 1 full Fedora release cycle, so I would vote for delaying this until F35.
[1] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues [2] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/TODO [3] https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165
On Sat, 21 Nov 2020 19:47:30 -0000 "Tom Seewald" tseewald@gmail.com wrote:
Things like bluetooth support, audio for flatpak applications, and the new pulse server were just added in the last month or so and there are issues with stability and audio playback (look at the issue tracker [1]), for example HSP is still marked as WIP [2]. It seems premature to commit to this change before the core features have been stabilized and more testing has been done. Audio is an area where users really have no tolerance for it misbehaving. Pushing a change like this too early can create a negative perception of the project which is something we should try to avoid (within reason).
According to the FAQ `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ%60
Is PipeWire ready yet?
It is getting ready for broader testing.
There’s also `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Limitations-in-0.3%...
Upstream says it is not ready!
Linux has had a large number of audio systems (OSS, ALSA, ESD, pulseaudio, and probably some I’ve forgotten), and almost as many painful transitions from one to the next. Since then audio has become a vital part of the computer desktop experience. Please make this less painful and don’t make this the default until it is ready and tested.
Jim
On Sat, Nov 21, 2020 at 3:53 PM James Szinger jszinger@gmail.com wrote:
On Sat, 21 Nov 2020 19:47:30 -0000 "Tom Seewald" tseewald@gmail.com wrote:
Things like bluetooth support, audio for flatpak applications, and the new pulse server were just added in the last month or so and there are issues with stability and audio playback (look at the issue tracker [1]), for example HSP is still marked as WIP [2]. It seems premature to commit to this change before the core features have been stabilized and more testing has been done. Audio is an area where users really have no tolerance for it misbehaving. Pushing a change like this too early can create a negative perception of the project which is something we should try to avoid (within reason).
According to the FAQ `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ%60
Is PipeWire ready yet? It is getting ready for broader testing.There’s also `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Limitations-in-0.3%...
Upstream says it is not ready!
Linux has had a large number of audio systems (OSS, ALSA, ESD, pulseaudio, and probably some I’ve forgotten), and almost as many painful transitions from one to the next. Since then audio has become a vital part of the computer desktop experience. Please make this less painful and don’t make this the default until it is ready and tested.
The upstream developer of PipeWire is the one who submitted this Change proposal. Before this proposal was submitted, he talked to us in the Workstation WG about it and stated that he's confident that PipeWire is in good shape for Fedora 34 and provides a straightforward way to fall back to legacy PulseAudio as needed.
On Sat, 21 Nov 2020, Neal Gompa wrote:
On Sat, Nov 21, 2020 at 3:53 PM James Szinger jszinger@gmail.com wrote:
On Sat, 21 Nov 2020 19:47:30 -0000 "Tom Seewald" tseewald@gmail.com wrote:
Things like bluetooth support, audio for flatpak applications, and the new pulse server were just added in the last month or so and there are issues with stability and audio playback (look at the issue tracker [1]), for example HSP is still marked as WIP [2]. It seems premature to commit to this change before the core features have been stabilized and more testing has been done. Audio is an area where users really have no tolerance for it misbehaving. Pushing a change like this too early can create a negative perception of the project which is something we should try to avoid (within reason).
According to the FAQ `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ%60
Is PipeWire ready yet? It is getting ready for broader testing.There’s also `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Limitations-in-0.3%...
Upstream says it is not ready!
Linux has had a large number of audio systems (OSS, ALSA, ESD, pulseaudio, and probably some I’ve forgotten), and almost as many painful transitions from one to the next. Since then audio has become a vital part of the computer desktop experience. Please make this less painful and don’t make this the default until it is ready and tested.
The upstream developer of PipeWire is the one who submitted this Change proposal. Before this proposal was submitted, he talked to us in the Workstation WG about it and stated that he's confident that PipeWire is in good shape for Fedora 34 and provides a straightforward way to fall back to legacy PulseAudio as needed.
I spent about three weeks trying to live with pipewire in October/November and encountered a lot of issues, most of them were already reported. The most important one is instability of conference calls with Google Meet in both Firefox and Chrome and inability to share more than a single browser page window on Wayland. The pipewire and its portal are stating everything is ok but the content is simply not streaming out.
Also, constant change of the audio inputs and outputs, like arbitrarily switching the defaults for mic between USB devices, thunderbolt-based dock and the built-in one on Thinkpad attached to the dock, is making it very hard to accept it is a stable and predictable software.
These are the ones that really turned me away from using pipewire on F33. I tried twice: first with F32, then F33 and it is simply not ready for even basic office use case with a laptop in dock and multiple monitors with audio outputs.
This is just one evidence point, of course, and highly personal, but I do not see how pipewire could become a default with the current quality. Shipped in parallel, with easy to switch ways, sure.
So has this essentially been decided on by the working group? If not, what concerns would be listened to?
On Sat, Nov 21, 2020 at 4:57 PM Tom Seewald tseewald@gmail.com wrote:
So has this essentially been decided on by the working group? If not, what concerns would be listened to?
Well, the idea would be for us to put it into Rawhide and do a series of test days/weeks to get feedback and close any remaining gaps. If it doesn't manage to pull through by beta freeze, then we would revert and push it back to Fedora 35.
On Sat, Nov 21, 2020 at 05:05:59PM -0500, Neal Gompa wrote:
On Sat, Nov 21, 2020 at 4:57 PM Tom Seewald tseewald@gmail.com wrote:
So has this essentially been decided on by the working group? If not, what concerns would be listened to?
Well, the idea would be for us to put it into Rawhide and do a series of test days/weeks to get feedback and close any remaining gaps. If it doesn't manage to pull through by beta freeze, then we would revert and push it back to Fedora 35.
Additionally one thing to note: Fedora 34 is scheduled to release 2021-04-20 and the change complete checkpoint is 2021-02-23.
Thats 3 months to make sure it's solid or revert it at the end if not. (Granted with some holidays in there).
kevin
On 11/21/20 4:05 PM, Neal Gompa wrote:
On Sat, Nov 21, 2020 at 4:57 PM Tom Seewald tseewald@gmail.com wrote:
So has this essentially been decided on by the working group? If not, what concerns would be listened to?
Well, the idea would be for us to put it into Rawhide and do a series of test days/weeks to get feedback and close any remaining gaps. If it doesn't manage to pull through by beta freeze, then we would revert and push it back to Fedora 35.
I feel like for something as fundamental to the desktop experience as audio a few test days would really expose all of the pain points. At least personally my uses of audio vary quite a bit day to day and week to week, especially in the current environment.
I would be a lot happier if there was a documented way to enable this for F32 / F33 so the brave could try living with it for a prolonged period of time.
On 11/21/20 6:00 PM, Brandon Nielsen wrote: [Snip]
I feel like for something as fundamental to the desktop experience as audio a few test days would really expose all of the pain points. At least personally my uses of audio vary quite a bit day to day and week to week, especially in the current environment.
_Wouldn't_ really expose all the pain points.
I would be a lot happier if there was a documented way to enable this for F32 / F33 so the brave could try living with it for a prolonged period of time.
Well, the idea would be for us to put it into Rawhide and do a series of test days/weeks to get feedback and close any remaining gaps. If it doesn't manage to pull through by beta freeze, then we would revert and push it back to Fedora 35.
Did these test days/weeks ever happen? I don't recall seeing an announcement or any talk about their results.
On 2/19/21 3:47 PM, Tom Seewald wrote:
Well, the idea would be for us to put it into Rawhide and do a series of test days/weeks to get feedback and close any remaining gaps. If it doesn't manage to pull through by beta freeze, then we would revert and push it back to Fedora 35.
Did these test days/weeks ever happen? I don't recall seeing an announcement or any talk about their results.
Final preparations are happening now: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/t...
I'm using rpm-ostree based fedora system (fedora 33) with pipewire and after latest update pipewire-0.3.23-1.fc33.x86_64 pipewire-alsa-0.3.23-1.fc33.x86_64 pipewire-pulseaudio-0.3.23-1.fc33.x86_64 pipewire-utils-0.3.23-1.fc33.x86_64 pipewire-libs-0.3.23-1.fc33.x86_64 pipewire0.2-libs-0.2.7-4.fc33.x86_64 pipewire-gstreamer-0.3.23-1.fc33.x86_64
gnome can't output any sounds because output devices are empty. alsamixer displays my sound card, but the default pipewire output is empty.
сб, 20 февр. 2021 г. в 23:05, Brandon Nielsen nielsenb@jetfuse.net:
On 2/19/21 3:47 PM, Tom Seewald wrote:
Well, the idea would be for us to put it into Rawhide and do a series of test days/weeks to get feedback and close any remaining gaps. If it doesn't manage to pull through by beta freeze, then we would revert and push it back to Fedora 35.
Did these test days/weeks ever happen? I don't recall seeing an announcement or any talk about their results.
Final preparations are happening now: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/t... _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, Nov 21, 2020 at 9:56 pm, Tom Seewald tseewald@gmail.com wrote:
So has this essentially been decided on by the working group?
We decided to submit a change proposal through the usual change process. :) It includes a fallback plan to defer the change in case there are too many unexpected problems.
If not, what concerns would be listened to?
I think we'd be most interested in practical user experience issues, like the ones that Alexander has mentioned already. Particularly if there is a bug report.
Michael
Hi, I thought this Change was exciting to see, even if it has some room to improve as pointed out earlier in the thread.
On 11/21/20 6:43 PM, Michael Catanzaro wrote:
I think we'd be most interested in practical user experience issues, like the ones that Alexander has mentioned already. Particularly if there is a bug report.
An alternative to `pavucontrol` is something we discussed in the i3wm SIG. Currently we find it to be the most intuitive graphical interface available for managing audio devices and streams.
One thing I would like to see (without having looked very hard yet) is to know what the migration impact is for end-users moving from PulseAudio controller tools and interfaces to PipeWire.
On 11/21/20 7:00 PM, Brandon Nielsen wrote:
I would be a lot happier if there was a documented way to enable this for F32 / F33 so the brave could try living with it for a prolonged period of time.
Me too! I know I would probably try this out on my personal Workstation i f I had some good docs on how to migrate it. Especially with some kind of estimate of time needed to complete, so I can measure how long before I will need a functioning audio stack to jump into a video call where people need to hear/see me. ;)
On Sat, 21 Nov 2020 15:56:23 -0500 Neal Gompa ngompa13@gmail.com wrote:
On Sat, Nov 21, 2020 at 3:53 PM James Szinger jszinger@gmail.com wrote:
According to the FAQ `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ%60
Is PipeWire ready yet? It is getting ready for broader testing.There’s also `https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Limitations-in-0.3%...
Upstream says it is not ready!
The upstream developer of PipeWire is the one who submitted this Change proposal. Before this proposal was submitted, he talked to us in the Workstation WG about it and stated that he's confident that PipeWire is in good shape for Fedora 34 and provides a straightforward way to fall back to legacy PulseAudio as needed.
Even the change proposal says it is not ready.
We would make a pipewire-pulse package that provides the same features as the pulseaudio (daemon) package.
As of this writing, these things are missing from the JACK implementation, we hope to implement them before fedora 34:
There is software to be written between now and beta freeze. When is supposed to be tested?
It’s also not feature complete:
pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34 …
I also found a couple more problems:
1. No end-user documentation on pipewire.org. There are a few man pages, but nothing that answers “How do I do this?” Compare to `https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/%60 and the massive number of Google hits.
2. No native management tools. The change proposal says to test the usual pulseaudio and JACK tools (patcl, pavucontrol, catia, carla, qjackctl), but does not mention any native tools. This is a problem because the PA and JACK tools will manage different subsets of pipewire, potentially causing much confusion and wailing.
Jim
On 11/22/20 10:26 AM, James Szinger wrote:
- No native management tools. The change proposal says to test the
usual pulseaudio and JACK tools (patcl, pavucontrol, catia, carla, qjackctl), but does not mention any native tools. This is a problem because the PA and JACK tools will manage different subsets of pipewire, potentially causing much confusion and wailing.
Actually, it's completely transparent between PulseAudio and JACK tools: they see each other the way they normally would. In fact, the JACK tools can see each individual PulseAudio application as a separate JACK client, which eliminates the need for a PulseAudio-JACK bridge.
On Sun, Nov 22, 2020 at 11:26:11AM -0700, James Szinger wrote:
Even the change proposal says it is not ready.
We would make a pipewire-pulse package that provides the same features as the pulseaudio (daemon) package. As of this writing, these things are missing from the JACK implementation, we hope to implement them before fedora 34:There is software to be written between now and beta freeze. When is supposed to be tested?
It's supposed to be 'testable' by: Change Checkpoint: Completion deadline (testable) Tue 2021-02-09 and 100% code complete by: Change Checkpoint: 100% Code Complete Deadline Tue 2021-02-23
kevin
On Sun, Nov 22, 2020 at 11:33:22AM -0800, Kevin Fenzi wrote:
It's supposed to be 'testable' by: Change Checkpoint: Completion deadline (testable) Tue 2021-02-09 and 100% code complete by: Change Checkpoint: 100% Code Complete Deadline Tue 2021-02-23
Given that Beta Freeze is 2021-03-16, barely over a month is frightfully little time to adequately test something that has such an impact on the end-user experience.
- Solomon
On Sun, Nov 22, 2020 at 06:03:50PM -0500, Solomon Peachy wrote:
On Sun, Nov 22, 2020 at 11:33:22AM -0800, Kevin Fenzi wrote:
It's supposed to be 'testable' by: Change Checkpoint: Completion deadline (testable) Tue 2021-02-09 and 100% code complete by: Change Checkpoint: 100% Code Complete Deadline Tue 2021-02-23
Given that Beta Freeze is 2021-03-16, barely over a month is frightfully little time to adequately test something that has such an impact on the end-user experience.
Barely over a month? I guess you are dropping all of this month, next month and january? That seems a bit unfair.
In any case if it's not ready by change checkpoint, it can/would be reverted. Several big changes have had that happen to them, and it's been for the better as they got all the testing up to that point and were ready for the next cycle.
kevin
On 24.11.2020 22:29, Kevin Fenzi wrote:
Barely over a month? I guess you are dropping all of this month, next month and january? That seems a bit unfair.
Yes. We need at least 1 full Fedora release to test everything on real hardware. Optional PipeWire in F34 and default in F35.
On 11/20/20 8:36 AM, Vitaly Zaitsev via devel wrote:
IMO, too early. PipeWire is too unstable yet. I suggest postpone this proposal to Fedora 35.
The person who wrote the change proposal is the lead developer of Pipewire. He believes it is stable enough (or will be) by the time F34 branches. And to be honest, it won't get enough testing without being *at least* submitted to Rawhide.
With my Fedora Jam hat on (read: professional audio), I believe it's the right move. It's stable *enough* and needs to be tested by the public. If it's still too unstable, then there's a contingency plan. BUT, if we don't move forward *now* we'll wait another decade, and be in the same situation that Wayland is in.
The time to move forward is *now*. If we keep being scared, we'll never get anywhere.
On 20.11.2020 20:00, Erich Eickmeyer wrote:
With my Fedora Jam hat on (read: professional audio), I believe it's the right move. It's stable *enough* and needs to be tested by the public. If it's still too unstable, then there's a contingency plan. BUT, if we don't move forward *now* we'll wait another decade, and be in the same situation that Wayland is in.
Yes, but we shouldn't break the working audio configuration for end users. They should be able to easily roll back to their previous behavior, if necessary.
If the `dnf swap pulseaudio pipewire-pulse` and vice versa will work fine, I'm totally agree with this change.
Am 20.11.20 um 17:36 schrieb Vitaly Zaitsev via devel:
On 20.11.2020 17:26, Ben Cotton wrote:
This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
IMO, too early. PipeWire is too unstable yet. I suggest postpone this proposal to Fedora 35.
I checked on the available docu for pipewire .. pipewire.org, gitlab etc.
Most sentences start with "We want to.." not "We have done it..."
Making this Default for anyone in 12months seems like the mother of bad ideas.
Fedora Desktop Linux is doing great at the moment, really. Comparing it to problems other OS have, I just can smile about them, if you understand ;) Putting this at risk is not helpfull for the growing Linux Desktop Segment where Fedora is part of.
Of course, testing is necessary and should be easy possible on a running prod system. I suggest to open a Test page on the fedora wiki, where people see known bugs, instructions how to test it and a fixed test case run ( use videoplayer, check for a delay, use musikplayer, check for cracks between tracks etc. etc. ).
Best regards, Marius Schwarz
Why push this half baked feature for F34, I just tried the F34 cinnamon spin and this feature isn't even alpha quality. I wont be switching cinnamon or any rpmfusion packages I maintain to it till it's rock steady release quality.
Maybe you would like to elaborate, because I have switched yesterday and so far I can't see any difference in functionality.
Vít
Dne 16. 12. 20 v 9:21 Leigh Scott napsal(a):
Why push this half baked feature for F34, I just tried the F34 cinnamon spin and this feature isn't even alpha quality. I wont be switching cinnamon or any rpmfusion packages I maintain to it till it's rock steady release quality. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Maybe you would like to elaborate, because I have switched yesterday and so far I can't see any difference in functionality.
Vít
Dne 16. 12. 20 v 9:21 Leigh Scott napsal(a):
After removing pulseaudio package I have no sound and pipewire-pulse doesn't autostart, pulseaudio used /etc/xdg/autostart to start. Even after activating pipewire-pulse using systemctl it still has no sound.
$ rpm -qa --requires cinnamon* |grep pulse libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit) libpulse-mainloop-glib.so.0()(64bit) libpulse-mainloop-glib.so.0(PULSE_0)(64bit) libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit)
On Wed, Dec 16, 2020 at 5:18 AM Leigh Scott leigh123linux@gmail.com wrote:
Maybe you would like to elaborate, because I have switched yesterday and so far I can't see any difference in functionality.
Vít
Dne 16. 12. 20 v 9:21 Leigh Scott napsal(a):
After removing pulseaudio package I have no sound and pipewire-pulse doesn't autostart, pulseaudio used /etc/xdg/autostart to start. Even after activating pipewire-pulse using systemctl it still has no sound.
$ rpm -qa --requires cinnamon* |grep pulse libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit) libpulse-mainloop-glib.so.0()(64bit) libpulse-mainloop-glib.so.0(PULSE_0)(64bit) libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit)
I'm literally working on getting the automatic activation working. I'm sorry that it's not ready right now, but I'm still going through and fixing it. I'm testing around Fedora KDE at the moment, and while it's "working" it's not fully right just yet.
After removing pulseaudio package I have no sound and pipewire-pulse doesn't autostart, pulseaudio used /etc/xdg/autostart to start. Even after activating pipewire-pulse using systemctl it still has no sound.
CONFESSION: I have found the issue :blush:
I was remotely (virt-manager over ssh) accessing the VM hosted on my workstation, it works fine running host.
On Fri, 2020-11-20 at 11:26 -0500, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
== Owner ==
- Name: [[User:Wtaymans| Wim Taymans]]
- Email: wim.taymans@gmail.com
== Detailed Description == Currently, all desktop audio is handled by the PulseAudio daemon. Applications make use of the PulseAudio client library to communicate with the PulseAudio daemon that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel (gnome-control-panel) both use the Pulseaudio client libraries to manage the volume and configuration of the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to the JACK server. This proposal will install a JACK client library replacement that talks directly to PipeWire. All existing PRO audio jack applications will then work on top of PipeWire.
For legacy ALSA clients, we will install an ALSA plugin that routes the audio directly to PipeWire.
With these 3 changes, all audio will be routed to PipeWire. There will then be no more need to install the PulseAudio and JACK daemons.
== Feedback == The owner of this proposal has been in context with both the PulseAudio and JACK maintainers and community. PipeWire is considered to be the successor of both projects.
== Benefit to Fedora == The end goal is to end up with one audio infrastructure for both Desktop and Pro audio use cases. This will end the fragmentation of the audio landscape.
Some of the benefits that PipeWire will bring:
PRO Audio features
PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use the JACK API and JACK daemon, which is hard to setup and integrates poorly with the rest of the system (and PulseAudio in particular).
With a replacement libjack library, PRO Audio application can run directly on PipeWire and integrate seamlessly with other ALSA and PulseAudio applications. This would bring Fedora closer to the experience of other operating systems.
Flexibility/Integration
PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph and the management into separate processes. This makes it possible to better integrate with the other system components or swap out the default policy for a highly customized one (such as for automotive or embedded). This is in contrast to PulseAudio, which has all logic embedded into the daemon with limited configuration options.
In the next phase we expect to greatly expand the user experience and configuration of the audio infrastructure with better integration throughout the system.
Performance
PipeWire was designed for high performance and low-latency, using
much of the same design as JACK. JACK application should run with comparable performance even in low-latency situations.
Security
PipeWire enforces per client security. Object visibility and the
actions on them can be configured independently per client. This makes it possible to enforce a security policy for sandboxed applications (Flatpak) such as denying access to certain audio capture devices or block them from interfering with other applications.
Maintainability
Both PulseAudio and JACK have very slow development cycles with few
new features. The more flexible and distributed nature of the design of PipeWire should encourage more new features and use-cases.
== Scope ==
- Proposal owners:
We would make a pipewire-pulse package that provides the same features as the pulseaudio (daemon) package. We would only provide a drop-in replacement daemon, the pulseaudio client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio package is removed and replaced by the pipewire-pulse implementation. In the same way, installing the pulseaudio package would remove the pipewire-pulse package, making it possible to switch between implementations. This will also allow for an easy rollback.
We also need to check and correct the dependencies of other packages. As of this writing, some packages do not state their dependencies correctly and get removed when pulseaudio is removed. We also need to check the JACK to make sure they still install with the replacement JACK client library.
The JACK client libraries will be installed in the same way, removing the old JACK client libraries.
- Other developers:
The distribution needs to default to the pipewire-pulse package instead of pulseaudio. JACK applications need to install the pipewire-libjack client library.
- Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
- Policies and guidelines:
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34
- avahi network discovery and audio routing. This is not enabled by
default but can be activated with paprefs. this includes TCP and RTP transport of audio.
- make devices available as UPNP media servers. Not enabled by
default, paprefs can be used.
- easy configuration of combining all sinks. Questionable feature but
possible via paprefs.
User scripts will still work but custom configurations of the pulseaudio daemon will not be used anymore.
Most of the JACK workflow of managing the JACK daemon is not going to be needed anymore as things will work out-of-the-box. As of this writing, these things are missing from the JACK implementation, we hope to implement them before fedora 34:
- latency reporting: useful to align streams
- freewheeling: used when rendering a project
- jackdbus: used by some tools to manage the graph
== How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package).
To test the JACK support, one needs to install pipewire-libjack, which removes the original JACK client and server.
After these changes, a restart is needed to make sure the new pipewire-pulse daemon is running.
Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
- gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch.
- pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
- firefox: check out a website with audio/video such as youtube and
verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111).
- rhythmbox: check if playback works as expected
- bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
- Regular system usage and performance should not change.
- JACK tools such as catia, carla should run and can be used to
inspect the graph.
A client like guitarix (which I use so I am biased :) should be added for testing of the jack infrastructure compatibility IMO.
== User Experience == In general, users should not be able to see any change when using PulseAudio applications.
The big change is when using JACK application:
- They will start without having to configure and start the daemon.
this includes the period size and sample rates.
- All devices will be visible in the graph with meaningful names. Devices will be automatically slaved when needed without needing any configuration.
- bluetooth devices will be usable as well.
== Dependencies == Other packages might need to have their requirements fixed to work with the replacement packages but this is under our control.
== Contingency Plan ==
- Contingency mechanism: Keep existing pulseaudio and JACK client
libraries as defaults
- Contingency deadline: beta freeze
- Blocks release? No
- Blocks product? No
== Documentation == [https://pipewire.org%5D(PipeWire website) [https://www.youtube.com/watch?v=8LZt4loZu64&t=14s%5D(Video with Current status) [https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md%5D... guide) [https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md%5D(... to use/test)
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Ben Cotton wrote on Fri, Nov 20, 2020:
== How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package).
Took me some time to figure out how to test: - there's no such package; there's a pipewire-libpulse that apparently got integrated into pipewire-libs but doesn't replace pulseaudio unlike the comment above (in fc33's update-testing pipewire-0.3.16-1.fc33.x86_64) - /usr/share/doc/pipewire/README.md talks about pw-pulse <appname> to test but not how to replace the user's pulse socket - there's pipewire-pulse and a pipewire.socket/service user service in (the new) pipewire package, but the user service doesn't start pipewire-pulse (unless the exec is commented out in the config maybe?)
I ended up manually removing the socket at /run/user/<uid>/pulse/native, starting pipewire-pulse manually and killing the old pulseaudio instance but I'm sure there's a better way?
I've messed around with (very casual) things and everything appears to work, with pipewire-pulse spewing some warnings when I tried pavucontrol ---- [W][001555077.904969][pulse-server.c:411 reply_error()] pulse-server 0x56434a66a640: [PulseAudio Volume Control] ERROR command:87 (EXTENSION) tag:17 error:19 (Operation not supported) ---- and errors when a client disconnect ---- [E][001555597.840471][core.c:71 core_event_error()] core 0x56434a67f520: proxy 0x56434a67f520 id:0: bound:-1 seq:667 res:-22 (Invalid argument) msg:"unknown resource 40 op:3" ----
both are probably harmless, and that aside everything looks great; I think making things easier to test (or clarifying the procedure) for fedora 33 would help reassuring people about it.
Haven't tested the jack side of things as I don't use it normally.
On 11/20/20 1:28 PM, Dominique Martinet wrote:
Ben Cotton wrote on Fri, Nov 20, 2020:
== How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package).
Took me some time to figure out how to test:
[Snip]
Me too.
I think for current F33 / Rawhide you're expected to create some symlinks manually: https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165
On Fri, 20 Nov 2020 at 19:47, Brandon Nielsen nielsenb@jetfuse.net wrote:
On 11/20/20 1:28 PM, Dominique Martinet wrote:
Ben Cotton wrote on Fri, Nov 20, 2020:
l the pipewire-pulse library (which
removes the pulseaudio package).
Took me some time to figure out how to test:
[Snip]
Me too.
I think for current F33 / Rawhide you're expected to create some symlinks manually: https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165
I don't think this is the the correct way any longer. Lib-Pulse was AFAIK the initially planned drop-in replacement for pulseaudio. This has since been deprecated. Pipewire-Pulse AFAIK provides a separate pulseaudio server. I dont think it needs any linking, other than software activation.
It would be great however if the change request clarified what needs to be done - especially taking into account that very recent online instructions now may be wrong.
On 11/20/20 4:31 PM, Naheem Zaffar wrote:
On Fri, 20 Nov 2020 at 19:47, Brandon Nielsen <nielsenb@jetfuse.net mailto:nielsenb@jetfuse.net> wrote:
On 11/20/20 1:28 PM, Dominique Martinet wrote: > Ben Cotton wrote on Fri, Nov 20, 2020: l the pipewire-pulse library (which >> removes the pulseaudio package). > > Took me some time to figure out how to test: [Snip] Me too. I think for current F33 / Rawhide you're expected to create some symlinks manually: https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165 <https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165>I don't think this is the the correct way any longer. Lib-Pulse was AFAIK the initially planned drop-in replacement for pulseaudio. This has since been deprecated. Pipewire-Pulse AFAIK provides a separate pulseaudio server. I dont think it needs any linking, other than software activation.
It would be great however if the change request clarified what needs to be done - especially taking into account that very recent online instructions now may be wrong.
If it has changed, it would be really great if pipewire-pulse could make it into the F33 repos so it could be easily tested.
On Fri, 20 Nov 2020 18:35:19 -0600 Brandon Nielsen nielsenb@jetfuse.net wrote:
If it has changed, it would be really great if pipewire-pulse could make it into the F33 repos so it could be easily tested.
I agree. I think new software should be available and testable on a stable Fedora release before it becomes default. I’m not ready to have a rawhide install on real hardware to test something that’s not ready yet. I am especially wary of a change that requires new software to be written between now and beta.
Remember, there was great anger and frustration when pulseaudio became the default before it was ready (IMHO). It has improved a lot since then. Please learn from them and make it easy for volunteers to test this with real use before breaking everyone’s sound. I have a few things I want to try beyond what is in the how-to-test section.
Please provide simple instructions on how to test for F33/32 or defer the change until F35. Overall, pipewire sounds very promising; I just want to be sure it is ready.
Jim
Den lör 21 nov. 2020 kl 15:31 skrev James Szinger jszinger@gmail.com:
On Fri, 20 Nov 2020 18:35:19 -0600 Brandon Nielsen nielsenb@jetfuse.net wrote:
If it has changed, it would be really great if pipewire-pulse could make it into the F33 repos so it could be easily tested.
I agree. I think new software should be available and testable on a stable Fedora release before it becomes default. I’m not ready to have a rawhide install on real hardware to test something that’s not ready yet. I am especially wary of a change that requires new software to be written between now and beta.
I think this is a way too high burden on new features. Testing in rawhide should be enough. Something like pipewire is also pretty easy to test in a Live system.
Best regards Andreas
Remember, there was great anger and frustration when pulseaudio became the default before it was ready (IMHO). It has improved a lot since then. Please learn from them and make it easy for volunteers to test this with real use before breaking everyone’s sound. I have a few things I want to try beyond what is in the how-to-test section.
Please provide simple instructions on how to test for F33/32 or defer the change until F35. Overall, pipewire sounds very promising; I just want to be sure it is ready.
Jim _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 11/23/20 10:30 AM, Andreas Tunek wrote:
Den lör 21 nov. 2020 kl 15:31 skrev James Szinger <jszinger@gmail.com mailto:jszinger@gmail.com>:
On Fri, 20 Nov 2020 18:35:19 -0600 Brandon Nielsen <nielsenb@jetfuse.net <mailto:nielsenb@jetfuse.net>> wrote: > If it has changed, it would be really great if pipewire-pulse could > make it into the F33 repos so it could be easily tested. I agree. I think new software should be available and testable on a stable Fedora release before it becomes default. I’m not ready to have a rawhide install on real hardware to test something that’s not ready yet. I am especially wary of a change that requires new software to be written between now and beta.I think this is a way too high burden on new features. Testing in rawhide should be enough. Something like pipewire is also pretty easy to test in a Live system.
[Snip]
Easy to test basic things like sound works, headphones work, output device changing works. Much more difficult to test every audio use-case I use in a given day, week, month, because needs and uses change so much. Am I using my Bluetooth headphones today? A USB audio interface? Webcam? HDMI? Plus I work across different systems with almost entirely different hardware. I may be willing to run Rawhide on some of these systems, but most people probably won't.
I'm not saying this should necessarily be a mandate. But for something completely fundamental to how a lot of people use their systems, especially now, with such a wide array of hardware and uses, we should absolutely be pursuing the widest possible test coverage. And right now, the only answers are "it works in rawhide" and "it will be feature complete later".
On Mon, Nov 23, 2020 at 10:44:05AM -0600, Brandon Nielsen wrote:
On 11/23/20 10:30 AM, Andreas Tunek wrote:
Den lör 21 nov. 2020 kl 15:31 skrev James Szinger <jszinger@gmail.com mailto:jszinger@gmail.com>:
On Fri, 20 Nov 2020 18:35:19 -0600 Brandon Nielsen <nielsenb@jetfuse.net <mailto:nielsenb@jetfuse.net>> wrote: > If it has changed, it would be really great if pipewire-pulse could > make it into the F33 repos so it could be easily tested. I agree. I think new software should be available and testable on a stable Fedora release before it becomes default. I’m not ready to have a rawhide install on real hardware to test something that’s not ready yet. I am especially wary of a change that requires new software to be written between now and beta.I think this is a way too high burden on new features. Testing in rawhide should be enough. Something like pipewire is also pretty easy to test in a Live system.
[Snip]
Easy to test basic things like sound works, headphones work, output device changing works. Much more difficult to test every audio use-case I use in a given day, week, month, because needs and uses change so much. Am I using my Bluetooth headphones today? A USB audio interface? Webcam? HDMI? Plus I work across different systems with almost entirely different hardware. I may be willing to run Rawhide on some of these systems, but most people probably won't.
I'm not saying this should necessarily be a mandate. But for something completely fundamental to how a lot of people use their systems, especially now, with such a wide array of hardware and uses, we should absolutely be pursuing the widest possible test coverage. And right now, the only answers are "it works in rawhide" and "it will be feature complete later".
Please do note that this week has US holidays in it and change owners may be off away from computers taking time off. I don't think we should be impatient on this... let them get a chance to respond rather than everyone saying over and over they don't think it's ready and it's not testable yet.
Additionally, since it's a big change with a wide amount of workflows and hardware and users expected, thats another reason to accept the change for f34. It will then get testing up until the beta freeze... if it's not ready then, it can be moved to f35 all the better for all the testing it got in the early f34 cycle.
So, IMHO, relax, wait for change owners to make things testable, then test and file bugs and we can see where we are. There's too many unknowns right at this minute.
kevin
On Tue, Nov 24, 2020 at 01:33:57PM -0800, Kevin Fenzi wrote:
So, IMHO, relax, wait for change owners to make things testable, then test and file bugs and we can see where we are. There's too many unknowns right at this minute.
So...you're saying that we should evaluate proposed changes, not as they are currently written, but as they might be written at some unspcecified later date.
(Which, oddly enough, is the same problem us naysayers have with the actual change request...)
- Solomon
On Tue, Nov 24, 2020 at 05:27:31PM -0500, Solomon Peachy wrote:
On Tue, Nov 24, 2020 at 01:33:57PM -0800, Kevin Fenzi wrote:
So, IMHO, relax, wait for change owners to make things testable, then test and file bugs and we can see where we are. There's too many unknowns right at this minute.
So...you're saying that we should evaluate proposed changes, not as they are currently written, but as they might be written at some unspcecified later date.
no.
I am saying you should not look at a change and evaluate it like it's landing in stable as soon as it's approved. There will be testing. There will be bugs. If those bugs are serious enough there will be reverting and trying again later.
It's a 'Hey folks, we are going to try and do this, what do you think about the approach' ? It sounds to me like everyone is fine with the general idea, they just want lots of testing. Thats great. I would definitely hope the change owners would also want that. I am pretty sure however they thought things could be stablized by f34 or they wouldn't have submitted it for f34.
Anyhow, lets wait for the change owners to chime in and adjust their change from the feedback so far.
kevin
On 24.11.2020 22:33, Kevin Fenzi wrote:
Additionally, since it's a big change with a wide amount of workflows and hardware and users expected, thats another reason to accept the change for f34. It will then get testing up until the beta freeze... if it's not ready then, it can be moved to f35 all the better for all the testing it got in the early f34 cycle.
Yes-yes. Remember about the completely broken GCC 10 snapshot in Fedora 32 with a lot of internal regressions. We shouldn't break the working audio configuration for end users.
On Mon, 23 Nov 2020 17:30:51 +0100 Andreas Tunek andreas.tunek@gmail.com wrote:
Den lör 21 nov. 2020 kl 15:31 skrev James Szinger jszinger@gmail.com:
On Fri, 20 Nov 2020 18:35:19 -0600 Brandon Nielsen nielsenb@jetfuse.net wrote:
If it has changed, it would be really great if pipewire-pulse could make it into the F33 repos so it could be easily tested.
I agree. I think new software should be available and testable on a stable Fedora release before it becomes default. I’m not ready to have a rawhide install on real hardware to test something that’s not ready yet. I am especially wary of a change that requires new software to be written between now and beta.
I think this is a way too high burden on new features. Testing in rawhide should be enough. Something like pipewire is also pretty easy to test in a Live system.
There is difference between having a feature available and making it the default.
I fully support have pipewire replacing pulseaudio as an optional feature. I am opposed to making it the default without adequate testing. I am not even proposing a 'no regression' rule. I am just asking for extensive testing and real-world use, so that an informed decision can be made about the defaults. The proposed testing is not enough.
Jim
Am 20.11.20 um 23:31 schrieb Naheem Zaffar:
I don't think this is the the correct way any longer. Lib-Pulse was AFAIK the initially planned drop-in replacement for pulseaudio. This has since been deprecated. Pipewire-Pulse AFAIK provides a separate pulseaudio server. I dont think it needs any linking, other than software activation.
It would be great however if the change request clarified what needs to be done - especially taking into account that very recent online instructions now may be wrong.
What will be the impakt of the switch to pipewire?
Do people like me need to rewrite theire entire multiroom home audiosystem (now based on pulseaudio) to make it work with pipewire?
best regards, marius
On 2020-11-20 2:31 p.m., Naheem Zaffar wrote:
On Fri, 20 Nov 2020 at 19:47, Brandon Nielsen <nielsenb@jetfuse.net mailto:nielsenb@jetfuse.net> wrote:
On 11/20/20 1:28 PM, Dominique Martinet wrote: > Ben Cotton wrote on Fri, Nov 20, 2020: l the pipewire-pulse library (which >> removes the pulseaudio package). > > Took me some time to figure out how to test: [Snip] Me too. I think for current F33 / Rawhide you're expected to create some symlinks manually: https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165 <https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165>I don't think this is the the correct way any longer. Lib-Pulse was AFAIK the initially planned drop-in replacement for pulseaudio. This has since been deprecated. Pipewire-Pulse AFAIK provides a separate pulseaudio server. I dont think it needs any linking, other than software activation.
Pipewire-pulse is not packaged yet. It will be great to get it available for Fedora 33 for testing purpose.
Il 20/11/20 20:28, Dominique Martinet ha scritto:
Ben Cotton wrote on Fri, Nov 20, 2020:
== How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package).
Took me some time to figure out how to test:
- there's no such package; there's a pipewire-libpulse that apparently
got integrated into pipewire-libs but doesn't replace pulseaudio unlike the comment above (in fc33's update-testing pipewire-0.3.16-1.fc33.x86_64)
I think the package name is wrong, it should be pipewire-pulseaudio. However, it seems it doesn't correctly replace pulseaudio:
# dnf install pipewire-pulseaudio --enablerepo=updates-testing Ultima verifica della scadenza dei metadati: 0:02:42 fa il dom 22 nov 2020, 09:50:29. Errore: Problema: problem with installed package pulseaudio-libs-glib2-13.99.2-1.fc33.x86_64 - package pipewire-pulseaudio-0.3.13-4.fc33.i686 conflicts with pulseaudio-libs-glib2 provided by pulseaudio-libs-glib2-13.99.2-1.fc33.x86_64 - conflicting requests - package pipewire-pulseaudio-0.3.15-2.fc33.i686 conflicts with pulseaudio-libs-glib2 provided by pulseaudio-libs-glib2-13.99.2-1.fc33.x86_64 - package pipewire-pulseaudio-0.3.13-4.fc33.x86_64 conflicts with pulseaudio-libs-glib2 provided by pulseaudio-libs-glib2-13.99.2-1.fc33.x86_64 - package pipewire-pulseaudio-0.3.15-2.fc33.x86_64 conflicts with pulseaudio-libs-glib2 provided by pulseaudio-libs-glib2-13.99.2-1.fc33.x86_64 - problem with installed package pulseaudio-13.99.2-1.fc33.x86_64 - package pipewire-pulseaudio-0.3.16-2.fc33.x86_64 conflicts with pulseaudio provided by pulseaudio-13.99.2-1.fc33.x86_64
On 22.11.2020 10:05, Mattia Verga via devel wrote:
I think the package name is wrong, it should be pipewire-pulseaudio. However, it seems it doesn't correctly replace pulseaudio:
# dnf install pipewire-pulseaudio --enablerepo=updates-testing
This is absolutely fine. You should use dnf swap instead:
dnf swap pulseaudio pipewire-pulseaudio --allowerasing
Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020:
On 22.11.2020 10:05, Mattia Verga via devel wrote:
I think the package name is wrong, it should be pipewire-pulseaudio. However, it seems it doesn't correctly replace pulseaudio:
# dnf install pipewire-pulseaudio --enablerepo=updates-testing
This is absolutely fine. You should use dnf swap instead:
dnf swap pulseaudio pipewire-pulseaudio --allowerasing
That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) Perhaps a missing provide?
On 22.11.2020 12:36, Dominique Martinet wrote:
That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) Perhaps a missing provide?
Some packages directly depends on the pulseaudio package instead of the required libraries:
$ dnf -C repoquery --whatrequires=pulseaudio Cadence-0:1.0.0-0.12.20200504git5787908.fc33.x86_64 alsa-plugins-pulseaudio-0:1.2.2-3.fc33.i686 alsa-plugins-pulseaudio-0:1.2.2-3.fc33.x86_64 fluxbox-pulseaudio-0:1.3.7-12.fc32.noarch kde-settings-pulseaudio-0:33.0-2.fc33.noarch plasma-pa-0:5.19.5-1.fc33.i686 plasma-pa-0:5.19.5-1.fc33.x86_64 plasma-pa-0:5.20.3-1.fc33.i686 plasma-pa-0:5.20.3-1.fc33.x86_64 pulseaudio-esound-compat-0:13.99.2-1.fc33.x86_64 pulseaudio-module-bluetooth-0:13.99.2-1.fc33.x86_64 pulseaudio-module-bluetooth-freeworld-0:1.4-3.fc33.x86_64 pulseaudio-module-gconf-0:13.99.2-1.fc33.x86_64 pulseaudio-module-gsettings-0:13.99.2-1.fc33.x86_64 pulseaudio-module-jack-0:13.99.2-1.fc33.x86_64 pulseaudio-module-lirc-0:13.99.2-1.fc33.x86_64 pulseaudio-module-x11-0:13.99.2-1.fc33.x86_64 pulseaudio-module-zeroconf-0:13.99.2-1.fc33.x86_64 pulseaudio-qpaeq-0:13.99.2-1.fc33.x86_64 xfce4-pulseaudio-plugin-0:0.4.3-3.fc33.x86_64 xpra-0:4.0.4-1.fc33.x86_64
Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020:
On 22.11.2020 12:36, Dominique Martinet wrote:
That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) Perhaps a missing provide?
Some packages directly depends on the pulseaudio package instead of the required libraries:
That's not gnome-shell's case.
$ rpm -q --requires gnome-shell | grep pulse libpulse-mainloop-glib.so.0()(64bit) libpulse-mainloop-glib.so.0(PULSE_0)(64bit) libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit)
$ dnf -C repoquery --whatprovides 'libpulse.so.0(PULSE_0)(64bit)' Last metadata expiration check: 0:09:40 ago on Sun 22 Nov 2020 12:51:10 CET. pulseaudio-libs-0:13.99.2-1.fc33.x86_64 $ dnf -C repoquery --whatprovides 'libpulse-mainloop-glib.so.0(PULSE_0)(64bit)' Last metadata expiration check: 0:09:53 ago on Sun 22 Nov 2020 12:51:10 CET. pulseaudio-libs-glib2-0:13.99.2-1.fc33.x86_64
or, put the other way around: $ dnf -C repoquery --provides pulseaudio-libs Last metadata expiration check: 0:10:47 ago on Sun 22 Nov 2020 12:51:10 CET. config(pulseaudio-libs) = 13.99.2-1.fc33 libpulse-simple.so.0 libpulse-simple.so.0()(64bit) libpulse-simple.so.0(PULSE_0) libpulse-simple.so.0(PULSE_0)(64bit) libpulse.so.0 libpulse.so.0()(64bit) libpulse.so.0(PULSE_0) libpulse.so.0(PULSE_0)(64bit) libpulsecommon-13.99.so libpulsecommon-13.99.so()(64bit) libpulsedsp.so libpulsedsp.so()(64bit) pulseaudio-libs = 13.99.2-1.fc33 pulseaudio-libs(x86-32) = 13.99.2-1.fc33 pulseaudio-libs(x86-64) = 13.99.2-1.fc33
$ dnf -C repoquery --provides pipewire-pulseaudio Last metadata expiration check: 0:11:16 ago on Sun 22 Nov 2020 12:51:10 CET. pipewire-pulseaudio = 0.3.13-4.fc33 pipewire-pulseaudio = 0.3.15-2.fc33 pipewire-pulseaudio = 0.3.16-2.fc33 pipewire-pulseaudio(x86-32) = 0.3.13-4.fc33 pipewire-pulseaudio(x86-32) = 0.3.15-2.fc33 pipewire-pulseaudio(x86-64) = 0.3.13-4.fc33 pipewire-pulseaudio(x86-64) = 0.3.15-2.fc33 pipewire-pulseaudio(x86-64) = 0.3.16-2.fc33 pulseaudio-libs pulseaudio-libs-glib2
apparently providing pulseaudio-libs / pulseaudio-libs-glib2 does not transitively mean they provide libpulse.so/libpulse-mainloop-glib.so ?
Or is the thing just broken atm? I just downloaded the latest and it only contains the server side part (systemd user service/socket for pipewire-pulse): $ rpm -qpl pipewire-pulseaudio-0.3.16-2.fc33.x86_64.rpm /usr/lib/systemd/user/pipewire-pulse.service /usr/lib/systemd/user/pipewire-pulse.socket
Yet tries to provide the client (pulseaudio-libs*).. that's just wrong?!
(unrelated: I'm getting pavucontrol segfaults with pipewire-pulse server, just opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1900339 )
How did you get past the issue of gnome-shell depending on pulseaudio? It's a bit disconcerting that the change proposal's guide on testing pipewire doesn't currently work.
Dne 22. 11. 20 v 13:07 Dominique Martinet napsal(a):
Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020:
On 22.11.2020 12:36, Dominique Martinet wrote:
That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) Perhaps a missing provide?
Some packages directly depends on the pulseaudio package instead of the required libraries:
That's not gnome-shell's case.
$ rpm -q --requires gnome-shell | grep pulse libpulse-mainloop-glib.so.0()(64bit) libpulse-mainloop-glib.so.0(PULSE_0)(64bit) libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit)
$ dnf -C repoquery --whatprovides 'libpulse.so.0(PULSE_0)(64bit)' Last metadata expiration check: 0:09:40 ago on Sun 22 Nov 2020 12:51:10 CET. pulseaudio-libs-0:13.99.2-1.fc33.x86_64 $ dnf -C repoquery --whatprovides 'libpulse-mainloop-glib.so.0(PULSE_0)(64bit)' Last metadata expiration check: 0:09:53 ago on Sun 22 Nov 2020 12:51:10 CET. pulseaudio-libs-glib2-0:13.99.2-1.fc33.x86_64
or, put the other way around: $ dnf -C repoquery --provides pulseaudio-libs Last metadata expiration check: 0:10:47 ago on Sun 22 Nov 2020 12:51:10 CET. config(pulseaudio-libs) = 13.99.2-1.fc33 libpulse-simple.so.0 libpulse-simple.so.0()(64bit) libpulse-simple.so.0(PULSE_0) libpulse-simple.so.0(PULSE_0)(64bit) libpulse.so.0 libpulse.so.0()(64bit) libpulse.so.0(PULSE_0) libpulse.so.0(PULSE_0)(64bit) libpulsecommon-13.99.so libpulsecommon-13.99.so()(64bit) libpulsedsp.so libpulsedsp.so()(64bit) pulseaudio-libs = 13.99.2-1.fc33 pulseaudio-libs(x86-32) = 13.99.2-1.fc33 pulseaudio-libs(x86-64) = 13.99.2-1.fc33
$ dnf -C repoquery --provides pipewire-pulseaudio Last metadata expiration check: 0:11:16 ago on Sun 22 Nov 2020 12:51:10 CET. pipewire-pulseaudio = 0.3.13-4.fc33 pipewire-pulseaudio = 0.3.15-2.fc33 pipewire-pulseaudio = 0.3.16-2.fc33 pipewire-pulseaudio(x86-32) = 0.3.13-4.fc33 pipewire-pulseaudio(x86-32) = 0.3.15-2.fc33 pipewire-pulseaudio(x86-64) = 0.3.13-4.fc33 pipewire-pulseaudio(x86-64) = 0.3.15-2.fc33 pipewire-pulseaudio(x86-64) = 0.3.16-2.fc33 pulseaudio-libs pulseaudio-libs-glib2
apparently providing pulseaudio-libs / pulseaudio-libs-glib2 does not transitively mean they provide libpulse.so/libpulse-mainloop-glib.so ?
Or is the thing just broken atm? I just downloaded the latest and it only contains the server side part (systemd user service/socket for pipewire-pulse): $ rpm -qpl pipewire-pulseaudio-0.3.16-2.fc33.x86_64.rpm /usr/lib/systemd/user/pipewire-pulse.service /usr/lib/systemd/user/pipewire-pulse.socket
Yet tries to provide the client (pulseaudio-libs*).. that's just wrong?!
I think it would be simple enough if there was not the explicit conflict with pulse audio [1]. The instruction could be "Disable PA service and install PW".
Better solution would be if pulseaudio-module-bluetooth did not depend on pulseaudio.
Now is PW not installable unless doing some hacks :(
Vít
[1] https://src.fedoraproject.org/rpms/pipewire/blob/master/f/pipewire.spec#_193
(unrelated: I'm getting pavucontrol segfaults with pipewire-pulse server, just opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1900339 )
On 24.11.2020 15:15, Vít Ondruch wrote:
I think it would be simple enough if there was not the explicit conflict with pulse audio [1]. The instruction could be "Disable PA service and install PW".
Absolutely impossible. They provides libraries with the same name.
Dne 24. 11. 20 v 15:22 Vitaly Zaitsev via devel napsal(a):
On 24.11.2020 15:15, Vít Ondruch wrote:
I think it would be simple enough if there was not the explicit conflict with pulse audio [1]. The instruction could be "Disable PA service and install PW".
Absolutely impossible. They provides libraries with the same name.
It was already said in this thread previously:
~~~
$ sudo dnf repoquery -l pipewire-pulseaudio Last metadata expiration check: 0:34:19 ago on Tue Nov 24 14:55:40 2020. /usr/bin/pipewire-pulse /usr/lib/.build-id /usr/lib/.build-id/50 /usr/lib/.build-id/50/e366932de35c2ce639b0d4a768e368c5282b1a /usr/lib/systemd/user/pipewire-pulse.service /usr/lib/systemd/user/pipewire-pulse.socket ~~~
So I wonder what libraries are you referring to?
I think that these services would compete for the same socket, but they don't conflict IMO.
Vít
On 24.11.2020 15:31, Vít Ondruch wrote:
So I wonder what libraries are you referring to?
libpulse.so*, but they we remove from the spec by this[1] commit.
[1]: https://src.fedoraproject.org/rpms/pipewire/c/306d51984ef5faf4ea455e6d385f0f...
Dne 24. 11. 20 v 15:15 Vít Ondruch napsal(a):
Dne 22. 11. 20 v 13:07 Dominique Martinet napsal(a):
Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020:
On 22.11.2020 12:36, Dominique Martinet wrote:
That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) Perhaps a missing provide?
Some packages directly depends on the pulseaudio package instead of the required libraries:
That's not gnome-shell's case.
$ rpm -q --requires gnome-shell | grep pulse libpulse-mainloop-glib.so.0()(64bit) libpulse-mainloop-glib.so.0(PULSE_0)(64bit) libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit)
$ dnf -C repoquery --whatprovides 'libpulse.so.0(PULSE_0)(64bit)' Last metadata expiration check: 0:09:40 ago on Sun 22 Nov 2020 12:51:10 CET. pulseaudio-libs-0:13.99.2-1.fc33.x86_64 $ dnf -C repoquery --whatprovides 'libpulse-mainloop-glib.so.0(PULSE_0)(64bit)' Last metadata expiration check: 0:09:53 ago on Sun 22 Nov 2020 12:51:10 CET. pulseaudio-libs-glib2-0:13.99.2-1.fc33.x86_64
or, put the other way around: $ dnf -C repoquery --provides pulseaudio-libs Last metadata expiration check: 0:10:47 ago on Sun 22 Nov 2020 12:51:10 CET. config(pulseaudio-libs) = 13.99.2-1.fc33 libpulse-simple.so.0 libpulse-simple.so.0()(64bit) libpulse-simple.so.0(PULSE_0) libpulse-simple.so.0(PULSE_0)(64bit) libpulse.so.0 libpulse.so.0()(64bit) libpulse.so.0(PULSE_0) libpulse.so.0(PULSE_0)(64bit) libpulsecommon-13.99.so libpulsecommon-13.99.so()(64bit) libpulsedsp.so libpulsedsp.so()(64bit) pulseaudio-libs = 13.99.2-1.fc33 pulseaudio-libs(x86-32) = 13.99.2-1.fc33 pulseaudio-libs(x86-64) = 13.99.2-1.fc33
$ dnf -C repoquery --provides pipewire-pulseaudio Last metadata expiration check: 0:11:16 ago on Sun 22 Nov 2020 12:51:10 CET. pipewire-pulseaudio = 0.3.13-4.fc33 pipewire-pulseaudio = 0.3.15-2.fc33 pipewire-pulseaudio = 0.3.16-2.fc33 pipewire-pulseaudio(x86-32) = 0.3.13-4.fc33 pipewire-pulseaudio(x86-32) = 0.3.15-2.fc33 pipewire-pulseaudio(x86-64) = 0.3.13-4.fc33 pipewire-pulseaudio(x86-64) = 0.3.15-2.fc33 pipewire-pulseaudio(x86-64) = 0.3.16-2.fc33 pulseaudio-libs pulseaudio-libs-glib2
apparently providing pulseaudio-libs / pulseaudio-libs-glib2 does not transitively mean they provide libpulse.so/libpulse-mainloop-glib.so ?
Or is the thing just broken atm? I just downloaded the latest and it only contains the server side part (systemd user service/socket for pipewire-pulse): $ rpm -qpl pipewire-pulseaudio-0.3.16-2.fc33.x86_64.rpm /usr/lib/systemd/user/pipewire-pulse.service /usr/lib/systemd/user/pipewire-pulse.socket
Yet tries to provide the client (pulseaudio-libs*).. that's just wrong?!
I think it would be simple enough if there was not the explicit conflict with pulse audio [1]. The instruction could be "Disable PA service and install PW".
Better solution would be if pulseaudio-module-bluetooth did not depend on pulseaudio.
Just FTR, this is the situation on Rawhide:
~~~
$ sudo dnf swap pulseaudio pipewire-pulseaudio Last metadata expiration check: 0:03:54 ago on Mon Nov 23 23:14:58 2020. Error: Problem 1: problem with installed package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires libprotocol-native.so()(64bit), but none of the providers can be installed - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires libpulsecore-13.99.so()(64bit), but none of the providers can be installed - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be installed - conflicting requests Problem 2: problem with installed package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires libpulsecore-13.99.so()(64bit), but none of the providers can be installed - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be installed - package pipewire-pulseaudio-0.3.16-3.fc34.x86_64 conflicts with pulseaudio provided by pulseaudio-13.99.3-1.fc34.x86_64 - conflicting requests (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
$ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing
Last metadata expiration check: 0:04:54 ago on Mon Nov 23 23:14:58 2020. Error: Problem: The operation would result in removing the following protected packages: gnome-shell (try to add '--skip-broken' to skip uninstallable packages)
$ sudo dnf remove pulseaudio-module-x11 Dependencies resolved. =================================================================================================================================================================================================================== Package Architecture Version Repository Size =================================================================================================================================================================================================================== Removing: pulseaudio-module-x11 x86_64 13.99.3-1.fc34 @rawhide 78 k
Transaction Summary =================================================================================================================================================================================================================== Remove 1 Package
Freed space: 78 k Is this ok [y/N]: ^COperation aborted.
$ sudo dnf remove pulseaudio-module-bluetooth
Error: Problem: The operation would result in removing the following protected packages: gnome-shell (try to add '--skip-broken' to skip uninstallable packages)
~~~
Now is PW not installable unless doing some hacks :(
Vít
[1] https://src.fedoraproject.org/rpms/pipewire/blob/master/f/pipewire.spec#_193
(unrelated: I'm getting pavucontrol segfaults with pipewire-pulse server, just opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1900339 )
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Dne 24. 11. 20 v 15:15 Vít Ondruch napsal(a):
Just FTR, this is the situation on Rawhide:
$ sudo dnf swap pulseaudio pipewire-pulseaudio Last metadata expiration check: 0:03:54 ago on Mon Nov 23 23:14:58 2020. Error: Problem 1: problem with installed package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires libprotocol-native.so()(64bit), but none of the providers can be installed - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires libpulsecore-13.99.so()(64bit), but none of the providers can be installed - package pulseaudio-module-x11-13.99.3-1.fc34.x86_64 requires pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be installed - conflicting requests Problem 2: problem with installed package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires libpulsecore-13.99.so()(64bit), but none of the providers can be installed - package pulseaudio-module-bluetooth-13.99.3-1.fc34.x86_64 requires pulseaudio(x86-64) = 13.99.3-1.fc34, but none of the providers can be installed - package pipewire-pulseaudio-0.3.16-3.fc34.x86_64 conflicts with pulseaudio provided by pulseaudio-13.99.3-1.fc34.x86_64 - conflicting requests (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) $ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing Last metadata expiration check: 0:04:54 ago on Mon Nov 23 23:14:58 2020. Error: Problem: The operation would result in removing the following protected packages: gnome-shell (try to add '--skip-broken' to skip uninstallable packages) $ sudo dnf remove pulseaudio-module-x11 Dependencies resolved. =================================================================================================================================================================================================================== Package Architecture Version Repository Size =================================================================================================================================================================================================================== Removing: pulseaudio-module-x11 x86_64 13.99.3-1.fc34 @rawhide 78 k Transaction Summary =================================================================================================================================================================================================================== Remove 1 Package Freed space: 78 k Is this ok [y/N]: ^COperation aborted. $ sudo dnf remove pulseaudio-module-bluetooth Error: Problem: The operation would result in removing the following protected packages: gnome-shell (try to add '--skip-broken' to skip uninstallable packages)
I've filed a bug report for this: https://bugzilla.redhat.com/show_bug.cgi?id=1900876
I think this definitely needs to be resolved quickly if this proposal is to go forward, otherwise the already small testing window will be even more narrow.
Em Sun, 22 Nov 2020 12:17:06 +0100 Vitaly Zaitsev via devel devel@lists.fedoraproject.org escreveu:
On 22.11.2020 10:05, Mattia Verga via devel wrote:
I think the package name is wrong, it should be pipewire-pulseaudio. However, it seems it doesn't correctly replace pulseaudio:
# dnf install pipewire-pulseaudio --enablerepo=updates-testing
This is absolutely fine. You should use dnf swap instead:
dnf swap pulseaudio pipewire-pulseaudio --allowerasing
Tried it today (tested using a COPR repo with pipewire-0.3.17, as with 0.3.15, it would try to remove a large number of packages which depends on PA).
There are still some packages being removed, probably due to wrong dependency chains:
# dnf swap pulseaudio pipewire-pulseaudio --allowerasing
Last metadata expiration check: 2:23:59 ago on Mon Dec 14 09:09:34 2020. Package pipewire-pulseaudio-0.3.17-3.fc33.x86_64 is already installed. Dependencies resolved. =================================================================================================================== Package Architecture Version Repository Size =================================================================================================================== Removing: pulseaudio x86_64 14.0-2.fc33 @updates 4.0 M Removing dependent packages: alsa-plugins-pulseaudio i686 1.2.2-3.fc33 @fedora 123 k alsa-plugins-pulseaudio x86_64 1.2.2-3.fc33 @fedora 121 k pulseaudio-module-bluetooth x86_64 14.0-2.fc33 @updates 231 k pulseaudio-module-gconf x86_64 14.0-2.fc33 @updates 40 k pulseaudio-module-gsettings x86_64 14.0-2.fc33 @updates 51 k pulseaudio-module-x11 x86_64 14.0-2.fc33 @updates 78 k pulseaudio-module-zeroconf x86_64 14.0-2.fc33 @updates 194 k pulseaudio-qpaeq x86_64 14.0-2.fc33 @updates 106 k steam i686 1.0.0.68-2.fc33 @rpmfusion-nonfree-updates 2.9 M Removing unused dependencies: gamemode i686 1.6-1.fc33 @updates 248 k gamemode x86_64 1.6-1.fc33 @updates 276 k gnome-shell-extension-gamemode noarch 1-4.fc33 @fedora 46 k inih i686 49-2.fc33 @fedora 25 k inih x86_64 49-2.fc33 @fedora 25 k libatomic i686 10.2.1-9.fc33 @updates 32 k libdbusmenu-gtk3 i686 16.04.0-16.fc33 @fedora 96 k libnsl i686 2.32-2.fc33 @updates 160 k libpng12 i686 1.2.57-12.fc33 @fedora 450 k mpg123-plugins-pulseaudio x86_64 1.26.2-2.fc33 @fedora 16 k
Transaction Summary =================================================================================================================== Remove 20 Packages
Also, PipeWire is not working fine with Mate Desktop volume control via media keys (XF86AudioLowerVolume, XF86AudioRiseVolume, XF86AudioMuteVolume). I opened a BZ for such issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1907617
-
I ran a few quick tests using both PA and Jack apps.
I didn't notice any major issue on my tests so far. Regards, Mauro
On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab mchehab@infradead.org wrote:
# dnf swap pulseaudio pipewire-pulseaudio --allowerasing
I needed to add --enablerepo=updates-testing
Also, you may need to (as yourself) perform a
$ systemctl --user enable pipewire pipewire-pulse
In limited testing it seems to work for my use cases.
Gary Buhrmaster wrote on Mon, Dec 14, 2020:
On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab mchehab@infradead.org wrote:
# dnf swap pulseaudio pipewire-pulseaudio --allowerasing
I needed to add --enablerepo=updates-testing
With updates-testing enabled here, it's much better than last month (no more gdm being removed), but there still are a few pulseaudio direct dependencies: # dnf swap pulseaudio pipewire-pulseaudio --allowerasing Last metadata expiration check: 0:10:19 ago on Tue 15 Dec 2020 07:52:26 CET. Dependencies resolved. ============================================================================== Package Arch Version Repository Size ============================================================================== Installing: pipewire-pulseaudio x86_64 0.3.17-3.fc33 updates-testing 14 k Upgrading: pipewire x86_64 0.3.17-3.fc33 updates-testing 118 k pipewire-gstreamer x86_64 0.3.17-3.fc33 updates-testing 52 k pipewire-libs x86_64 0.3.17-3.fc33 updates-testing 922 k Removing: pulseaudio x86_64 14.0-2.fc33 @updates-testing 4.0 M Removing dependent packages: alsa-plugins-pulseaudio x86_64 1.2.2-3.fc33 @fedora 121 k pulseaudio-module-bluetooth x86_64 14.0-2.fc33 @updates-testing 231 k pulseaudio-module-x11 x86_64 14.0-2.fc33 @updates-testing 78 k xfce4-pulseaudio-plugin x86_64 0.4.3-3.fc33 @fedora 447 k
In particular I'm worried alsa programs will stop working. Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's pulseaudio implementation? (I see there's also an alsa-plugins-jack, I guess that might work but I don't have it installed right now; or some new alsa-plugins-pipewire should be pulled in at least to keep things working one way or another)
Hi,
In particular I'm worried alsa programs will stop working.
There is a pipewire-alsa package to support alsa programs
Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's pulseaudio implementation?
It is but then you go through an extra layer of emulation, it's better to remove the pulseaudio one and use the pipewire one if you remove the pulseaudio daemon.
(I see there's also an alsa-plugins-jack, I guess that might work but I don't have it installed right now;
This should also work but again using an extra layer of emulation.
or some new alsa-plugins-pipewire should be pulled in at least to keep things working one way or another)
Yes, it should somehow be pulled in, how should that be done? A Suggests: for pipewire-pulse maybe?
Wim
On Tue, Dec 15, 2020 at 8:09 AM Dominique Martinet asmadeus@codewreck.org wrote:
Gary Buhrmaster wrote on Mon, Dec 14, 2020:
On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab mchehab@infradead.org wrote:
# dnf swap pulseaudio pipewire-pulseaudio --allowerasing
I needed to add --enablerepo=updates-testing
With updates-testing enabled here, it's much better than last month (no more gdm being removed), but there still are a few pulseaudio direct dependencies: # dnf swap pulseaudio pipewire-pulseaudio --allowerasing Last metadata expiration check: 0:10:19 ago on Tue 15 Dec 2020 07:52:26 CET. Dependencies resolved.
============================================================================== Package Arch Version Repository Size
============================================================================== Installing: pipewire-pulseaudio x86_64 0.3.17-3.fc33 updates-testing 14 k Upgrading: pipewire x86_64 0.3.17-3.fc33 updates-testing 118 k pipewire-gstreamer x86_64 0.3.17-3.fc33 updates-testing 52 k pipewire-libs x86_64 0.3.17-3.fc33 updates-testing 922 k Removing: pulseaudio x86_64 14.0-2.fc33 @updates-testing 4.0 M Removing dependent packages: alsa-plugins-pulseaudio x86_64 1.2.2-3.fc33 @fedora 121 k pulseaudio-module-bluetooth x86_64 14.0-2.fc33 @updates-testing 231 k pulseaudio-module-x11 x86_64 14.0-2.fc33 @updates-testing 78 k xfce4-pulseaudio-plugin x86_64 0.4.3-3.fc33 @fedora 447 k
In particular I'm worried alsa programs will stop working. Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's pulseaudio implementation? (I see there's also an alsa-plugins-jack, I guess that might work but I don't have it installed right now; or some new alsa-plugins-pipewire should be pulled in at least to keep things working one way or another)
-- Dominique _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Wim Taymans wrote on Tue, Dec 15, 2020:
In particular I'm worried alsa programs will stop working.
There is a pipewire-alsa package to support alsa programs
Aha! I had missed it, thanks.
Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's pulseaudio implementation?
It is but then you go through an extra layer of emulation, it's better to remove the pulseaudio one and use the pipewire one if you remove the pulseaudio daemon.
Definitely, I agree pipewire-alsa suffices and is better (although I'm not sure alsa-plugins-pulseaudio should have unfullfilled dependncies from pipewire-pulseaudio, it's probably saner to have it autoremoved by default to avoid multiple interfaces to the same service)
or some new alsa-plugins-pipewire should be pulled in at least to keep things working one way or another)
Yes, it should somehow be pulled in, how should that be done? A Suggests: for pipewire-pulse maybe?
I'm not too familiar on this, but a recommends (rather than suggests which will likely be ignored by dnf afaiu) on pipewire-pulseaudio sounds good despite being not directly related to pulseaudio.
I'm honestly not sure what would be best, but pulling it without the pipewire service enable sounds more harmful than good... pipewire-pulseaudio sounds like a good reinsurance that pipewire will likely be running.
Note: I've now switched packages and also had to enable/start the service: systemctl --user enable --now pipewire-pulse.socket
I would suggest installing a preset file that would tell systemd to enable it by default if possible?
It looks like pipewire.socket has one from /usr/lib/systemd/user-preset/90-default-user.preset (in fedora-release-common-33-2.noarch) which wasn't obvious to find, I didn't check if fedora34 also enables pipewire-pulse but if not it definitely should (or pipewire should ship its own presets)
Thanks,
Gary Buhrmaster wrote on Mon, Dec 14, 2020:
With updates-testing enabled here, it's much better than last month (no more gdm being removed), but there still are a few pulseaudio direct dependencies:
Steam from rpmfusion still conflicts with pipewire-pulseaudio as well. Until that conflict is resolved it is going to prevent a lot of people from being able to test pipewire since it will mean removing their ability to use steam and all of the games tied to it.
On 2020-12-15 10:52 a.m., Tom Seewald wrote:
Gary Buhrmaster wrote on Mon, Dec 14, 2020:
With updates-testing enabled here, it's much better than last month (no more gdm being removed), but there still are a few pulseaudio direct dependencies:
Steam from rpmfusion still conflicts with pipewire-pulseaudio as well. Until that conflict is resolved it is going to prevent a lot of people from being able to test pipewire since it will mean removing their ability to use steam and all of the games tied to it. ________________________
Resolved on steam 1.0.0.68-6
https://koji.rpmfusion.org/koji/packageinfo?packageID=413
Em Mon, 14 Dec 2020 23:04:23 +0000 Gary Buhrmaster gary.buhrmaster@gmail.com escreveu:
On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab mchehab@infradead.org wrote:
# dnf swap pulseaudio pipewire-pulseaudio --allowerasing
I needed to add --enablerepo=updates-testing
Also, you may need to (as yourself) perform a
$ systemctl --user enable pipewire pipewire-pulse
There are still broken dependecies when using with Jack protocol:
# dnf install pipewire-jack-audio-connection-kit --allowerasing --enablerepo=updates-testing Last metadata expiration check: 0:14:07 ago on Sat Dec 19 19:33:38 2020. Dependencies resolved. ============================================================================================================================================================================================== Package Architecture Version Repository Size ============================================================================================================================================================================================== Installing: pipewire-jack-audio-connection-kit x86_64 0.3.18-1.fc33 updates-testing 12 k Removing dependent packages: SDL_mixer x86_64 1.2.12-21.fc33 @fedora 201 k a2jmidid x86_64 9-4.fc33 @fedora 130 k amsynth x86_64 1.12.1-1.fc33 @updates 328 k anki noarch 2.1.15-3.fc33 @fedora 12 M ardour6 x86_64 6.3.0-1.fc33 @fedora 63 M ardour6-backend-alsa x86_64 6.3.0-1.fc33 @fedora 281 k ardour6-backend-dummy x86_64 6.3.0-1.fc33 @fedora 147 k ardour6-backend-jack x86_64 6.3.0-1.fc33 @fedora 184 k ardour6-backend-pulseaudio x86_64 6.3.0-1.fc33 @fedora 110 k arpage x86_64 0.3.3-30.fc33 @fedora 455 k aubio x86_64 0.4.9-7.fc33 @fedora 452 k audacity x86_64 2.3.3-7.fc33 @fedora 26 M avidemux x86_64 2.7.6-3.fc33 @rpmfusion-free 177 avidemux-libs x86_64 2.7.6-3.fc33 @rpmfusion-free 14 M avidemux-qt x86_64 2.7.6-3.fc33 @rpmfusion-free 4.3 M calf x86_64 0.90.3-7.fc33 @fedora 19 M denemo x86_64 2.4.0-2.fc33 @fedora 29 M dssi x86_64 1.1.1-20.fc33 @fedora 134 k ffmpeg x86_64 4.3.1-11.fc33 @rpmfusion-free 1.9 M ffmpeg-devel x86_64 4.3.1-11.fc33 @rpmfusion-free 8.7 M fluidsynth x86_64 2.1.1-4.fc33 @fedora 36 k fluidsynth-devel x86_64 2.1.1-4.fc33 @fedora 2.7 M fluidsynth-dssi x86_64 1.0.0-23.fc33 @fedora 119 k fluidsynth-libs x86_64 2.1.1-4.fc33 @fedora 464 k gpac-libs x86_64 1.0.1-1.fc33 @rpmfusion-free-updates 7.9 M gstreamer1-plugins-bad-free-fluidsynth x86_64 1.18.2-1.fc33 @updates 32 k gstreamer1-plugins-good-extras x86_64 1.18.2-1.fc33 @updates 64 k guitarix x86_64 0.40.0-5.fc33 @fedora 37 M jaaa x86_64 0.8.4-9.fc33 @fedora 94 k jack-audio-connection-kit x86_64 1.9.14-5.fc33 @fedora 1.9 M kdenlive x86_64 20.08.3-1.fc33 @rpmfusion-free-updates 62 M ladspa-calf-plugins x86_64 0.90.3-7.fc33 @fedora 23 lash x86_64 0.5.4-43.fc33 @fedora 455 k libavdevice x86_64 4.3.1-11.fc33 @rpmfusion-free 160 k lmms x86_64 1.1.3-19.fc33 @fedora 22 M mlt x86_64 6.22.1-1.fc33 @fedora 2.8 M mlt-freeworld x86_64 6.22.1-1.fc33 @rpmfusion-free 148 k mpg123-plugins-jack x86_64 1.26.2-2.fc33 @fedora 20 k mpg123-plugins-portaudio x86_64 1.26.2-2.fc33 @fedora 16 k mplayer x86_64 1.4-11.fc33 @rpmfusion-free 3.7 M mpv x86_64 0.33.0-1.fc33 @rpmfusion-free-updates 3.9 M mscore x86_64 3.5.2-4.fc33 @updates 76 M non-mixer x86_64 1.2.0-20.20200307gitbbe8386.fc33 @fedora 1.0 M non-sequencer x86_64 1.2.0-20.20200307gitbbe8386.fc33 @fedora 371 k non-session-manager x86_64 1.2.0-20.20200307gitbbe8386.fc33 @fedora 417 k portaudio x86_64 19-32.fc33 @fedora 259 k python3-pyaudio x86_64 0.2.11-9.fc33 @fedora 119 k python3-pygame x86_64 1.9.6-9.fc33 @fedora 8.2 M qjackctl x86_64 0.6.3-2.fc33 @updates 2.2 M qsynth x86_64 0.6.3-2.fc33 @updates 995 k rosegarden4 x86_64 20.06-1.fc33 @fedora 14 M slv2 x86_64 0.6.6-31.fc33 @fedora 160 k smplayer x86_64 20.6.0-3.fc33 @rpmfusion-free 15 M stk x86_64 4.5.0-16.fc33 @fedora 976 k timidity++ x86_64 2.14.0-21.fc33 @fedora 1.3 M timidity++-GTK-interface x86_64 2.14.0-21.fc33 @fedora 91 k tuxguitar x86_64 1.5.3-5.fc33 @fedora 11 M vkeybd x86_64 0.1.18d-20.fc33 @fedora 83 k vlc x86_64 1:3.0.12-0.2.fc33 @rpmfusion-free-updates 4.3 M x264 x86_64 0.160-2.20200702gitcde9a93.fc33 @rpmfusion-free 7.6 M
Transaction Summary ============================================================================================================================================================================================== Install 1 Package Remove 60 Packages
Total download size: 12 k Is this ok [y/N]:
And dnf swap doesn't work either:
# dnf swap pipewire-jack-audio-connection-kit --allowerasing --enablerepo=updates-testing usage: dnf swap [-c [config file]] [-q] [-v] [--version] [--installroot [path]] [--nodocs] [--noplugins] [--enableplugin [plugin]] [--disableplugin [plugin]] [--releasever RELEASEVER] [--setopt SETOPTS] [--skip-broken] [-h] [--allowerasing] [-b | --nobest] [-C] [-R [minutes]] [-d [debug level]] [--debugsolver] [--showduplicates] [-e ERRORLEVEL] [--obsoletes] [--rpmverbosity [debug level name]] [-y] [--assumeno] [--enablerepo [repo]] [--disablerepo [repo] | --repo [repo]] [--enable | --disable] [-x [package]] [--disableexcludes [repo]] [--repofrompath [repo,path]] [--noautoremove] [--nogpgcheck] [--color COLOR] [--refresh] [-4] [-6] [--destdir DESTDIR] [--downloadonly] [--comment COMMENT] [--bugfix] [--enhancement] [--newpackage] [--security] [--advisory ADVISORY] [--bz BUGZILLA] [--cve CVES] [--sec-severity {Critical,Important,Moderate,Low}] [--forcearch ARCH] remove_spec install_spec dnf swap: error: the following arguments are required: install_spec
Thanks, Mauro
On Fri, 20 Nov 2020 at 17:28, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
== Owner ==
- Name: [[User:Wtaymans| Wim Taymans]]
- Email: wim.taymans@gmail.com
== Detailed Description == Currently, all desktop audio is handled by the PulseAudio daemon. Applications make use of the PulseAudio client library to communicate with the PulseAudio daemon that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel (gnome-control-panel) both use the Pulseaudio client libraries to manage the volume and configuration of the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to the JACK server. This proposal will install a JACK client library replacement that talks directly to PipeWire. All existing PRO audio jack applications will then work on top of PipeWire.
For legacy ALSA clients, we will install an ALSA plugin that routes the audio directly to PipeWire.
With these 3 changes, all audio will be routed to PipeWire. There will then be no more need to install the PulseAudio and JACK daemons.
== Feedback == The owner of this proposal has been in context with both the PulseAudio and JACK maintainers and community. PipeWire is considered to be the successor of both projects.
== Benefit to Fedora == The end goal is to end up with one audio infrastructure for both Desktop and Pro audio use cases. This will end the fragmentation of the audio landscape.
Some of the benefits that PipeWire will bring:
PRO Audio features
PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use the JACK API and JACK daemon, which is hard to setup and integrates poorly with the rest of the system (and PulseAudio in particular).
With a replacement libjack library, PRO Audio application can run directly on PipeWire and integrate seamlessly with other ALSA and PulseAudio applications. This would bring Fedora closer to the experience of other operating systems.
Flexibility/Integration
PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph and the management into separate processes. This makes it possible to better integrate with the other system components or swap out the default policy for a highly customized one (such as for automotive or embedded). This is in contrast to PulseAudio, which has all logic embedded into the daemon with limited configuration options.
In the next phase we expect to greatly expand the user experience and configuration of the audio infrastructure with better integration throughout the system.
Performance
PipeWire was designed for high performance and low-latency, using
much of the same design as JACK. JACK application should run with comparable performance even in low-latency situations.
Security
PipeWire enforces per client security. Object visibility and the
actions on them can be configured independently per client. This makes it possible to enforce a security policy for sandboxed applications (Flatpak) such as denying access to certain audio capture devices or block them from interfering with other applications.
Maintainability
Both PulseAudio and JACK have very slow development cycles with few
new features. The more flexible and distributed nature of the design of PipeWire should encourage more new features and use-cases.
== Scope ==
- Proposal owners:
We would make a pipewire-pulse package that provides the same features as the pulseaudio (daemon) package. We would only provide a drop-in replacement daemon, the pulseaudio client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio package is removed and replaced by the pipewire-pulse implementation. In the same way, installing the pulseaudio package would remove the pipewire-pulse package, making it possible to switch between implementations. This will also allow for an easy rollback.
We also need to check and correct the dependencies of other packages. As of this writing, some packages do not state their dependencies correctly and get removed when pulseaudio is removed. We also need to check the JACK to make sure they still install with the replacement JACK client library.
The JACK client libraries will be installed in the same way, removing the old JACK client libraries.
- Other developers:
The distribution needs to default to the pipewire-pulse package instead of pulseaudio. JACK applications need to install the pipewire-libjack client library.
- Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
- Policies and guidelines:
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34
- avahi network discovery and audio routing. This is not enabled by
default but can be activated with paprefs. this includes TCP and RTP transport of audio.
- make devices available as UPNP media servers. Not enabled by
default, paprefs can be used.
- easy configuration of combining all sinks. Questionable feature but
possible via paprefs.
User scripts will still work but custom configurations of the pulseaudio daemon will not be used anymore.
Most of the JACK workflow of managing the JACK daemon is not going to be needed anymore as things will work out-of-the-box. As of this writing, these things are missing from the JACK implementation, we hope to implement them before fedora 34:
- latency reporting: useful to align streams
- freewheeling: used when rendering a project
- jackdbus: used by some tools to manage the graph
== How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package).
To test the JACK support, one needs to install pipewire-libjack, which removes the original JACK client and server.
After these changes, a restart is needed to make sure the new pipewire-pulse daemon is running.
Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
- gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch.
- pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
- firefox: check out a website with audio/video such as youtube and
verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111).
- rhythmbox: check if playback works as expected
- bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
- Regular system usage and performance should not change.
- JACK tools such as catia, carla should run and can be used to
inspect the graph.
== User Experience == In general, users should not be able to see any change when using PulseAudio applications.
The big change is when using JACK application:
- They will start without having to configure and start the daemon.
this includes the period size and sample rates.
- All devices will be visible in the graph with meaningful names. Devices
will be automatically slaved when needed without needing any configuration.
- bluetooth devices will be usable as well.
== Dependencies == Other packages might need to have their requirements fixed to work with the replacement packages but this is under our control.
== Contingency Plan ==
- Contingency mechanism: Keep existing pulseaudio and JACK client
libraries as defaults
- Contingency deadline: beta freeze
- Blocks release? No
- Blocks product? No
== Documentation == [https://pipewire.org%5D(PipeWire website) [https://www.youtube.com/watch?v=8LZt4loZu64&t=14s%5D(Video with Current status) [ https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md%5D... guide) [ https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md%5D(... to use/test)
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
For legacy ALSA clients, we will install an ALSA plugin that routes the audio directly to PipeWire.
Is ALSA still a valid use case? I thought ALSA support was phased out from most relevant software?
I'd say "no" to replacing pulseaudio daemon, but "yes" to giving it more polish and perhaps aiming for Fedora 35? PulseAudio itself is stable, but still breaks in edge cases (old games, WINE) so I'd give PipeWire more time.
On Sun, 22 Nov 2020 15:47:04 +0100 Andy Mender andymenderunix@gmail.com wrote:
Is ALSA still a valid use case? I thought ALSA support was phased out from most relevant software?
It is for me. I run some audio software that I do not want interrupted while it is running. So, I use pavucontrol to turn it off to pulse and make it available only to alsa. Then, I can directly configure, send commands to, and use the sound device, ignored by pulse. As near as I can tell, it is still available in audacity, as well.
alsa is going nowhere since it is the interface to the hardware that every other sound application depends on. It is mature so it should take very little maintenance to allow it to remain.
On 11/23/20 5:23 PM, stan via devel wrote:
On Sun, 22 Nov 2020 15:47:04 +0100 Andy Mender andymenderunix@gmail.com wrote:
Is ALSA still a valid use case? I thought ALSA support was phased out from most relevant software?
It is for me. I run some audio software that I do not want interrupted while it is running. So, I use pavucontrol to turn it off to pulse and make it available only to alsa. Then, I can directly configure, send commands to, and use the sound device, ignored by pulse. As near as I can tell, it is still available in audacity, as well.
My use case for pure alsa is video grabbing of VHS tapes. Sound is captured at alsa level, I do not want any pulseaudio in the middle.
Regards.
My reply got a lot longer than I originally planned to write.
TL;DR - Having the software working is just the tip of the iceberg. The other 9/10ths needs to be a concentrated effort on documentation and driving adoption of the new API and not relying on the compatibility layer. Otherwise it will be destined to become the next wayland (12 years on and I'm still having to make custom hacks/changes in my browser just to do screen sharing).
On 20/11/2020 16:26, Ben Cotton wrote:
This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
I think this is a great idea.
I am not an audiophile or a desktop developer (yet) and I have only had F33 on this system for a little over two weeks. However, I have been running Ubuntu full time since 2016 (and on/off for the last 20 years) - so I have experience with GNOME and pulseaudio as an "average user".
A lot of the comments against this idea seem to stem from the perspective of stability (or lack of it, to be more precise). That there is quite some way to go before its a replacement for pulseaudio. Which sounds like a fair argument except for one important fact...
pulseaudio is not perfect. Far from it!
I've lost count of the number of times my chosen input device changes between boots, or the volume control just stops working, or no matter how many times I quick and relaunch settings or logout/login the settings panel refuses to obey my selection.
Yes. You could argue that the fault lies with GNOME Settings, or any of the other applications that have shown problems in the past. However, if an API makes it that difficult to be able to program against it reliably, then I would argue that the API is broken.
I would be inclined to worry less about stability (or even compatibility) at this point and focus on making sure that there is a well thought about API that can genuinely provide Linux desktop audio for the next 10 years. And make sure that API is extremely well documented so application developers can make the switch to the new API as easily as possible.
Today, even some of the biggest software projects have very rapid development cycles compared to what they were a few years ago. Java for example [1]. So any active software should be able to switch to the new API within a few development cycles. The compatibility layer should be a short-term convenience and not a long term back-stop.
Bugs can be fixed relatively easily and quickly. Logical or functional changes to an API not so much.
If this is already the case, then to really have this available as a default option for F34, then documentation needs to have a serious update within the next few weeks. As others have mentioned, there seems to be confusion as to what exactly are the steps involved in testing this out under F33.
I started on the docs page [2] about an hour ago and am still non the wiser as to what I would have to do to test.
There should also be a clear roadmap specifying key dates / releases. For example:-
- Available for testing from F33 onwards. - Default in F34 with compatibility library. - Active support/development of the compatibility library ends with F36.
It would also be worth investigating what would be involved in getting some key software switched over to the new API by way of a showcase.
[1] https://adoptopenjdk.net/support.html [2] https://pipewire.org/#documentation
On Sun, Nov 22, 2020 at 03:42:05PM +0000, Gargoyle wrote:
- Available for testing from F33 onwards.
- Default in F34 with compatibility library.
It needs to be readily available for testing in F(n-1) for a complete release cycle before it can be made the default in F(n).
This is _very_ important to get right. Folks are still trashing Pulse Audio (and its creator) *to this day* for Ubuntu's half-assed PA integration from over a decade ago.
- Active support/development of the compatibility library ends with F36.
Support/development of the compatibility layer needs to continue indefinitely, and certainly a lot longer than one year (ie the F(n)->F(n+2) cycle)
It would also be worth investigating what would be involved in getting some key software switched over to the new API by way of a showcase.
Showcase, sure, but there's a long, long, long tail of barely-maintained software in use that won't get updated to use PW natively anytime soon. If ever.
FFS, most of the software I use today doesn't even use PA directly; it uses ALSA, which gets routed to PA via an ALSA plugin. Compatibility APIs must me maintained nearly indefinitely!
Meanwhile, as another data point, softare that was written using the sound API included with the first Win32 implementation (ie Windows NT 3.1) will still generate sound with current Windows 10 builds, *27* years later.
- Solomon
On Sun, 22 Nov 2020 11:12:57 -0500 Solomon Peachy pizza@shaftnet.org wrote:
On Sun, Nov 22, 2020 at 03:42:05PM +0000, Gargoyle wrote:
- Available for testing from F33 onwards.
- Default in F34 with compatibility library.
It needs to be readily available for testing in F(n-1) for a complete release cycle before it can be made the default in F(n).
Totally agree. This is the minimum standard by which this change should be evaluated. A few test days for rawhide are woefully inadequate.
This is _very_ important to get right. Folks are still trashing Pulse Audio (and its creator) *to this day* for Ubuntu's half-assed PA integration from over a decade ago.
Exactly. I hope the pipewire authors and advocates are smart enough to learn from this. If not them, then FESCO.
FFS, most of the software I use today doesn't even use PA directly; it uses ALSA, which gets routed to PA via an ALSA plugin. Compatibility APIs must me maintained nearly indefinitely!
FWIW, I bypass pulseaudio and use ALSA directly for software that benefits from low-level access to the sound device: Audacity, Kodi, and MythTV.
Jim
On 22/11/2020 16:12, Solomon Peachy wrote:
Showcase, sure, but there's a long, long, long tail of barely-maintained software in use that won't get updated to use PW natively anytime soon. If ever.
FFS, most of the software I use today doesn't even use PA directly; it uses ALSA, which gets routed to PA via an ALSA plugin. Compatibility APIs must me maintained nearly indefinitely!
Nope. I couldn't disagree more. If there's a long tail of unmaintained software without commercial gains, then it should be left to die in the great software graveyard. Feel free to keep a copy of F32 kicking around for when you want to run it, but it should not be a reason to stifle progress.
Meanwhile, as another data point, softare that was written using the sound API included with the first Win32 implementation (ie Windows NT 3.1) will still generate sound with current Windows 10 builds, *27* years later.
Yes. And Microsoft get paid a lot of money to build it that way. There's a commercial gain to be had justifying employing people to keep that compatibility going.
On Sun, Nov 22, 2020 at 07:20:20PM +0000, Gargoyle wrote:
Nope. I couldn't disagree more. If there's a long tail of unmaintained software without commercial gains, then it should be left to die in the great software graveyard. Feel free to keep a copy of F32 kicking around for when you want to run it, but it should not be a reason to stifle progress.
So "Progress" means "Proposing to force everyone to use software that doesn't even work right now, and won't be ready until (at best) a month before the F34 Beta Freeze"
...Right...
Maybe while we're at it we should make Fedora require AVX2, because supporting those old CPUs is clearly "stifiling progress"?
Nobody is saying "never" to pipewire; we are saying "not now", because *it can't be tested right now* and won't likely be ready for actual testing until (optimisticly) about a month before the F34 beta freeze.
To say nothing for the time needed to actually find and fix issues on the long tail of deployed hardware and software. That, to me, is a glaring sign that this proposal is _very_ premature.
Fedora took years before switching to Wayland by default, and that was something that had a far greater upside than this does.
Yes. And Microsoft get paid a lot of money to build it that way. There's a commercial gain to be had justifying employing people to keep that compatibility going.
Are you volunteering to do all of this coding/porting yourself? If not, why do you seem to believe that developer time is without cost?
I hate to break it to you, but 98% of what is in Fedora is "without commercial gains" -- and I can promise you that one year is nowhere near enough time to fix up everything that Fedora ships, much less the long tail of F/OSS that isn't packaged.
- Solomon
On 11/20/20 5:26 PM, Ben Cotton wrote:
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34
IMO, this alone disqualifies this plan.
Fedora should be a stable end-user distro and not a testing site for eager devs to test their immature and incomplete works.
Ralf
On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:
On 11/20/20 5:26 PM, Ben Cotton wrote:
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34
IMO, this alone disqualifies this plan.
Fedora should be a stable end-user distro and not a testing site for eager devs to test their immature and incomplete works.
I think Fedora should establish strong "no regressions" rule when replacing system software like this. PulseAudio has had 15 years of development, features and fixes. It is hard to believe pipewire is as capable as a replacement now.
Of course we would need to start with collecting the use cases, and this will be different for every user. For example, I frequently use my laptop with 3 sound devices present: built-in speakers, speakers connected to USB-C dock and bluetooth headphones*. I use pavucontrol to route applications to proper output/input and I expect this to work the same with PW. This is important to me.
On the other hand, I do not use AC3 passthrough when watching movies and I'm not so much interested in power saving through dynamic latency/timers adjustment and suspending outputs. If this ceased to work, _I_ wouldn't notice. But for someone this may be crucial. The same for equalizer modules. Or volume ramp up. Or multiple device combining. And so on.
Right now "How to test" section of Change Proposal contains only very rudimentary cases like "check if rhythmbox plays". This is not enough when replacing as potent software as PulseAudio.
* - for some BT codecs I need pulseaudio-module-bluetooth-freeworld
On Mon, 2020-11-23 at 18:20 +0100, Tomasz Torcz wrote:
On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:
On 11/20/20 5:26 PM, Ben Cotton wrote:
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34
IMO, this alone disqualifies this plan.
Fedora should be a stable end-user distro and not a testing site for eager devs to test their immature and incomplete works.
I think Fedora should establish strong "no regressions" rule when replacing system software like this. PulseAudio has had 15 years of development, features and fixes. It is hard to believe pipewire is as capable as a replacement now.
I disagree. This would be incompatible with the "First" foundation.
If we'd had a "no regressions" rule for pre-PA audio, we'd probably never have landed PA, or not for years. Are things on the whole better since we did? I'd say yes.
Will our first release with pipewire probably have some bugs that constitute regressions from the previous audio setup? Almost certainly. Especially given the sheer amounts of stuff people do - see your config below - I think we'd find it difficult to have a "no regressions" rule and still be Fedora. Part of Fedora's job is to adopt new things and shake some of the initial bugs out of them.
Of course we would need to start with collecting the use cases, and this will be different for every user. For example, I frequently use my laptop with 3 sound devices present: built-in speakers, speakers connected to USB-C dock and bluetooth headphones*. I use pavucontrol to route applications to proper output/input and I expect this to work the same with PW. This is important to me.
Did that all work with the first Fedora with PA in it? I bet not. Would we have as capable a PA today if Fedora hadn't taken the leap to include PA? Probably not.
On the other hand, I do not use AC3 passthrough when watching movies and I'm not so much interested in power saving through dynamic latency/timers adjustment and suspending outputs. If this ceased to work, _I_ wouldn't notice. But for someone this may be crucial. The same for equalizer modules. Or volume ramp up. Or multiple device combining. And so on.
Yes, and on and on and on and on and on and on and on...
Right now "How to test" section of Change Proposal contains only very rudimentary cases like "check if rhythmbox plays". This is not enough when replacing as potent software as PulseAudio.
*This*, though, I tend to agree with. "How to test" sections do tend to be mailed in. It would be good to cover at least a range of commonly used configurations here.
QA folks, this is definitely a Change that (if approved) we should do a Test Day (or several) for, and probably one that could use help with a better test plan. Do we have any domain experts who'd like to volunteer to work on that? Thanks!
On Mon, Nov 23, 2020 at 09:48:56AM -0800, Adam Williamson wrote:
If we'd had a "no regressions" rule for pre-PA audio, we'd probably never have landed PA, or not for years. Are things on the whole better since we did? I'd say yes.
You are correct; however the crucial difference between then and now is that PulseAudio was installable (and therefore testable) in Fedora 7 prior to Fedora 8 making it the default.
That is not the case with PipeWire today.
QA folks, this is definitely a Change that (if approved) we should do a Test Day (or several) for, and probably one that could use help with a better test plan. Do we have any domain experts who'd like to volunteer to work on that? Thanks!
If "Test Day" requires running rawhide (or booting a LiveUSB image) then I'm not going to be able to do meanigful testing with my actual desktop environment and applications.
- Solomon
On 11/23/20 11:48 AM, Adam Williamson wrote:
On Mon, 2020-11-23 at 18:20 +0100, Tomasz Torcz wrote:
On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:
On 11/20/20 5:26 PM, Ben Cotton wrote:
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34
IMO, this alone disqualifies this plan.
Fedora should be a stable end-user distro and not a testing site for eager devs to test their immature and incomplete works.
I think Fedora should establish strong "no regressions" rule when replacing system software like this. PulseAudio has had 15 years of development, features and fixes. It is hard to believe pipewire is as capable as a replacement now.
I disagree. This would be incompatible with the "First" foundation.
If we'd had a "no regressions" rule for pre-PA audio, we'd probably never have landed PA, or not for years. Are things on the whole better since we did? I'd say yes.
Will our first release with pipewire probably have some bugs that constitute regressions from the previous audio setup? Almost certainly. Especially given the sheer amounts of stuff people do - see your config below - I think we'd find it difficult to have a "no regressions" rule and still be Fedora. Part of Fedora's job is to adopt new things and shake some of the initial bugs out of them.
Of course we would need to start with collecting the use cases, and this will be different for every user. For example, I frequently use my laptop with 3 sound devices present: built-in speakers, speakers connected to USB-C dock and bluetooth headphones*. I use pavucontrol to route applications to proper output/input and I expect this to work the same with PW. This is important to me.
Did that all work with the first Fedora with PA in it? I bet not. Would we have as capable a PA today if Fedora hadn't taken the leap to include PA? Probably not.
[Snip]
PulseAudio wasn't necessarily purporting to be a drop-in replacement for Alsa. It seems like if PipeWire really is going to be swappable like the change text notes[0], we should be looking at this as a rare opportunity to get really widespread testing with a potentially majorly breaking change by offering the ability to easily swap it in and test in already released versions. That way we could be "first" and "battle hardened" at the same time.
Unfortunately, as noted elsewhere in this thread, there really isn't a way to test outside of Rawhide currently[1][2][3]. It seems like the packages are there and should work, but might not[4]?
As I've mentioned elsewhere, I'm not saying handling changes like this should be mandated[5], or even required in this specific case, or elsewhere. But I think there would be less pushback to the change if this was the course of action.
[0] - "This proposal is to replace the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak." [1] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [2] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [3] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [4] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [5] - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Fri, 20 Nov 2020 at 16:28, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
== Owner ==
- Name: [[User:Wtaymans| Wim Taymans]]
- Email: wim.taymans@gmail.com
== Detailed Description ==
This is great news. Whenever it lands. Fantastic.
I have installed pipewire-pulseaudio, pipewire-libjack pipewire-alsa ( pipewire 3.16 rawhide ). Pulseaudio is removed but nevertheless i have no issue actually. Sounds and software (pavucontrol ..etc) are working. Only one of my mixers (plasma-pa) is removed because of a pulseaudio dependency and needs to be rebuild. Sorry for my english.
Hi all,
For short, NO! I want to be able to shutdown pipewire in order to get instant ALSA access.
This was a real pain until pulseaudio recognized what they need to do:
systemctl --user stop pulseaudio systemctl --user stop pulseaudio.socket killall pulseaudio
If you want real low latency you won't do any additional layer on top of ALSA.
Further, my application provides some functional integration tests.
just run:
./configure --enable-run-functional-tests make make check
Alternatively you can run against installed libraries:
./configure --prefix=/usr --enable-run-functional-tests make make ags-integration-functional-test
Or to run in parallel using xvfb-run:
./configure --prefix=/usr --enable-run-functional-tests make make ags-parallel-integration-functional-test
Didn't look at pipewire, yet. Finally, please consider to shutdown the process completely as desired.
regards, Joël
Sounds to me like good opt-out documentation is in order. 🙂
-- Cheers, Justin W. Flory (he/him) https://jwf.io Sent from ProtonMail mobile
-------- Original Message -------- On Nov 24, 2020, 09:19, Joël Krähemann < jkraehemann@gmail.com> wrote: Hi all, For short, NO! I want to be able to shutdown pipewire in order to get instant ALSA access. This was a real pain until pulseaudio recognized what they need to do: systemctl --user stop pulseaudio systemctl --user stop pulseaudio.socket killall pulseaudio
Didn't look at pipewire, yet. Finally, please consider to shutdown the process completely as desired.
On Tue, Nov 24, 2020 at 9:19 AM Joël Krähemann jkraehemann@gmail.com wrote:
Hi all,
For short, NO! I want to be able to shutdown pipewire in order to get instant ALSA access.
This was a real pain until pulseaudio recognized what they need to do:
systemctl --user stop pulseaudio systemctl --user stop pulseaudio.socket killall pulseaudio
If you want real low latency you won't do any additional layer on top of ALSA.
Further, my application provides some functional integration tests.
just run:
./configure --enable-run-functional-tests make make check
Alternatively you can run against installed libraries:
./configure --prefix=/usr --enable-run-functional-tests make make ags-integration-functional-test
Or to run in parallel using xvfb-run:
./configure --prefix=/usr --enable-run-functional-tests make make ags-parallel-integration-functional-test
Didn't look at pipewire, yet. Finally, please consider to shutdown the process completely as desired.
We already have to have PipeWire running in GNOME and Plasma for Wayland sessions, so we can't completely shut it off. However, the pipewire-pulseaudio package provides a separate set of PulseAudio services with the same unit names as the ones provided by the pulseaudio package. Shutting those down would have the same effect for you.
That being said, I have spoken to a few audio engineers, and basically none of them use ALSA directly. They can't because ALSA doesn't support mixing properly, among other things. Most of them use JACK or PulseAudio, depending on their requirements. PipeWire is intended to simplify the pro audio case while bringing those benefits to casual audiophiles who use PulseAudio.
-- 真実はいつも一つ！/ Always, there's only one truth!
Hi,
This is bad.
On Tue, Nov 24, 2020 at 3:27 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Nov 24, 2020 at 9:19 AM Joël Krähemann jkraehemann@gmail.com wrote:
Hi all,
For short, NO! I want to be able to shutdown pipewire in order to get instant ALSA access.
This was a real pain until pulseaudio recognized what they need to do:
systemctl --user stop pulseaudio systemctl --user stop pulseaudio.socket killall pulseaudio
If you want real low latency you won't do any additional layer on top of ALSA.
Further, my application provides some functional integration tests.
just run:
./configure --enable-run-functional-tests make make check
Alternatively you can run against installed libraries:
./configure --prefix=/usr --enable-run-functional-tests make make ags-integration-functional-test
Or to run in parallel using xvfb-run:
./configure --prefix=/usr --enable-run-functional-tests make make ags-parallel-integration-functional-test
Didn't look at pipewire, yet. Finally, please consider to shutdown the process completely as desired.
We already have to have PipeWire running in GNOME and Plasma for Wayland sessions, so we can't completely shut it off. However, the pipewire-pulseaudio package provides a separate set of PulseAudio services with the same unit names as the ones provided by the pulseaudio package. Shutting those down would have the same effect for you.
Well I used to `dnf remove pulseaudio` might be I have to `dnf remove pipewire`, then.
That being said, I have spoken to a few audio engineers, and basically none of them use ALSA directly. They can't because ALSA doesn't support mixing properly, among other things. Most of them use JACK or PulseAudio, depending on their requirements. PipeWire is intended to simplify the pro audio case while bringing those benefits to casual audiophiles who use PulseAudio.
I really doubt that you listen to youtube while creating music. What do you want to mix? Might be for some exotic JACK setup.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Nov 24, 2020 at 2:07 PM Joël Krähemann jkraehemann@gmail.com wrote:
Hi,
This is bad.
On Tue, Nov 24, 2020 at 3:27 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Nov 24, 2020 at 9:19 AM Joël Krähemann jkraehemann@gmail.com wrote:
Hi all,
For short, NO! I want to be able to shutdown pipewire in order to get instant ALSA access.
This was a real pain until pulseaudio recognized what they need to do:
systemctl --user stop pulseaudio systemctl --user stop pulseaudio.socket killall pulseaudio
If you want real low latency you won't do any additional layer on top of ALSA.
Further, my application provides some functional integration tests.
just run:
./configure --enable-run-functional-tests make make check
Alternatively you can run against installed libraries:
./configure --prefix=/usr --enable-run-functional-tests make make ags-integration-functional-test
Or to run in parallel using xvfb-run:
./configure --prefix=/usr --enable-run-functional-tests make make ags-parallel-integration-functional-test
Didn't look at pipewire, yet. Finally, please consider to shutdown the process completely as desired.
We already have to have PipeWire running in GNOME and Plasma for Wayland sessions, so we can't completely shut it off. However, the pipewire-pulseaudio package provides a separate set of PulseAudio services with the same unit names as the ones provided by the pulseaudio package. Shutting those down would have the same effect for you.
Well I used to `dnf remove pulseaudio` might be I have to `dnf remove pipewire`, then.
Sorry, no. Doing that will cause the desktop environment to get uninstalled. We rely on PipeWire for handling mediation of A/V resources across domains, including for handling screensharing and screencasting.
Removal of the pipewire-pulseaudio package will remain possible, but you'll still likely cause problems because the desktops *expect* this stuff to exist and stuff that requires a PulseAudio daemon will be broken if none exist.
That being said, I have spoken to a few audio engineers, and basically none of them use ALSA directly. They can't because ALSA doesn't support mixing properly, among other things. Most of them use JACK or PulseAudio, depending on their requirements. PipeWire is intended to simplify the pro audio case while bringing those benefits to casual audiophiles who use PulseAudio.
I really doubt that you listen to youtube while creating music. What do you want to mix? Might be for some exotic JACK setup.
You never really know. I would be hesitant to presume such things, given the folks I've talked to. At least one of them does in fact do YouTube stuff while doing audio and video production, because that's his job. For him, the PipeWire setup this Change proposes will make his life easier. I expect other pro audio types to be similarly happy about these improvements.
And note, the lead developer of Fedora Jam (a spin dedicated to pro audio) has signed off on this Change. In fact, he was the primary driver for us to work toward making this Change proposal in the first place.
I am working with Wim (the change proposer), the Workstation WG, and the KDE SIG to make the necessary adjustments in Rawhide to support swapping between PulseAudio and PipeWire. So far, Wim has not been interested in backporting the fixes I've made to Fedora 33, so the plan would be to start producing media with PipeWire on it for Rawhide and set up multiple events over the next few months to get things tested.
Richard Brown from openSUSE also informed me that it's technically possible to do some level of audio subsystem QA using OpenQA, but I'm not sure how to do it. Perhaps that's another avenue we can pursue to improve integration testing coverage?
I am working with Wim (the change proposer), the Workstation WG, and the KDE SIG to make the necessary adjustments in Rawhide to support swapping between PulseAudio and PipeWire. So far, Wim has not been interested in backporting the fixes I've made to Fedora 33, so the plan would be to start producing media with PipeWire on it for Rawhide and set up multiple events over the next few months to get things tested.
I really don't think a few test days are at all sufficient for such a sweeping change. The fact users cannot easily test this on F33 makes it even worse. I understand the desire for moving forward, but this change proposal comes off as premature.
On Tue, Nov 24, 2020 at 2:42 PM Tom Seewald tseewald@gmail.com wrote:
I am working with Wim (the change proposer), the Workstation WG, and the KDE SIG to make the necessary adjustments in Rawhide to support swapping between PulseAudio and PipeWire. So far, Wim has not been interested in backporting the fixes I've made to Fedora 33, so the plan would be to start producing media with PipeWire on it for Rawhide and set up multiple events over the next few months to get things tested.
I really don't think a few test days are at all sufficient for such a sweeping change. The fact users cannot easily test this on F33 makes it even worse. I understand the desire for moving forward, but this change proposal comes off as premature.
"Premature" is a weird term to use here, considering the whole point of these things is to be able to do integration work in the first place. And it's not like we can't revert the change before release if it turns out to be problematic.
But that said, I would like to backport all the packaging changes to Fedora 33 too. It's not actually *hard* to do, it's just a matter of getting everyone to agree to get it to happen.
-- 真実はいつも一つ！/ Always, there's only one truth!
"Premature" is a weird term to use here, considering the whole point of these things is to be able to do integration work in the first place. And it's not like we can't revert the change before release if it turns out to be problematic.
Yes, premature as in proposing a huge change to the next version of Fedora before ensuring current users can even test/evaluate said change. The fact that there are packaging conflicts when installing pipewire-pulseaudio strongly suggests that few people have actually been able to install and test the package.
On Tue, Nov 24, 2020 at 3:30 PM Tom Seewald tseewald@gmail.com wrote:
"Premature" is a weird term to use here, considering the whole point of these things is to be able to do integration work in the first place. And it's not like we can't revert the change before release if it turns out to be problematic.
Yes, premature as in proposing a huge change to the next version of Fedora before ensuring current users can even test/evaluate said change. The fact that there are packaging conflicts when installing pipewire-pulseaudio strongly suggests that few people have actually been able to install and test the package.
Currently the PipeWire developers have been doing it by hand while they are developing the software. I have been going through and fixing things so that regular folks can do it semi-automatically.
The packaging for PipeWire has been changing rapidly as the API shims for PulseAudio changed from libraries to a replacement daemon, that's why this is broken again.
Currently the PipeWire developers have been doing it by hand while they are developing the software. I have been going through and fixing things so that regular folks can do it semi-automatically.
The packaging for PipeWire has been changing rapidly as the API shims for PulseAudio changed from libraries to a replacement daemon, that's why this is broken again.
I know why it's currently broken, but that doesn't change the fact that this is being proposed before most people can assess the change. In fact the current amount of churn suggests that pipewire is still a ways off from stabilizing.
On Tue, Nov 24, 2020 at 3:30 PM Tom Seewald <tseewald(a)gmail.com> wrote:
Currently the PipeWire developers have been doing it by hand while they are developing the software. I have been going through and fixing things so that regular folks can do it semi-automatically.
Are there instructions available for this semi-automatic process to test this change now?
On 24.11.2020 21:34, Neal Gompa wrote:
The packaging for PipeWire has been changing rapidly as the API shims for PulseAudio changed from libraries to a replacement daemon, that's why this is broken again.
I see that they removed[1] the API shims. What about applications that require or even dlopen() the libpulse.so* shared libraries?
They will crash if the pulseaudio package will be removed.
[1]: https://src.fedoraproject.org/rpms/pipewire/c/306d51984ef5faf4ea455e6d385f0f...
On Wed, Nov 25, 2020 at 6:06 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 24.11.2020 21:34, Neal Gompa wrote:
The packaging for PipeWire has been changing rapidly as the API shims for PulseAudio changed from libraries to a replacement daemon, that's why this is broken again.
I see that they removed[1] the API shims. What about applications that require or even dlopen() the libpulse.so* shared libraries?
They will crash if the pulseaudio package will be removed.
We don't use API shims anymore for PulseAudio, we now replace the daemon and reuse the original PulseAudio libraries.
On 25.11.2020 13:36, Neal Gompa wrote:
We don't use API shims anymore for PulseAudio, we now replace the daemon and reuse the original PulseAudio libraries.
This is not a complete replacement now. Running another daemon is not good for me.
On Tue, Nov 24, 2020 at 8:05 PM Neal Gompa ngompa13@gmail.com wrote:
But that said, I would like to backport all the packaging changes to Fedora 33 too. It's not actually *hard* to do, it's just a matter of getting everyone to agree to get it to happen.
I think that being able to easily install/revert and run pipewire as default in the F33 release will result in the confidence that it is ready (or at least mostly ready) and does not impact most of the Fedora community, which would presumably make the decision to move forward non-controversial. And non-controversial well tested (or testable) is presumably a goal.
I, for one, would be happy to run pipewire on my daily F33 driver if I did not have to currently jump through so many hoops to do so.
On 11/24/20 9:17 PM, Neal Gompa wrote:
On Tue, Nov 24, 2020 at 2:07 PM Joël Krähemann jkraehemann@gmail.com wrote:
That being said, I have spoken to a few audio engineers, and basically none of them use ALSA directly. They can't because ALSA doesn't support mixing properly, among other things. Most of them use JACK or PulseAudio, depending on their requirements. PipeWire is intended to simplify the pro audio case while bringing those benefits to casual audiophiles who use PulseAudio.
I really doubt that you listen to youtube while creating music. What do you want to mix? Might be for some exotic JACK setup.
You never really know. I would be hesitant to presume such things, given the folks I've talked to. At least one of them does in fact do YouTube stuff while doing audio and video production, because that's his job. For him, the PipeWire setup this Change proposes will make his life easier. I expect other pro audio types to be similarly happy about these improvements.
Indeed.
This discussion seems to be a proof that people can get used and attached to absolutely anything at all, such as three audio subsystems competing for the same resources being somehow a good thing.
The extent to which the multi-headed monster has been tamed over time is amazing, but on the production side there's never a point in time where you can truly forget, much less ignore the great divide underneath. All of which is just a constant unwanted distraction when you're trying to create music.
If something can unify that mess then halleluja.
- Panu -
Neal Gompa ngompa13@gmail.com writes:
Richard Brown from openSUSE also informed me that it's technically possible to do some level of audio subsystem QA using OpenQA, but I'm not sure how to do it. Perhaps that's another avenue we can pursue to improve integration testing coverage?
While it is technically possible to do audio testing in openQA, it is not really used a lot. The main reason is that the current implementation is rather brittle (albeit pretty clever): it converts the audio signal to an image (afaik it plots the intensity) and does its usual needle comparison. Unfortunately this does not work that well in practice and the one of the few audio tests that openSUSE has in openQA is a constant source of trouble, while catching very few bugs [1].
But even if openQA had a very reliable way to test audio, I'm afraid it wouldn't really help us out too much here. openQA is realistically only going to be able to cover your basic use cases, but it's not going to be able to test all the special audio setups that all the people who are into audio have at home (as that would require their hardware & software). So openQA would only test what the PipeWire devs are probably testing already anyway and it would not provide a whole lot of additional interesting test cases.
Now, this does not mean that we shouldn't test audio in Fedora's openQA (we don't atm), as that is still a valuable regression test. But we won't be able to cover a lot of the more interesting use cases where I would expect [2] that most of current the bugs are. Those will only get found by running this on real world hardware by folks that have their working setups.
Cheers,
Dan
Footnotes: [1] I've heard this only, take this with a pinch of salt.
[2] emphasis on _expect_, not _know_. I really have no insight in the maturity of PiperWire.
On Mon, 2020-11-30 at 00:24 +0100, Dan Čermák wrote:
Neal Gompa ngompa13@gmail.com writes:
Richard Brown from openSUSE also informed me that it's technically possible to do some level of audio subsystem QA using OpenQA, but I'm not sure how to do it. Perhaps that's another avenue we can pursue to improve integration testing coverage?
While it is technically possible to do audio testing in openQA, it is not really used a lot. The main reason is that the current implementation is rather brittle (albeit pretty clever): it converts the audio signal to an image (afaik it plots the intensity) and does its usual needle comparison. Unfortunately this does not work that well in practice and the one of the few audio tests that openSUSE has in openQA is a constant source of trouble, while catching very few bugs [1].
But even if openQA had a very reliable way to test audio, I'm afraid it wouldn't really help us out too much here. openQA is realistically only going to be able to cover your basic use cases, but it's not going to be able to test all the special audio setups that all the people who are into audio have at home (as that would require their hardware & software). So openQA would only test what the PipeWire devs are probably testing already anyway and it would not provide a whole lot of additional interesting test cases.
Now, this does not mean that we shouldn't test audio in Fedora's openQA (we don't atm), as that is still a valuable regression test. But we won't be able to cover a lot of the more interesting use cases where I would expect [2] that most of current the bugs are. Those will only get found by running this on real world hardware by folks that have their working setups.
Yeah, I looked into it before and this is basically why I didn't bother implementing it; it doesn't buy us much more than we're getting naturally from human testing anyway.
Adam Williamson adamwill@fedoraproject.org writes:
On Mon, 2020-11-30 at 00:24 +0100, Dan Čermák wrote:
Neal Gompa ngompa13@gmail.com writes:
Now, this does not mean that we shouldn't test audio in Fedora's openQA (we don't atm), as that is still a valuable regression test. But we won't be able to cover a lot of the more interesting use cases where I would expect [2] that most of current the bugs are. Those will only get found by running this on real world hardware by folks that have their working setups.
Yeah, I looked into it before and this is basically why I didn't bother implementing it; it doesn't buy us much more than we're getting naturally from human testing anyway.
Well, except that a human needn't lift a finger anymore to check if there's actually sound coming out of vlc/mpv/firefox/etc. ;-).
Now checking whether that's actually the sound that you expect or whether it has the correct volume is an entirely different story of course and I'm afraid that's something where we'll have to rely on humans or $shinyMlAiSolutionThatSolvesAllOurProblems.
Cheers,
Dan
On Tue, Nov 24, 2020 at 08:06:41PM +0100, Joël Krähemann wrote:
On Tue, Nov 24, 2020 at 3:27 PM Neal Gompa ngompa13@gmail.com wrote:
That being said, I have spoken to a few audio engineers, and basically none of them use ALSA directly. They can't because ALSA doesn't support mixing properly, among other things. Most of them use JACK or PulseAudio, depending on their requirements. PipeWire is intended to simplify the pro audio case while bringing those benefits to casual audiophiles who use PulseAudio.
I really doubt that you listen to youtube while creating music. What do you want to mix? Might be for some exotic JACK setup.
FWIW, as an amateur musician, bandmates send me youtube links for songs they want to cover, and as part of learning the song I may play along with the youtube video, record it to an Ardour track, etc.
All currently doable on Fedora but there are some hoops to jump through.
(Very much looking forward to PipeWire.)
--b.
I'm very excited about this change and ultimately want to be able to test it out but it seems that there are still package dependency issues. How can I test this out on my end using the repos in their current state on either Fedora 33 or Rawhide? I've got a few systems I can test on to see if there are any regressions, and don't mind running Rawhide to do some testing. Is there a write-up of how to test this that we can follow in the meantime until the packaging fixes land in Rawhide, or should end-users wait until Pipewire is packaged and set as default in a nightly Rawhide build? It seems like it would greatly benefit the Fedora project to get as many people trying this change out as possible.
-- Dylan Taylor
Hi all,
First of all, thanks for the comments, keep them coming. We have seen these concerns many times before with big infrastructure changes like pulseaudio or wayland or systemd. I think they are necessary to keep our feet on the ground and not get carried away by our pipe dreams (pun intended).
As the author of PipeWire and creator of this Change proposal, I will try to address some of the concerns I see here in the comments:
It needs more testing...
This change request is about enabling PipeWire audio by default *for testing* in a testing environment. I'm proposing this because I think it is ready for *testing*. I hear some claims that it is too early to test; as the main developer, I disagree. It's not too early to test. People have been running PipeWire as the main audio backend for some time now, and so can you.
The goal when enabling this by default is to have a nicely integrated solution that people can try, test and revert. This will give us more testers and feedback and bring us closer to the final goal.
but I can't even enable it to test! packages don't install and have conflicts!
We're working on getting the dependencies right on other packages so that we can actually swap implementation.
Should we have waited until this works better? perhaps.
We ask for some patience until this is fixed, I expect this to be testable next week. Stay tuned for an update.
This is going to be so buggy, why do this to us
The feedback from early testers give me confidence that it will not be all doom. There will be bugs, they will get fixed and you'll have to retest. It is how to move forward.
By the end of the testing and the beta freeze we end up with a nice list of bugs and must-have features that people found (or not) and we roll back (or not).
why bother, this will fail and we'll have to roll back anyway
I have no problem whatsoever with rolling back after an honest round of testing. This proposal will be resubmitted for the next release and we try again. But, this would be all pointless without taking the risk to actually test the new things first.
it's still in active development
A project like this takes time to develop and will hopefully be in active development for many more years. There are so many ideas remaining...
Development of the video parts started in early 2017, more than 3 years ago and ended up in fedora 27 as a dependency for screencasting.
Development and testing of the redesigned audio core started in june 2018 and ended up in Fedora 32. You could already test the audio on f32 and some people did.
The core audio parts and API/ABI has been stable since february 2020. Since then we've been working on the use cases, management of devices and streams and tools. We've had a crew of early testers and incredible feedback.
I believe It's ready for more testing.
but the pulseaudio replacement server is only 5 weeks old!
It is and it works very nicely indeed, I want you to try it.
What's more impressive is that it does not take a lot of complicated code to implement this on top of PipeWire.
It's not ready, it needs to mature more, it's too early
This may be true but it's too early to make that decision without giving it a round of testing first, IMHO.
There are things that are not implemented yet but I think those are not important enough to block general testing.
Some thing might simply not be implemented either (like ESD compatibility) and will cause regressions. I want to know what's important for people, what are must-haves.
there is not enough time to test
Perhaps not and then we need to roll back and test more in the next rawhide. It should not stop us from starting to test now, when the developers think it's ready for testing.
I don't know how to measure when 'enough testing' has been done. It ultimately depends on how confident people feel after using it for a while.
I've tried it and it doesn't work
You have not tried what we propose for rawhide and f34 because there is no easy way to install this yet, please stay tuned. We're going to be fixing the dependencies and upgrading to the latest versions to make this easy.
Also please tell us what is wrong and please try again after a fix landed.
Much of the instability with browsers and music players got fixed after the pulseaudio replacement server was implemented.
but I don't want to test all this
This is ok, I can understand that you don't want to deal with possible audio problems. You will have to install pulseaudio again and opt out. You will have to hope that other people do sufficient testing. It is a bit strange when you are running rawhide, but hey.
but this and that is broken, it's all pointless, why bother, you'll never get this fixed in time
Maybe so. Please let us know what's broken. It might be an easy fix and we can retest an updated version. Or not, and then it's a blocker and we roll back. But you have to let us know.
So my proposal still is:
* Make it easy to swap, hopefully get that working smoothly next week. stay tuned. * Enable by default in rawhide * fix bugs, repeat, retest.. * collect final experiences at beta freeze, re-evaluate rollback or not
Is this something we can agree on?
Wim
On 25/11/2020 10:47, Wim Taymans wrote:
but I don't want to test all this
This is ok, I can understand that you don't want to deal with possible audio problems. You will have to install pulseaudio again and opt out. You will have to hope that other people do sufficient testing. It is a bit strange when you are running rawhide, but hey.
I think a key problem is that this is a feature that can only really be tested in a desktop environment and not many people run rawhide on a desktop, so if it's only testable in rawhide how much testing will it really get.
That's probably why people are so keen to be able to test it in F33 or to delay it for a further cycle.
Tom
On ke, 25 marras 2020, Wim Taymans wrote:
Hi all,
First of all, thanks for the comments, keep them coming. We have seen these concerns many times before with big infrastructure changes like pulseaudio or wayland or systemd. I think they are necessary to keep our feet on the ground and not get carried away by our pipe dreams (pun intended).
As the author of PipeWire and creator of this Change proposal, I will try to address some of the concerns I see here in the comments:
It needs more testing...
This change request is about enabling PipeWire audio by default *for testing* in a testing environment. I'm proposing this because I think it is ready for *testing*. I hear some claims that it is too early to test; as the main developer, I disagree. It's not too early to test. People have been running PipeWire as the main audio backend for some time now, and so can you.
The goal when enabling this by default is to have a nicely integrated solution that people can try, test and revert. This will give us more testers and feedback and bring us closer to the final goal.
but I can't even enable it to test! packages don't install and have conflicts!
We're working on getting the dependencies right on other packages so that we can actually swap implementation.
Should we have waited until this works better? perhaps.
We ask for some patience until this is fixed, I expect this to be testable next week. Stay tuned for an update.
This is going to be so buggy, why do this to us
The feedback from early testers give me confidence that it will not be all doom. There will be bugs, they will get fixed and you'll have to retest. It is how to move forward.
By the end of the testing and the beta freeze we end up with a nice list of bugs and must-have features that people found (or not) and we roll back (or not).
why bother, this will fail and we'll have to roll back anyway
I have no problem whatsoever with rolling back after an honest round of testing. This proposal will be resubmitted for the next release and we try again. But, this would be all pointless without taking the risk to actually test the new things first.
it's still in active development
A project like this takes time to develop and will hopefully be in active development for many more years. There are so many ideas remaining...
Development of the video parts started in early 2017, more than 3 years ago and ended up in fedora 27 as a dependency for screencasting.
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
How can we make sure audio replacement doesn't end up in the same state?
Development and testing of the redesigned audio core started in june 2018 and ended up in Fedora 32. You could already test the audio on f32 and some people did.
The core audio parts and API/ABI has been stable since february 2020. Since then we've been working on the use cases, management of devices and streams and tools. We've had a crew of early testers and incredible feedback.
I believe It's ready for more testing.
A traditional way to provide testing ground is to:
- make packages available on current Fedora release through COPR repositories
- provide them in Rawhide
- provide means to switch to the proposed setup manually with somewhat easy and documented set of steps
- provide pre-integrated image that defaults to the proposed setup
Enabling Pipewire Audio by default in Rawhide does not give any indication things work because Fedora users aren't necessary using Rawhide as their desktop environments.
Please consider at least providing COPR repository for Fedora 33 so that it is easy to switch to PipeWire Audio on otherwise working desktop system -- without the necessity to install a virtual environment with Rawhide.
but the pulseaudio replacement server is only 5 weeks old!
It is and it works very nicely indeed, I want you to try it.
What's more impressive is that it does not take a lot of complicated code to implement this on top of PipeWire.
It's not ready, it needs to mature more, it's too early
This may be true but it's too early to make that decision without giving it a round of testing first, IMHO.
There are things that are not implemented yet but I think those are not important enough to block general testing.
Some thing might simply not be implemented either (like ESD compatibility) and will cause regressions. I want to know what's important for people, what are must-haves.
there is not enough time to test
Perhaps not and then we need to roll back and test more in the next rawhide. It should not stop us from starting to test now, when the developers think it's ready for testing.
I don't know how to measure when 'enough testing' has been done. It ultimately depends on how confident people feel after using it for a while.
I've tried it and it doesn't work
You have not tried what we propose for rawhide and f34 because there is no easy way to install this yet, please stay tuned. We're going to be fixing the dependencies and upgrading to the latest versions to make this easy.
Also please tell us what is wrong and please try again after a fix landed.
Much of the instability with browsers and music players got fixed after the pulseaudio replacement server was implemented.
but I don't want to test all this
This is ok, I can understand that you don't want to deal with possible audio problems. You will have to install pulseaudio again and opt out. You will have to hope that other people do sufficient testing. It is a bit strange when you are running rawhide, but hey.
but this and that is broken, it's all pointless, why bother, you'll never get this fixed in time
Maybe so. Please let us know what's broken. It might be an easy fix and we can retest an updated version. Or not, and then it's a blocker and we roll back. But you have to let us know.
So my proposal still is:
- Make it easy to swap, hopefully get that working smoothly next week. stay tuned.
- Enable by default in rawhide
- fix bugs, repeat, retest..
- collect final experiences at beta freeze, re-evaluate rollback or not
Is this something we can agree on?
Wim
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Wed, Nov 25, 2020 at 7:49 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On ke, 25 marras 2020, Wim Taymans wrote:
Hi all,
First of all, thanks for the comments, keep them coming. We have seen these concerns many times before with big infrastructure changes like pulseaudio or wayland or systemd. I think they are necessary to keep our feet on the ground and not get carried away by our pipe dreams (pun intended).
As the author of PipeWire and creator of this Change proposal, I will try to address some of the concerns I see here in the comments:
It needs more testing...
This change request is about enabling PipeWire audio by default *for testing* in a testing environment. I'm proposing this because I think it is ready for *testing*. I hear some claims that it is too early to test; as the main developer, I disagree. It's not too early to test. People have been running PipeWire as the main audio backend for some time now, and so can you.
The goal when enabling this by default is to have a nicely integrated solution that people can try, test and revert. This will give us more testers and feedback and bring us closer to the final goal.
but I can't even enable it to test! packages don't install and have conflicts!
We're working on getting the dependencies right on other packages so that we can actually swap implementation.
Should we have waited until this works better? perhaps.
We ask for some patience until this is fixed, I expect this to be testable next week. Stay tuned for an update.
This is going to be so buggy, why do this to us
The feedback from early testers give me confidence that it will not be all doom. There will be bugs, they will get fixed and you'll have to retest. It is how to move forward.
By the end of the testing and the beta freeze we end up with a nice list of bugs and must-have features that people found (or not) and we roll back (or not).
why bother, this will fail and we'll have to roll back anyway
I have no problem whatsoever with rolling back after an honest round of testing. This proposal will be resubmitted for the next release and we try again. But, this would be all pointless without taking the risk to actually test the new things first.
it's still in active development
A project like this takes time to develop and will hopefully be in active development for many more years. There are so many ideas remaining...
Development of the video parts started in early 2017, more than 3 years ago and ended up in fedora 27 as a dependency for screencasting.
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
How can we make sure audio replacement doesn't end up in the same state?
That is a bug with GNOME. I have been using Plasma Wayland screencasting perfectly with Plasma 5.20 on Fedora 33 with all three this week. Could you please file a bug report against gnome-shell about the issue?
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium?
Tom
On ke, 25 marras 2020, Tomáš Popela wrote:
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium?
Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work.
What I also see on this F33 instance is that mic input often disappears from Chrome -- Firefox continues to see it but Chrome doesn't. And it is even for a built-in mic on the laptop. In fact, I have now three mics connected (one in Logitech's camera, one USB mic, one built-in) and regularly get Chrome to not see any of the mics while GNOME Settings can see them. Restart of Chrome helps for the first meeting done, then I need to restart it again.
But even in Firefox no actual screen sharing happens. It doesn't complain -- simply nothing gets out while everything is saying it should.
On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:
On ke, 25 marras 2020, Tomáš Popela wrote:
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium?
Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work.
It also doesn't work for me: with the chrome option enabled, the list of windows to share and the list of screens to share are both empty. In addition to the chrome dialog I get two popups asking me which window to share, but selecting something there doesn't seem to have any effect.
Zbyszek
On Thu, Nov 26, 2020 at 8:35 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:
On ke, 25 marras 2020, Tomáš Popela wrote:
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium?
Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work.
It also doesn't work for me: with the chrome option enabled, the list of windows to share and the list of screens to share are both empty. In addition to the chrome dialog I get two popups asking me which window to share, but selecting something there doesn't seem to have any effect.
Something about Firefox makes it request for me three times, but after that it seems to work.
Dne 26. 11. 20 v 14:38 Neal Gompa napsal(a):
On Thu, Nov 26, 2020 at 8:35 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:
On ke, 25 marras 2020, Tomáš Popela wrote:
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium?
Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work.
It also doesn't work for me: with the chrome option enabled, the list of windows to share and the list of screens to share are both empty. In addition to the chrome dialog I get two popups asking me which window to share, but selecting something there doesn't seem to have any effect.
Something about Firefox makes it request for me three times, but after that it seems to work.
But once you loose the selection dialog, you won't get it again anymore :/ But this seems to be FF issue, not Pipewire.
Vít
On to, 26 marras 2020, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:
On ke, 25 marras 2020, Tomáš Popela wrote:
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium?
Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work.
It also doesn't work for me: with the chrome option enabled, the list of windows to share and the list of screens to share are both empty. In addition to the chrome dialog I get two popups asking me which window to share, but selecting something there doesn't seem to have any effect.
I get the same behavior in Chrome but in Firefox it shows proper dialogs and still fails to send anything out.
On to, 26 marras 2020, Alexander Bokovoy wrote:
On to, 26 marras 2020, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Nov 25, 2020 at 04:41:56PM +0200, Alexander Bokovoy wrote:
On ke, 25 marras 2020, Tomáš Popela wrote:
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Screencasting still does not work in Fedora 33. It pretends to work as in claiming through the applications and GNOME indicators that the screen / application window / browser tabs are shared but nothing gets actually shared. Tested today with Firefox and Chrome on Wayland for Google Meet, BlueJeans, Jitsi.
Works flawlessly here (Firefox and Chrome/Chromium) for some time. Do you have the chrome://flags/#enable-webrtc-pipewire-capturer option enabled in Chrome/Chromium?
Yes! And nothing works. It worked for me partially in F33 beta, not anymore since F33 release. May be before that -- I did not track back exact date when things changed to not work.
It also doesn't work for me: with the chrome option enabled, the list of windows to share and the list of screens to share are both empty. In addition to the chrome dialog I get two popups asking me which window to share, but selecting something there doesn't seem to have any effect.
I get the same behavior in Chrome but in Firefox it shows proper dialogs and still fails to send anything out.
With the help of Tomas and Jan, we've got this sorted out. Upgrade to pipewire 0.3.15 did help with Chrome, Firefox, and OBS being now able to share the screen. It doesn't help with UX of pipewire portal dialogs but this is something I can live with for time being.
With the help of Tomas and Jan, we've got this sorted out. Upgrade to pipewire 0.3.15 did help with Chrome, Firefox, and OBS being now able to share the screen. It doesn't help with UX of pipewire portal dialogs but this is something I can live with for time being.
Hi,
I noticed a pipewire update today and that greatly reduced the list of dependent packages getting in the way of a dnf swap:
paprefs pulseaudio-module-bluetooth-freeworld (rpmfusion) pulseaudio-module-gconf pulseaudio-module-gsettings pulseaudio-module-x11 xfce4-pulseaudio-plugin
The paprefs package depends on pulseaudio-module-gsettings and is not a problem, more like a collateral casualty.
The non-rpmfusion pulseaudio-module-* packages seem to be part of the problem with an explicit pulseaudio dependency. They all come from the pulseaudio SRPM, but it's not clear whether the scope of the pipewire-pulseaudio package includes those modules. Playing a bit with dnf repoquery it doesn't seem to be the case, and the other pulseaudio-module-* packages I didn't install on my system seem to share the same behavior.
Same explicit dependency with the xfce4-pulseaudio-plugin package.
I'm now much closer to giving pipewire a try.
Dridi
Same explicit dependency with the xfce4-pulseaudio-plugin package.
I'm now much closer to giving pipewire a try.
The f33 xfce4-pulseaudio-plugin package from updates-testing can now work with pipewire and so far so good. I'm of course lacking the features I was using with paprefs, but will try to find in the pipewire docs whether the same can be achieved with pipewire-specific tooling.
My main case was the "simultaneous output devices" to not have to do anything when I switch between bluetooth devices (plural) or physical jack output.
Not sure when I'll get a chance to try Ardour, I haven't used it in months.
Cheers
The f33 xfce4-pulseaudio-plugin package from updates-testing can now work with pipewire and so far so good. I'm of course lacking the features I was using with paprefs, but will try to find in the pipewire docs whether the same can be achieved with pipewire-specific tooling.
My main case was the "simultaneous output devices" to not have to do anything when I switch between bluetooth devices (plural) or physical jack output.
Not sure when I'll get a chance to try Ardour, I haven't used it in months.
I wish I could have answered earlier but sharing my feedback now is better than never.
I'd like to state first that while I enjoy pulseaudio without being very knowledgeable or proficient, I'm also very enthusiast about pipewire. I'm however feeling very uneasy with pipewire replacing pulesaudio by default. At least from my experience on the Xfce spin.
First, I had to reboot my laptop to formally switch to pipewire, which was not needed to switch back to pulseaudio. I'm not ruling out pebcak on this specific point.
Then I started using pipewire and pavucontrol to switch between devices, adjust volume for certain applications, configure devices. I have some problems with pulseaudio where some applications like firefox won't remember the volume I set them at (or maybe firefox forces a 100% volume whenever it starts an audio server?) and some applications like firefox will have their audio delayed the longer a video meeting lasts and some applications refuse to have their output changed (not firefox for that matter) for example via pavucontrol.
With pipewire it was stated in the change description that not all of the features of the pulseaudio daemon were supported, and it was visible. I was unable to select an output device for a running application, any application. I would have to set the device I wanted as the default one and it would only take effect for future playbacks. With bluetooth devices in particular I was not always able to switch between profiles.
Finally, one day after saying "so far so good" the pipewire-pulse daemon started failing. I tried to dig the following logs from journalctl but the interesting stuff seems to be gone already. Restarting the daemon didn't help, which never happened to me with pulseaudio. The pulseaudio daemon may fail me a couple times a year, but a restart of the service always solved the immediate problem.
I used pipewire-pulse mainly with Firefox, Pragha and VLC (from rpmfusion). VCL didn't work at all, I had to switch its audio to ALSA to get sound. Everything else worked, modulus the problems mentioned above like changing outputs etc.
In terms of devices I used built-in speakers, didn't think about trying built-in jack, but used the built-in microphone. I also had bluetooth devices in A2DP and HSP/HFP (including microphone) and a USB microphone. No problems with the devices besides not being able to route an application to or from a specific one without making it the default.
Unfortunately I didn't have time to share my notes earlier, and no time either to try to understand and possibly reproduce failures. So I will keep an eye (and an ear) on piprewire but I would recommend strongly against making it the default based on what I was able to test. I would be happy to participate in a test day if (big if) I'm available to follow troubleshooting and error reporting instructions because my understanding is that this is a fast-moving project, but I'm not confident it is ready to replace pulseaudio yet.
Maybe next time I'll get a chance to play with pulseaudio-jack too.
Dridi
I can confirm that this works great. I've used it with BlueJeans without issue.
So, the current sentiment is:
* provide an easy way to test in f33, either copr or with regular packages. - rawhide is a not a good place to get good testing anyway * encourage people to test. Provide instructions on how to do this and how to leave feedback. * Carry this over to f34, probably with just the packages/easier switch. * propose permanent switch for f35 - it gets at least full cycle of testing (f34 + part of f33) * re-evaluate situation for f35 beta freeze to make a default switch.
Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch?
Wim
On 11/25/20 8:18 AM, Wim Taymans wrote:
So, the current sentiment is:
- provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
- encourage people to test. Provide instructions on how to do this and how to leave feedback.
- Carry this over to f34, probably with just the packages/easier switch.
- propose permanent switch for f35
- it gets at least full cycle of testing (f34 + part of f33)
- re-evaluate situation for f35 beta freeze to make a default switch.
Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch?
Wim
My intention in stating my wishes this could be tested more widely was not to discourage this as a change for F34. I just hoped that since the change request states PipeWire is intended to work as a drop-in replacement for PulseAudio, that we could find a way to drop it in for at least Fedora 33 (copr, whatever), and hopefully maximize the test coverage. I figured more, easier, testing would make everybody more comfortable with inclusion in F34.
Even if it can't be an easy drop-in, I would at least like to see the documentation updated for how to hack it in, since apparently the symlink method is no longer the intended method.
No matter what, thank you so much for working so hard to improve the state of A/V in Linux!
On Wed, Nov 25, 2020 at 02:18:45PM -0000, Wim Taymans wrote:
So, the current sentiment is:
Well, of a few folks. :)
- provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
It's likely more limited than f33 for sure, but it's still vaulable. I run rawhide on my main laptop and I know a number of QA folks do as well when there is no branched. After f34 branches off rawhide, I know a number of people who switch to it to test.
- encourage people to test. Provide instructions on how to do this and how to leave feedback.
- Carry this over to f34, probably with just the packages/easier switch.
- propose permanent switch for f35
- it gets at least full cycle of testing (f34 + part of f33)
- re-evaluate situation for f35 beta freeze to make a default switch.
Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch?
I don't think we need to go this slow, unless we run into problems...
If we run into problems in f34, we can just revert and try again for f35. Of course that does assume that it's made easy to switch the default back.
So, for me personally, I think having a way to test in f33 would be great and provide more feedback, but I think we should move ahead for f34 unless there's blockers, in which case we revert back and try for f35.
kevin
On Wed, Nov 25, 2020 at 7:01 PM Kevin Fenzi kevin@scrye.com wrote:
I don't think we need to go this slow, unless we run into problems...
If we run into problems in f34, we can just revert and try again for f35. Of course that does assume that it's made easy to switch the default back.
So, for me personally, I think having a way to test in f33 would be great and provide more feedback, but I think we should move ahead for f34 unless there's blockers, in which case we revert back and try for f35.
What Kevin said reflects my thoughts as well. It's worth trying to aim for f34 and fall back to f35 if it doesn't work well enough.
Kalev
- re-evaluate situation for f35 beta freeze to make a default switch.
Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch?
I feel that based on testing if there are no caveats discovered the switch could still be made for F34 as the default and there could be an easy switch back to PulseAudio if users need it for some reason.
On 2020-11-25 6:18 a.m., Wim Taymans wrote:
So, the current sentiment is:
- provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
That will be great as a lab suite maintainer. pipewire-pulse is currently missing as package and the documentation needs update. Rather sooner should pipewire aimed to default on Fedora 34 which will follow the 4 F principles.
I also run Rawhide on desktop.
Running Rawhide, I don't think there is a need to postpone this, if the PipeWire and PA are easily swap-able and that should be possible next week as far as I understand your plan. That means everybody will be able to switch back to PA if there are issues. That should be good for Rawhide as well as F34.
Vít
Dne 25. 11. 20 v 15:18 Wim Taymans napsal(a):
So, the current sentiment is:
- provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
- encourage people to test. Provide instructions on how to do this and how to leave feedback.
- Carry this over to f34, probably with just the packages/easier switch.
- propose permanent switch for f35
- it gets at least full cycle of testing (f34 + part of f33)
- re-evaluate situation for f35 beta freeze to make a default switch.
Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch?
Wim _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
"Wim Taymans" wtaymans@fedoraproject.org writes:
So, the current sentiment is:
- provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
- encourage people to test. Provide instructions on how to do this and how to leave feedback.
- Carry this over to f34, probably with just the packages/easier switch.
Yeah, I have the feeling that we should give this a good round of testing for a whole release cycle at least before we PipeWire the default. Especially if we make it simple to switch between PulseAudio & PipeWire, we'll give the developers much more usage data than from a few test days.
- propose permanent switch for f35
- it gets at least full cycle of testing (f34 + part of f33)
- re-evaluate situation for f35 beta freeze to make a default switch.
Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch?
Hm, I don't see a technical reason why a certain edition of Fedora couldn't ship with PipeWire by default earlier. Albeit I don't think that jumping ahead of the rest of the distro would reflect very well on the project, unless you call it "Fedora PipeWire Edition".
Cheers,
Dan
On Mon, 2020-11-30 at 00:31 +0100, Dan Čermák wrote:
"Wim Taymans" wtaymans@fedoraproject.org writes:
- propose permanent switch for f35
- it gets at least full cycle of testing (f34 + part of f33)
- re-evaluate situation for f35 beta freeze to make a default
switch.
Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch?
Hm, I don't see a technical reason why a certain edition of Fedora couldn't ship with PipeWire by default earlier. Albeit I don't think that jumping ahead of the rest of the distro would reflect very well on the project, unless you call it "Fedora PipeWire Edition".
It will be a spin in this case (Jam), not an edition, right? (And editions sometimes do differ in what features they ship, e.g. Workstation defaulted to btrfs in F33 but Server had not.
If the benefits for pro audio users outweigh any issues that cause the default to be reverted to Pulseaudio, I can see it being valuable to Jam to stick to Pipewire anyway while the balance goes the other way around for non-pro users who don't use JACK.
Cheers,
On Fri, 20 Nov 2020 at 16:27, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Scope ==
- Proposal owners:
We would make a pipewire-pulse package that provides the same features as the pulseaudio (daemon) package. We would only provide a drop-in replacement daemon, the pulseaudio client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio package is removed and replaced by the pipewire-pulse implementation.
Is it required to make the packages conflict?
The implementation that is used needs to have its service activated.
I understand the need for replacing pulseaudio package when upgrading, but it should be possible to have both installed and have the service from only one activated? Atleast for current fedora that will make it easier to test and switch between implementations.
On 12/5/20 12:39 PM, Naheem Zaffar wrote:
I understand the need for replacing pulseaudio package when upgrading, but it should be possible to have both installed and have the service from only one activated? Atleast for current fedora that will make it easier to test and switch between implementations.
The point is you don't want/shouldn't have both pipewire and pulseaudio installed simultaneously since pipewire-pulseaudio is a drop-in replacement.
So no, that would be a bad idea.
Wouldn't using a "Conflicts=" option in the systemd user unit file work while preventing both from running simultaneously? (I mean, except when it is started from cli directly.)
Le 05/12/2020 à 21:43, Erich Eickmeyer a écrit :
On 12/5/20 12:39 PM, Naheem Zaffar wrote:
I understand the need for replacing pulseaudio package when upgrading, but it should be possible to have both installed and have the service from only one activated? Atleast for current fedora that will make it easier to test and switch between implementations.
The point is you don't want/shouldn't have both pipewire and pulseaudio installed simultaneously since pipewire-pulseaudio is a drop-in replacement.
So no, that would be a bad idea.
-- Erich Eickmeyer Maintainer Fedora Jam
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Hi,
I'm the packager of pulseaudio-module-bluetooth-freeworld in rpmfusion. That library provides AAC, LDAC and aptX for Bluetooth users.
What seems to be the case is that pipewire can already be built with aptX and ldac support: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/meson.bui...
There's a lot of work going on to improve Bluetooth support, which is great!
We already have libldac in Fedora, and here's a review request for libopenaptx: https://bugzilla.redhat.com/show_bug.cgi?id=1908922 (I appreciate if some of you could take a look)
This way, we could update the pipewire package to build with these in Fedora and have first-class support for these codecs.
Best regards, Greg
On 20/11/2020 16:26, Ben Cotton wrote:
== Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
So I tried this in F33 with the packages from updates-testing and I'm afraid to say it didn't end well...
Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
As pactl was removed by the switch I couldn't test this.
- gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch.
This worked initially, but see later.
- pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
Didn't test this.
- firefox: check out a website with audio/video such as youtube and
verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111).
Didn't test this.
- rhythmbox: check if playback works as expected
This worked initially, but see later.
- bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
I was unable to get this to work.
The first problem is that bluetooth is not actually enabled by default so you have to edit /etc/pipewire/pipewire.conf and tell it to add "-e bluez5" when starting the session manager.
After that my headphones who show up as a device in pw-cli but not as a target I could send sound to.
The final straw though was that fast user switching seems to completely break it. I assume that the daemon doesn't release the audio device when you switch to a different desktop to something because once I started a second session things got horribly confused and I wound up with one desktop where audio worked and one where it didn't work at all.
Tom
On 2020-12-21 3:31 a.m., Tom Hughes via devel wrote:
On 20/11/2020 16:26, Ben Cotton wrote:
== Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
So I tried this in F33 with the packages from updates-testing and I'm afraid to say it didn't end well...
Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
As pactl was removed by the switch I couldn't test this.
pactl command is still present after replacing pulseaudio by pipewire-pulseaudio.
pactl info Server String: /run/user/1000/pulse/native Library Protocol Version: 34 Server Protocol Version: 34 Is Local: yes Client Index: 78 Tile Size: 65472 Server Name: PulseAudio (on PipeWire 0.3.18) Server Version: 14.0.0 Default Sample Specification: float32le 2ch 48000Hz Default Channel Map: front-left,front-right Default Sink: alsa_output.pci-0000:03:00.6.analog-stereo Default Source: alsa_input.pci-0000:03:00.6.analog-stereo Cookie: 5667:4fbd
- gnome-control-center: check the audio tab, check the volume sliders and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch.
This worked initially, but see later.
- pavucontrol: check volumes in the input devices tabs and check the microphone volumes
Didn't test this.
Worked fine.
- firefox: check out a website with audio/video such as youtube and verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111).
Didn't test this.
Works.
- rhythmbox: check if playback works as expected
This worked initially, but see later.
Works here.
- bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc.
I was unable to get this to work.
Works with Galaxy Buds+ as highlighted below:
pactl info Server String: /run/user/1000/pulse/native Library Protocol Version: 34 Server Protocol Version: 34 Is Local: yes Client Index: 97 Tile Size: 65472 Server Name: PulseAudio (on PipeWire 0.3.18) Server Version: 14.0.0 Default Sample Specification: float32le 2ch 48000Hz Default Channel Map: front-left,front-right Default Sink: api.bluez5.a2dp.sink.Galaxy Buds+ (11C1) Default Source: alsa_input.pci-0000:03:00.6.analog-stereo Cookie: 4766:6514
The first problem is that bluetooth is not actually enabled by default so you have to edit /etc/pipewire/pipewire.conf and tell it to add "-e bluez5" when starting the session manager.
Which version of pipewire was used on your system? Pipewire 0.3.18 enabled a bluetooth headphone i.e. Galaxy Buds+ with issue related to resuming for the reopened lid of a laptop. Workaround is with the command for terminal "systemctl --user restart pipewire.service pipewire-pulse.service". See attached pipewire.conf with include bleuz5 enabled by default.
After that my headphones who show up as a device in pw-cli but not as a target I could send sound to.
An example with Galaxy Buds+:
id 84, type PipeWire:Interface:Node/3 factory.id = "7" client.id = "31" device.id = "83" node.description = "Galaxy Buds+ (11C1)" node.name = "api.bluez5.a2dp.sink.Galaxy Buds+ (11C1)" media.class = "Audio/Sink" id 85, type PipeWire:Interface:Port/3 object.path = "Galaxy Buds+ (11C1):playback_0" format.dsp = "32 bit float mono audio" node.id = "84" audio.channel = "FL" port.name = "playback_FL" port.direction = "in" port.physical = "true" port.terminal = "true" port.alias = "Galaxy Buds+ (11C1):playback_FL" id 86, type PipeWire:Interface:Port/3 object.path = "Galaxy Buds+ (11C1):monitor_0" format.dsp = "32 bit float mono audio" node.id = "84" audio.channel = "FL" port.name = "monitor_FL" port.direction = "out" port.alias = "Galaxy Buds+ (11C1):monitor_FL" id 87, type PipeWire:Interface:Port/3 object.path = "Galaxy Buds+ (11C1):playback_1" format.dsp = "32 bit float mono audio" node.id = "84" audio.channel = "FR" port.name = "playback_FR" port.direction = "in" port.physical = "true" port.terminal = "true" port.alias = "Galaxy Buds+ (11C1):playback_FR" id 88, type PipeWire:Interface:Port/3 object.path = "Galaxy Buds+ (11C1):monitor_1" format.dsp = "32 bit float mono audio" node.id = "84" audio.channel = "FR" port.name = "monitor_FR" port.direction = "out" port.alias = "Galaxy Buds+ (11C1):monitor_FR"
The final straw though was that fast user switching seems to completely break it. I assume that the daemon doesn't release the audio device when you switch to a different desktop to something because once I started a second session things got horribly confused and I wound up with one desktop where audio worked and one where it didn't work at all.
No issue on my desktop running Rawhide. Maybe some issues are user error like using old version of pipewire. Update your system and make sure pipewire version is 0.3.18 whose pipewire-pulseaudio properly handle dependencies. Should you see Steam from RPM Fusion being removed, grab the latest version from their Koji page which fixes the problem.
On 27/12/2020 20:07, Luya Tshimbalanga wrote:
On 2020-12-21 3:31 a.m., Tom Hughes via devel wrote:
On 20/11/2020 16:26, Ben Cotton wrote:
<
- bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc.
I was unable to get this to work.
Works with Galaxy Buds+ as highlighted below:
I was trying it with Bose QC35 headphones.
The first problem is that bluetooth is not actually enabled by default so you have to edit /etc/pipewire/pipewire.conf and tell it to add "-e bluez5" when starting the session manager.
Which version of pipewire was used on your system? Pipewire 0.3.18 enabled a bluetooth headphone i.e. Galaxy Buds+ with issue related to resuming for the reopened lid of a laptop. Workaround is with the command for terminal "systemctl --user restart pipewire.service pipewire-pulse.service". See attached pipewire.conf with include bleuz5 enabled by default.
It was 0.3.18 and as I say it was showing up as a device but with no node that I could route audio to.
That configuration you attached still seems to be missing the extra "-e bluez5" on the pipewire-media-session line? or is the comment there wrong when it says that is required?
The final straw though was that fast user switching seems to completely break it. I assume that the daemon doesn't release the audio device when you switch to a different desktop to something because once I started a second session things got horribly confused and I wound up with one desktop where audio worked and one where it didn't work at all.
No issue on my desktop running Rawhide. Maybe some issues are user error like using old version of pipewire. Update your system and make sure pipewire version is 0.3.18 whose pipewire-pulseaudio properly handle dependencies. Should you see Steam from RPM Fusion being removed, grab the latest version from their Koji page which fixes the problem.
I don't use steam so it's nothing to do with that.
Tom
I was trying it with Bose QC35 headphones.
It was 0.3.18 and as I say it was showing up as a device but with no node that I could route audio to.
Maybe an extra step is required for that Bose QC35. Try to forget that device and reconnect.
That configuration you attached still seems to be missing the extra "-e bluez5" on the pipewire-media-session line? or is the comment there wrong when it says that is required?
I haven't needed to put "-e bluez5" as Galaxy Buds+ worked without extra configuration on a first try.
Luya
On 29/12/2020 01:41, Luya Tshimbalanga wrote:
I was trying it with Bose QC35 headphones.
It was 0.3.18 and as I say it was showing up as a device but with no node that I could route audio to.
Maybe an extra step is required for that Bose QC35. Try to forget that device and reconnect.
That configuration you attached still seems to be missing the extra "-e bluez5" on the pipewire-media-session line? or is the comment there wrong when it says that is required?
I haven't needed to put "-e bluez5" as Galaxy Buds+ worked without extra configuration on a first try.
I had another play with it and I can confirm that I now have bluetooth working - it does work out of the box but has a habit of switching back to the on board sound for new audio streams unless you add that "-e bluez5" argument.
What doesn't work at all, and this is likely what was causing my problems before, is fast user switching.
That doesn't work with traditional pulseaudio for bluetooth but you can work around that by disabling the bluetooth modules in .config/pulse/default.pa for all bar one user if you are happy only using bluetooth for a single user.
With pipewire not only does it not work for bluetooth, it doesn't work for the on board sound either - you have to stop the pipewire service for one user before switching to the other one or it can't use the sound card as the other instance still has it open.
I did try and use the (not shipped in Fedora) system service units for pipewire but I couldn't get them to work.
Tom
My experience is pretty OK with PipeWire in f33. Gaming also OK and seems like even fixed long standing issues in some games. Overall is better in terms of CPU utilization and quality (subjectively).
But one noticeable issue - no volume control in GNOME Shell, but it available in System Settings. There is also report about this in GNOME Flashback https://bugzilla.redhat.com/show_bug.cgi?id=1912062
Il giorno ven, 20/11/2020 alle 11.26 -0500, Ben Cotton ha scritto:
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default.
== Owner ==
- Name: [[User:Wtaymans| Wim Taymans]]
- Email: wim.taymans@gmail.com
== Detailed Description == Currently, all desktop audio is handled by the PulseAudio daemon. Applications make use of the PulseAudio client library to communicate with the PulseAudio daemon that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel (gnome-control-panel) both use the Pulseaudio client libraries to manage the volume and configuration of the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to the JACK server. This proposal will install a JACK client library replacement that talks directly to PipeWire. All existing PRO audio jack applications will then work on top of PipeWire.
For pro audio we should test very deeply with clients like ardour, audacity, rosegarden, hydrogen and so on. Pro audio is very sensible to latency and real time scheduling, and jack is very mature in handling these requirements. IMHO pipewire is too young to accomplish these tasks. I think this should be an opt-in or out and that jack should remain as an alternative to pipewire's jack module.
Ciao Guido
... snip
I switched a desktop F33 machine from pulseaudio to pipewire and it seems to work fine at a quick glance:
$ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing $ systemctl --user enable pipewire pipewire-pulse
Now I have the problem when I re-plug my headphones (old-fashioned headphone jack) that I don't see the headphones as output device via "pactl list sinks" (neither via pavucontrol, gnome's audio settings, ...).
However the low-level alsa tools can see the headphone jacks (e.g. "alsamixer") and I can use "aplay" to get sound output one the headphone jacks.
With pulseaudio I had the same situation but $ pacmd unload-module module-udev-detect && pacmd load-module module-udev-detect
fixed the situation for me (though I saw duplicated sinks via pulseaudio for the rest of the session).
-> Is there a way to force pipewire to rescan the available sinks? (Ideally there would be auto-detection of course)
I guess this is more a support question but I assumed that it might be on topic here as the main goal is to get some testing for pipewire in Fedora :-)
Felix
On 14/01/2021 11:45, Felix Schwarz wrote:
I switched a desktop F33 machine from pulseaudio to pipewire and it seems to work fine at a quick glance:
$ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing $ systemctl --user enable pipewire pipewire-pulse
Now I have the problem when I re-plug my headphones (old-fashioned headphone jack) that I don't see the headphones as output device via "pactl list sinks" (neither via pavucontrol, gnome's audio settings, ...).
There's an upstream ticket that may be related:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/533
Tom
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Alexander Bokovoy -
Andreas Tunek -
Andy Mender -
Anthony F McInerney -
Artem Tim -
Ben Cotton -
Brandon Nielsen -
Dan Čermák -
Dominique Martinet -
Dridi Boukelmoune -
Dylan M Taylor -
edmond pilon -
Erich Eickmeyer -
Felix Schwarz -
foss＠jwf.io -
Gargoyle -
Gary Buhrmaster -
Gergely Gombos -
Guido Aulisi -
J. Bruce Fields -
James Szinger -
Joël Krähemann -
Justin W. Flory
-
Kalev Lember -
Kevin Fenzi -
Leigh Scott -
Luya Tshimbalanga -
Lyes Saadi -
Marius Schwarz -
Mattia Verga -
Mauro Carvalho Chehab -
Michael Catanzaro -
Michel Alexandre Salim -
Naheem Zaffar -
Neal Gompa -
Panu Matilainen -
Ralf Corsepius -
Roberto Ragusa -
Simo Sorce -
Solomon Peachy -
stan -
Tom Hughes -
Tom Seewald -
Tomasz Torcz -
Tomáš Popela -
Vasiliy Tolstov -
Vitaly Zaitsev -
Vít Ondruch -
Wim Taymans -
Wim Taymans -
Zbigniew Jędrzejewski-Szmek