10 ms·
PipeWire 0.3.62
- jbirer 4y ago
- djoldman 4y agoHad no clue. https://pipewire.org/ https://pipewire.org/
- phkahler 4y agoLooks like video is getting a lot of work now.
- jelicicm 4y agoStumbled into PipeWire few months ago when trying to setup Bluetooth headset on Ubuntu OS. It's superior to PulseAudio, but... Really unbelievable to comprehend that Linux distros have such bad support for Bluetooth audio headsets - something very common in today's tech world. Android, Windows and Apple's OS all very efficiently switch from A2DP codec which is excellent for audio playback, but has no possibility for bidirectional communication (so you can't use your microphone) and HSP/HFP coded which provides worse sound, but you can talk. Linux doesn't have this fixed, there were some attempts [0], but nothing great came out of it. [0] https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1838151 https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/18...
- jchw 4y agoI'm actually confused; The past couple years, PulseAudio has been pretty good at switching between the two for me. Getting stuck in HSP isn't unique to Linux of course; it can happen if anything holds the mic open, there's reports of issues with both macOS and Windows too, for the same reason. Especially common with programs like Discord. PulseAudio absolutely supports it with the Bluetooth module's auto_switch feature. I guess I'm not sure if Pipewire supports it, but it's likely handled by whatever is doing session management. I can only assume it's possible to configure Wireplumber to handle it if it doesn't have native support for it yet.
- jelicicm 4y agoHm, not really sure about `auto_switch`, didn't dig deep enough to find it I guess. PulseAudio only offered HSF/HSP which sounded simply terrible. PipeWire's HSP sounds pretty good (mSBC codec), although it's still obviously worse than A2DP. I'll have to look into auto switching and how to enable on either system.
- jchw 4y agoAre you saying that in pavucontrol, you see no A2DP modes at all? That's very strange, since all Bluetooth certified stuff should at least support A2DP SBC mode. Out of the box, Pipewire should also be able to support LDAC and maybe AptX. PulseAudio can use Gstreamer to support additional codecs, so on PulseAudio with GStreamer 1.20+ you can get better A2DP coverage, assuming you have the right codec packages installed on your distro. In general, Linux Bluetooth support has been a lot better as of late, to the point where I didn't need to mess with much, so most of what I know about it is actually older. (I used to use a third-party PulseAudio module to get better A2DP support for example, but when I looked it up, I found that it was deprecated in favor of just using newer GStreamer.)
- vladvasiliu 4y agojelicicm mentioned ubuntu in the original comment. I seem to remember that as of Ubuntu 20.04, LDAC wasn't supported. I needed to jump through some hoops to get it to work. It was still using full-on pulseaudio, not pipewire, at the time. I wouldn't be surprised for it to still not support non-free codecs out of the box. I've indeed had no issues on my Arch install. Works perfectly with LDAC on my Sony headphones and aptx-hd on my Shure. The mic of the Sony is a bad joke so I never use it, but I've tried it and switching modes worked fine on Linux.
- jchw 4y agoI hear you on that one. I'm patiently awaiting end-to-end support for LE audio with bidirectional audio streams, and maybe, if we're really lucky, Sony will release a pair of headphones that has a better microphone to go with it.
- viraptor 4y agoNot sure if this is what you were pointing out here, so just in case: Pipewire does allow you to switch BT codecs including the ones which do better bidi quality. Including autoswitching if you want it to happen automatically https://wiki.archlinux.org/title/PipeWire#Automatic_profile_selection https://wiki.archlinux.org/title/PipeWire#Automatic_profile_... (you can switch manually as well)
- thewataccount 4y agoI've personally had a smoother experience on KDE with PipeWire because it seems to switch quicker for my headphones automatically, and worst case I can just right click it in the bottom right and select the correct codec. On Mac OS X however with the same headset, there's no manual switching, and I have to try to "coax" it into switching back by playing media like Spotify and it's not super consistent. Granted I only switch accidentally when I accidentally have my headphones selected as the audio source.
- sph 4y agoAre you complaining that Linux can't handle Bluetooth because PulseAudio breaks your setup, on a Pipewire post? Use Pipewire then. As other have said, this is not a problem anymore with the recommended setup of Pipewire + WirePlumber.
- spion 4y agoWhat is really unbelieveable is that Bluetooth still cannot do high quality full duplex streams in 2022, and that anyone that wants to use wireless has to accept sounding like a telephone line / old radio from the early 90ties in meetings.
- worthless-trash 4y agoWhen I ask sales people "does their bluetooth headset actually do high quality full duplex streams" they give me the strangest look. I am glad to see that I'm not the only one asking for this, i feel like i'm taking crazy pills.
- trifurcate 4y agoMy personal experience is the opposite-- although this behavior perhaps isn't desirable for end users who don't want to fiddle with their codec selection, being able to switch between A2DP and HSP manually in pavucontrol provides me with a much superior experience compared to Windows which would a) keep my headset in HSP because of some rogue application with a stuck open mic and make it really difficult to track it down/undo it and b) (rarely) keep my headset in A2DP while an application is attempting to grab audio or switch it to A2DP in the middle of meetings and break everything until I restart the application trying to use my mic. In my experience, a manual codec switch is a much smoother experience, ironically.
- esaym 4y agoWideband (mSBC) support was added into Pulseaudio 15 btw: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/15.0/#supportforhfpbluetoothprofiles https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1... It also added support for using higher bitpools for the SBC codec (sbc, sbc_xq_453, sbc_xq_512, sbc_xq_552) which pushes its quality above APTx and the other proprietary codecs. Info about bitpools and SBC here: https://habr.com/en/post/456182/ https://habr.com/en/post/456182/
- jeppesen-io 4y agoWhen using recent packages (e.g. NixOS) it's become quite good in the last ~6-ish months. It switches automatically when I open zoom, which is very nice
- LinAGKar 4y agoWhy post some random point release?
- nerdponx 4y agoFree karma? People like to talk about stuff that they like to talk about, so post a thread about stuff people like to talk about.
- screamingninja 4y agoI ask that "why post X" question often, but that leads to "why upvote X", which answers it. Enough people find it interesting enough to discuss that it's found its way to front page!
- ElijahLynn 4y agoGood question. More context would be good.
- lionkor 4y agoI use PipeWire on my desktop and laptop, and its doing a better job than pulse ever did. That said, I've had daily issues with it, from it slowing video playback (weirdly, by about 10 seconds over 20 minutes or so, only noticable when watching something synchronized with someone else), over crackling noises with speakers when no audio is playing, to straight up lags and skips every few seconds with certain devices. Audio on linux is a complete joke, and I'm glad pipewire is there to tackle it.
- CarVac 4y agoI've experienced that same lack of synchronization with other people.
- sph 4y agoIf you haven't, post an issue on the Pipewire repo. I've found that the main author, Wim Taymans, is very proactive in fixing any issue if they're reproducible. I've opened two bugs, and two times he fixed them personally in less than a week, which is incredible for an open source project of that size.
- CameronNemo 4y agoI've had the same experience. Had a couple issues and they ended up fixed in the next version.
- mort96 4y agoVideo playback timing is actually pretty difficult, with only trade-offs, no "right" solution. The easiest solution is to use your computer's accurate clock to time the frames. This means, if your video is at 30 FPS, you will have gone through exactly 3000 frames after 100 seconds. But your monitor might not be refreshing at exactly 60 FPS, it might be targetting the 59.94 standard, or it might be targetting 60 FPS but with a clock that's a bit less accurate than your computer's, so every now and then, you get a stutter as a video frame has to shown for 1 refresh interval longer or shorter than it should. What we could do instead is to calculate a fixed pattern to display frames. If your monitor is 30Hz and the video is 30 FPS, we show exactly one video frame for every monitor refresh. If your monitor is 60Hz and the video is 30 FPS, show each video frame for 2 monitor refreshes. If the monitor is 30Hz and the video is 60 FPS, skip every other video frame. This will already introduce some deviation from the "ideal" timing if your display clock isn't super accurate. And if the monitor is 59.94Hz, that's probably close enough to 60 that we want to show each frame of 30 FPS video exactly twice, but that means the video is playing at 99.9% of its intended speed. 10 seconds over 20 minutes is a surprisingly big gap though. Playing every frame of 30 FPS video twice on a 59.94Hz monitor would net a 1.2 second deviation over 20 minutes. EDIT: Why the downvotes? Everything here is correct according to my understanding of the situation after implementing video playback software and working with other people's. If anything is wrong, please correct me, don't just silently downvote.
- sylware 4y agoI was expecting pipewire to provide a pulseaudio ABI compatibility without the cost of the pulseaudio SDK(glib), that for 1 steam game. Well, it pulls glib into the SDK too. I forgot about that game, and I am back on my good friend alsa. The software mixer (dmix/pulseaudio/pipewire/jack/whatever) is hidden behind the alsa API.
- _8j50 4y agoOh this thing, and of course it is amazing and popular. But removing it caused so much pain, it's like pulseaudio and asahi all over again. My gripe is desktop developers and maintainers have this mindset that "users need this stuff, even if they don't want it we will make sure they have it and things will break otherwise". My wish/hope is for stable/well supported distros like debian to have good support for "minimal" versions of popular DEs.
- codedokode 4y agoKnowledgeable people, please explain. Wouldn't it be better if applications used ALSA for audio output? In this case they could work without Pulseaudio and with (because Pulseaudio adds a sink to ALSA). This way the application doesn't need to know which audio daemon it uses. What are the downsides of this approach?
- throw903290 4y agoI use pure Alsa on virtual machines. Image is stripped down so much it barely runs XServer. Another reason is future proofing. PipeWire is yet another audio protocol, and may not be around in 5 or 10 years. Not everything has PipeWire. Some flavours of linux has support for 10 years. Even some of my desktop boxes still use Pulseaudio. And finally what PipeWire actually offers? If you need to dump audio into output, ALSA seems sufficient.
- dlundqvist 4y agoFrom what I've read PW's official stance is to keep using the existing protocols such as PA and JACK. PW comes with a PA-compatible server, replacement JACK client libraries and an ALSA plugin. So it supports clients from all three at the same time. Precisely so software does not need to be rewritten (I imagine).
- wtay 4y agoPeople like to use the pulseaudio API because it has features people want, compares to ALSA or JACK: See here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#should-i-uninstall-everything-pulseaudio https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
- aidenn0 4y agoOnly slightly OT; does anyone have a solution for playing audio from ssh? The best I have so far is to pick a program that I know is under X (here xterm) and run something like: eval "env $(cat /proc/"$(pgrep -n xterm)"/environ |xargs -0 -n1 printf '%q ') bash" To get the environment setup right.
- jraph 4y ago(edit: I might have misunderstood your comment, but see my edit at the end) If you use PulseAudio or pipewire-pulse on your local computer and that both computers are on the same network (or at least the machine you ssh into can access your local machine, possibly through a tunnel - PulseAudio listen to port 4713 by default), you can set the PULSE_SERVER environment variable. PULSE_SERVER=X.X.X.X whatever_should_play_a_sound Where X.X.X.X is the domain or IP of your local machine. Your local machine needs to be configured to allow remote computers to play sound locally (by loading module module-native-protocol-tcp as far as I know - a papref setting is available for PulseAudio). If the computer you ssh into has Pulseaudio or pipewire-pulse, on your local machine you can run: PULSE_SERVER=Y.Y.Y.Y pavucontrol Where Y.Y.Y.Y is your ssh server, and set the default output sink to your local computer's. Then it will play things through your local computer. You need to setup your local computer so it advertises its PulseAudio service, and your server needs to have the module-zeroconf-discover module loaded. You can load a module with pactl (for both PulseAudio or pipewire-pulse): pactl load-module module-zeroconf-discover pactl load-module module-native-protocol-tcp listen=0.0.0.0 edit: and if you just want to play something on your remote machine, then `PULSE_SERVER=localhost` can work. export $(dbus-launch) instead of your command possibly works too. With Pipewire on Debian I noticed it works out of the box though.
- aidenn0 4y agoYou are misunderstanding; I want to play audio on the remote machine, not on the local machine. The remote machine is running pipewire-pulse.
- deleted 4y ago[deleted]