0.3.16 pulse replacement
For the pulse-dropin-replacement to work, you probably also need to clear your users config,
~/.config/pulse (like in delete/move the content) - That is created by pulseaudio for pulseaudio.
Otherwise the server could be unable to start.
I just installed the pulse replacement and while everything seems to be working just fine, the only problem is gnome-shell doesn't seem to be able to see the pipewrire pulse server, thus the volume control in the top right system menu is absent and keyboard media keys for volume don't work either. I think this should be addressed in the troubleshooting section with a solution if there is one.
Interestingly enough gnome-control-center is able to control the volume as well as other typical pulseaudio parameters.
killall pipewire-pulse; killall pipewire restarts the pipewire pulse daemon and makes the volume control in gnome-shell work as expected. This of course is a workaround and not a proper solution.
UPDATE 2: the above makes the volume control menu item and shortcuts appear, but adjusting the volume does nothing.
- I don't see volume indicator in gnome-shell/wayland but I'm able to control volume with media keys. -- Svito (talk) 15:55, 3 December 2020 (UTC)
- Possibly related: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/426 Hexchain (talk) 18:05, 3 December 2020 (UTC)
- Solved, refer to the latest change I made in the main page, found the solution thanks to Hexchain's link. -- GabMus (talk) 19:55, 4 December 2020 (UTC)
Does `pipewire` support low latency/high quality bluetooth codecs (aptX, LDAC, ...) ? along the lines of https://aur.archlinux.org/packages/pulseaudio-modules-bt-git/ If yes, how to configure it? along the lines of https://freedesktop.org/software/pulseaudio/pavucontrol/ nTia89 (talk) 21:23, 3 December 2020 (UTC)
- I switched to PipeWire and currently bluetooth sound poorly works: high latency and low quality.
- Actually open bug/enhancement in pipewire bugtracker .
- nTia89 (talk) 10:20, 5 December 2020 (UTC)
- It does now but currently there is no way to select a codec manually. It uses (the first supported?) codec in this order: LDAC, AptX HD, AptX, SBC. You can check for the current codec with
pactl list sinksIIRC.
- Hexchain (talk) 00:41, 21 December 2020 (UTC)
Right now I think the description is missing some content to exactly explain what pipewire is and what it can be used for. The website names some important examples imho:
- Capture and playback of audio and video with minimal latency.
- Real-time Multimedia processing on audio and video.
- Multiprocess architecture to let applications share multimedia content.
- Seamless support for PulseAudio, JACK, ALSA and GStreamer applications.
- I fully agree! TBH I don't see an urgent need for a discussion on this topic. Feel free to amend the page with whatever you think is right. -- Edh (talk) 19:30, 3 March 2021 (UTC)
Move section "webrtc screen sharing" below other sections in "Usage"
I think that the "Audio" and "Video" sections are more important and more general, so they should be placed first.
- IMHO the ordering is just fine as of now. Pipewire is completely optional for handling audio and video. However, for screensharing under wayland you must use it. I strongly believe that this section is of most interest to the average user. Note, I am fine though with whatever reaches a consensus. I do not feel too strongly about the ordering of these sections. -- Edh (talk) 19:28, 3 March 2021 (UTC)
0.3.23 no pcm devices found
Thanks nTia89 for reverting my change. pipewire-alsa isn't needed, I checked contents of the package, it definitely can't help.
Spent 5h on pipewire, it did not find any sound-card. The moment I installed pipewire-alsa it started working. I used
pw-cli ls | grep -i pcm to find pcm devices. I didn't change any config the whole time, because the wiki-page says it should work out of the box. I rebooted a lot. I hoped I could help that other users don't have to spend 5h on this. pipewire seems very nice. So here is what I did in the end.
pipewire pipewire-media-session pipewire-alsa pipewire-jack pipewire-pulse pipewire-jack-dropin(ignore jack if you don't have jack-applications)
systemctl --user enable pipewire.socket pipewire-pulse.service pipewire-media-session.service
systemctl --user restart pipewire.service pipewire-pulse.service pipewire-media-session.service
I try to find out what exactly my mistake was.
Native pulse clients can't connect
pipewire-pulse-dropin (AUR) has existed until Nov 2020. If still installed, it shadows and conflicts the socket
/run/user/*/pulse/native which is now already provided by
pipewire-pulse.service. Delete that orphaned package to solve this issue. Sausix (talk) 15:10, 30 March 2021 (UTC)
I think we have to mention the official wiki page: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Configuration#set-global-sample-rate because it is a complete and always up-to-date resource.
I think we should add a Configuration section; a sort of:
`PipeWire is a powerful tool having a plethora of options. We recommend to read the official wiki page in order to have a complete sight of all possibilities. Although most users are happy with default settings, particular configuration cases are reported in the Pipewire/Examples page. On the other hand, most common issues and their solutions are reported below in the Troubleshooting section.`
What do you think?
- I fully agree with you about mentioning the official wiki page. However, I think it is fine to recap some of the most important configuration options in the ArchWiki too! At least to me the current phrasing of the paragraph suggests that we solely refer to the official wiki page for that. -- Edh (talk) 11:03, 27 March 2021 (UTC)
video production ready?
The video section currently claims that:
> Although the software [video in PipeWire] is not yet production-ready, it is safe to play around with.
(emphasis mine). What's the source for the claim? The PipeWire (PW) FAQ basically says "It [PW] is ready for broader use", so I wonder where that dissonance comes from. --Anarcat (talk) 18:45, 6 May 2021 (UTC)
Elaborate on the expectations/requirements of the jack/jack2 removal option
The page currently suggests removing jack/jack2 from your system as an alternative to running through `pw-jack` or installingAUR to have the system use PipeWire for JACK but this is most likely blocked by a lot of software unless you've installed said software on your system without involving `pacman` and thus not having the transaction blocked, or you would need to force the removal (and IgnorePkg it to prevent it from returning) or maybe NoExtract jack's *.so files? The way it is suggested makes it sound like it should be a very easy `pacman -Rns jack/jack2` which it more than likely will not be.
Examples of programs that would block a simple/normal removal as suggested are blender and ffmpeg looking for 'jack', or things like qemu and fluidsynth looking for 'libjack.so=0-64'.
Maybe this section should have a note about that or maybe it's better to remove that whole suggestion as an option?