[HN Gopher] PipeWire: A server for Linux audio and video streams
___________________________________________________________________
PipeWire: A server for Linux audio and video streams
Author : sandebert
Score : 324 points
Date : 2021-09-11 07:31 UTC (1 days ago)
(HTM) web link (pipewire.org)
(TXT) w3m dump (pipewire.org)
| jagger27 wrote:
| I find it beautiful that the LDAC codec used with Sony wireless
| Bluetooth headphones only works on Linux through PipeWire. macOS
| is stuck with AAC, and Windows gets aptX. Linux gets all of them.
|
| Who do I thank for making this Just Work?
| SSLy wrote:
| Probably EHfive for their pioneering work on integrating those
| into PA/bluez https://github.com/EHfive/pulseaudio-modules-bt
| 2OEH8eoCRo0 wrote:
| Podman + Pipewire (and soon Wireplumber), two things to love
| about Fedora.
| WD-42 wrote:
| The migration to Pipewire has already begun. It is the default
| option in Arch, at least if you use the new arch-install script.
| figomore wrote:
| It's the default at Fedora too. I've been using it at NixOS
| without any problem.
| bananaoomarang wrote:
| Switched to pipewire last year at some point and it has been
| remarkably pain free.
|
| Bluetooth support seems more robust (no more weird 'have to
| reboot my computer to connect to these headphones for some
| reason') but the real headline feature is I no longer have to
| screw around to get pulseaudio and jack to coexist peacefully
| (nigh on impossible in my experience)
| marcodiego wrote:
| Wanted to try debian 11 last weekend. First time I installed it
| from debootstrap. I plugged in a 1TB SSD on an USB 2.0 to SATA
| case, formatted it, prepared the root filesystem with
| debootstrap, chrooted to it, installed a bunch of packages, setup
| locale and timezone, installed linux-image, grub and booted it.
| Worked flawlessly.
|
| Tried a "ps|aux" and discovered it is already running wayland and
| pipewire. Works so well it is boring. Nice!
| Venn1 wrote:
| PipeWire is a fantastic bit of software and it's great on the
| desktop. I would play around with it in the studio but it lacks a
| netjack2 equivalent. zita-n2j is not a replacement since it
| requires the client to have audio hardware.
|
| I'll stick with Jack2 + Netjack2 in the studio until that gets
| sorted.
| bryanmikaelian wrote:
| PipeWire was the only way I could get AirPod Pros to work in
| headset mode.
|
| With pulseaudio, it was rabbit hole after rabbit hole only to
| find a solution that ended up not working.
|
| I switched a few weeks ago and haven't looked back.
| josteink wrote:
| I'd love to try it out, but for the time being I'm running Ubuntu
| (for work needs) and there doesn't seem to be any trivial/non-
| invasive ways to get PipeWire to run on a regular Ubuntu desktop
| install.
|
| Maybe it makes it to next LTS as an apt-gettable option? I'll
| keep my hopes up :)
| jabl wrote:
| Last I checked, they are seriously investigating switching to
| pipewire for the upcoming 21.10 release.
| jeroenhd wrote:
| I don't know about any LTS versions, but 21.04 has pipewire in
| the standard repo. I expect PW to be in the 22.04 LTS based on
| that, but I don't expect it to be the default any time soon.
|
| This PPA [0] works fine for me in 21.04 to get the latest
| version. Support for the PPA seems to go back to Bionic, so you
| should be able to use it on recent LTS versions of Ubuntu as
| well.
|
| The only annoying part of the whole process is that the
| migration requires running a bunch of commands to stop and mask
| PulseAudio and to enable pipewire. This guide [1] worked great
| for me.
|
| [0]: https://launchpad.net/~pipewire-
| debian/+archive/ubuntu/pipew...
|
| [1]: https://ubuntuhandbook.org/index.php/2021/05/enable-
| pipewire...
| marcodiego wrote:
| Ubuntu has been burned by adopting pulseaudio too early. I've
| had many problems in 2008 and still have some today. They will
| probably be more conservative when switching this time.
| squarefoot wrote:
| Patiently waiting for Linux to have one audio server that will
| offer compatibility to all previous ones (that is, all software
| requiring other audio systems such as oss, alsa, PA, Jack, etc.
| will be handled gracefully _without installing them_ ) while
| encouraging direct support for new apps, then slowly phasing them
| out until we have a consistent, possibly layered, low latency
| audio stack that scales from small single board computers to full
| sized audio workstations. Choice is a good thing, but too much of
| it can have negative effects by slowing development and porting
| down (see window/desktop managers).
| Ericson2314 wrote:
| To be a bit more on the nose than the other replies? Did you
| read past the headline at all?
|
| This is perhaps one of the _best_ examples of not just making a
| new standard, but making one implementation to rule them all
| and implementing all the competing standards.
|
| > Patiently waiting for Linux to have one audio server that
| will offer compatibility to all previous ones
|
| That's PipeWire!
|
| > then slowly phasing them out until we have a consistent,
| possibly layered, low latency audio stack that scales from
| small single board computers to full sized audio workstations.
|
| Does PipeWire have its own interface for applications yet? I
| haven't heard of it if so. That's good; let everything maranate
| for a while before trying to design the "one, true interface".
| ptx wrote:
| Interestingly, FreeBSD and Linux both started with the same
| audio stack (OSS) and both rewrote it twice[1], but FreeBSD has
| kept the original OSS API while adding essentially the same
| features, it seems.
|
| The big selling-point of ALSA, from what I remember, was that
| OSS couldn't provide mixing to support multiple applications -
| but FreeBSD's OSS does that. Some of the main selling-points of
| PulseAudio are per-application volume, low latency and high-
| quality resampling, all of which FreeBSD's OSS claims to do as
| well.
|
| [1] https://wiki.freebsd.org/Sound
| boudin wrote:
| Pipewire is implementing Alsa, Pulse Audio and Jack already. I
| don't think alsa is going away but I can see Pulse Audio and
| Jack being replaced by it quite quickly.
| spijdar wrote:
| I don't think ALSA and Pipewire fill the same niche anyway? I
| was under the impression ALSA was an API for directly talking
| to the audio devices, which would be used by Pipewire or
| Pulseaudio or that in-house solution ChromeOS uses, or
| whichever flavor of mixer.
|
| End-user applications talking directly to ALSA will probably
| become more uncommon, though.
|
| Edit: Yeah, the PipeWire FAQ confirms this https://gitlab.fre
| edesktop.org/pipewire/pipewire/-/wikis/FAQ...
| jabl wrote:
| Pipewire indeed doesn't replace ALSA, but it provides the
| ALSA API, allowing applications coded against the ALSA API
| to use pipewire.
| eredengrin wrote:
| Ah this is very cool to hear, thanks for the
| clarification.
| [deleted]
| kevincox wrote:
| PipeWire is aiming, and positioned to be this service. I don't
| have a particular case for low-latency audio so I can't comment
| on that but it is amazing that you can use pavucontrol to tweak
| your device configuration and volumes then use qjackctl to wire
| the devices however you want. I'm impressed at how well it
| works and it even supports better bluetooth codecs than
| pulseaudio does.
|
| It has already shipped by default in Fedora and is available in
| Arch and NixOS. It does look like it will quickly wipe out
| PulseAudio by default. I'm sure Jack and ALSA will hang in
| there longer but they are already used much more rarely (by
| users, the ALSA API will stick around for decades more I'm
| sure).
| pshirshov wrote:
| Out of curiosity: I believe that pipewire was supposed to solve
| the remote desktop problem for wayland. I mean real RDP, not VNC.
|
| What's the situation with RDP on wayland?
| stncls wrote:
| For the last ~12 years, I gave PulseAudio a try every time I
| upgraded the Fedora distro on my main computers. I almost never
| had the catastrophic bugs many people complained about. But
| pulseaudio has always taken 10-15% of one CPU when in use (be it
| on audio/video calls, or music/movie playback). This is across 3
| different laptops and 2 desktops. It is not a huge deal, but it
| is a bit frustrating on laptops where battery life is precious. I
| understand that PulseAudio is very powerful, but it represented
| no practical gain for me personally, with my very simple use
| cases, so I simply disabled it.
|
| Weirdly, I found very few people complaining about PulseAudio's
| CPU usage. Maybe nobody cares about 10-15% of one core.
|
| However, I am happy to report that PipeWire seems to not have
| this problem at all. Since it became default on Fedora, it has
| barely shown on top's first page. Given that it is even more
| ambitious than PulseAudio in terms of latency, this is incredibly
| impressive!
| timvisee wrote:
| Yes! I experienced the same. Just never publicly complained
| about it. It's the only constant running thing having high CPU.
| PipeWire, though still somewhat power hungry, is a lot better.
| lostdog wrote:
| Similar thing for me. Pulseaudio sometimes takes a bunch of CPU
| with audio playing.
|
| Even stranger, sometimes it keeps taking 5-10% CPU with no
| audio playing. (I think it is related to running out of memory
| for a moment and using swap, but no matter how much memory I
| free up, the computer never returns to normal and must be
| restarted).
|
| I'm getting to the point of installing debug symbols and
| pointing perf at it, but dropping pulseaudio would be an even
| better solution.
| marcodiego wrote:
| Pulseaudio eating too much CPU happens on an Ubuntu machine of
| mine. I simply type "pulseaudio -k" to restart it. But this
| kind of action should not be needed, I'm the user, I'm not
| supposed to fight the system, the OS should work for me not the
| other way around.
| beebeepka wrote:
| I've got music during my gaming sessions on Ubuntu. Never
| seen this happen. Will keep an eye.
|
| I'll probably get downvoted again but what hardware?
| marcodiego wrote:
| And old Dell machine.
| earthbee wrote:
| Are there any particular circumstance where it takes 10-15% of
| one CPU for you or is it whenever there is sound playing? I
| just checked mine while playing music on YouTube and it bounces
| between 4.0 and 4.8%
| stncls wrote:
| Whenever there is sound playing or recording. I think it was
| lower than 10-15% on my most recent desktop, so maybe 4-5%
| makes sense if your computer is powerful. (While I fully
| appreciate that it is a very minor annoyance, 5% still
| frustrates me because PulseAudio added no value to me. I also
| understand that it added features very useful to other
| people.)
| stncls wrote:
| Note that PipeWire was initiated by Wim Taymans, one of the
| driving forces behind GStreamer. I think it is one case of the
| right people in charge of the right projects :-).
| beebeepka wrote:
| What kind of hardware are we talking about? 15% for music
| playback is a lot
| andrewaylett wrote:
| One time, many moons ago now, I noticed Pulse taking a
| reasonable fraction of a core and thought I'd zap PA to try to
| use less CPU.
|
| Unfortunately, using my media player _without_ PA actually used
| _more_ CPU overall -- the audio player 's CPU use went up by
| more than PA had been using. So I went back to using PA.
| kfajdsl wrote:
| I switched over from pulseaudio to pipewire last week, and I can
| say it just works (tm), which is the highest praise I can give
| something like this as a non-power-user.
| peakaboo wrote:
| I also did, because pulseaudio was giving me weird sound issues
| (although they are probably because of Bluetooth to be honest).
|
| But I found out about pulsewire and after switching, it just
| works, so... Plan on keeping using it.
| xrd wrote:
| As others have commented, the documentation is not there yet.
| I've never had good experiences trying to switch from pulse to
| pipe.
|
| It sounds like some distros are using as the starting point for
| new installs, like Arch.
|
| Is this the best way, to just install a new distro from scratch.
| I just don't want to try to hack a bunch of configuration files
| from pulse.
|
| If so, what's the best distro offering pipewire. It seems like a
| revolutionary change and I'm excited to use it.
| vbezhenar wrote:
| Fedora uses pipewire. Try LiveCD image.
| mixmastamyk wrote:
| I tried to hook up a midi keyboard to a raspberry pi, for my kid
| to practice piano but it didn't work well. Was Ubuntu Mate with
| timidity soft synth. Latency was about half a second from key
| press to sound which made it unplayable. Not sure what else could
| be done but hopefully this project is a solution.
| PaulDavisThe1st wrote:
| I use an RPi4 for a high end self-built e-piano (StudioLogic
| weighted key controller, Pianoteq for synthesis, ART monitors,
| HifiBerry pro-audio DAC). Latency is fine, but you won't get
| the same results with stock Ubuntu Mate. The "solutions" don't
| involve Pipewire per se, although in the future that might be
| the technology in use.
| cjaybo wrote:
| I haven't tried it but you might look into AVLinux, it's
| supposed to be more real-time performance friendly.
| ta988 wrote:
| it could be yes, but there are a lot of variables to take into
| account here. what audio system were you using what were the
| settings.
| mixmastamyk wrote:
| Whatever is standard with ubuntu, pulse audio with defaults I
| believe. At some point I installed jack but it didnt seem to
| help. I gave up as several hours were all I had to spare. :-/
| OJFord wrote:
| I've found the AV sync considerably off watching Youtube videos
| in Firefox with Bluetooth earphones (not tried other
| combinations) since switching to Pipewire. It's not something I
| do enough that I was bothered to switch back to Pulseaudio, and
| haven't really dug into it yet.
|
| But while it's mentioned here.. anyone else have that, or know
| what it might be?
| EvanDotPro wrote:
| I use Bluetooth ear buds (OnePlus Buds) daily on Fedora with
| Pipewire and haven't noticed any perceivable sync issues
| myself.
|
| Edit: Other comments are mentioning codec selection for
| Bluetooth in relation to lag/sync issues. I'm using whatever is
| default on Fedora 34. I've never looked and am not at my
| computer to check right now unfortunately.
| mr_sturd wrote:
| I moved from PulseAudio to SnapCast for streaming audio over my
| local network as it was easier to configure multiple sinks for
| multi-room audio.
|
| It looks as though there is support for similar with PipeWire,
| with the _ROC sink_ and _ROC source_ modules[0][1]. I 'm going to
| have to set aside some time to have a poke around with this and
| see how it performs.
|
| [0] - https://docs.pipewire.org/page_module_roc_sink.html
|
| [1] - https://docs.pipewire.org/page_module_roc_source.html
| mlang23 wrote:
| PulseAudio was and is the disaster that the LAD community has
| already predicted. Whenever a package manager forced it onto me,
| I had to figure out how to get rid of it again. Hopefully PieWire
| will improve things.
| jeroenhd wrote:
| In my experience, the Manjaro and Ubuntu package managers make
| the PipeWire packages "provide" the necessary PulseAudio
| metapackages to avoid dependency issues. I guess that means
| even if you don't plan to switch, installing PipeWire right now
| may help you prevent your package manager from installing Pulse
| as a dependency.
| EvanDotPro wrote:
| Long time daily Fedora user here. PipeWire is what we've needed
| for so long in terms of audio, not to mention more recently in
| terms of screen capture with Wayland.
|
| The only issue I've run into is that for some apps (Zoom,
| Firefox, Chrome) which are set to use my "default audio device"
| for input or output, it selects the correct device initially, but
| if I change the default/system device (via gnome sound settings)
| later while it's in use, most (all?) of the time, the application
| continues using whatever device was selected initially.
|
| I haven't bothered to debug or see if this is a known issue as it
| hasn't bothered me much since most apps allow switching to
| explicit input/output devices which works fine. I believe (but
| haven't definitively confirmed) that changes via pavucontrol also
| work, so perhaps it's something with the gnome sound settings?
|
| Anyway, huge thanks to the devs who put their time, effort,
| experience, and talent into making PipeWire happen. It's a huge
| step forward on multiple fronts
| dralley wrote:
| They have one of the best / most comprehensive FAQs I've ever
| seen.
|
| https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ
| satyanash wrote:
| the transition from pulseaudio -> pipewire was pretty matter-of-
| fact. A great example of things done right.
| vyskocilm wrote:
| An another amazing feature of Pipewire is that it made desktop
| sharing under Wayland possible. Really awesome piece of a
| software.
| lom wrote:
| When I first tried it a year ago, it worked for some time until
| some update that broke my headphones. Half a year ago, when I
| installed another distro I gave it another shot and it worked
| OOTB. But unfortunately a month ago my headphones stopped
| working. But they still/always worked in pulseaudio. There seem
| to be a few issues with my symptoms, yet the maintainers haven't
| fixed the regression yet... Until then I'll be having to use
| pulse
| lambdaba wrote:
| PipeWire completely removed lag on bluetooth audio for me, which
| was a nice unexpected surprise.
| davidandgoliath wrote:
| I'm in regardless (being I use fedora), but this cements it if
| that's the case.
| jeroenhd wrote:
| I don't have that experience (using AAC, that is), but I do
| enjoy being able to select the Bluetooth audio codec with
| Pipewire (SBC, AAC, SBC-XQ, mSBC, etc.).
|
| The array of supported and configurable Bluetooth codecs are
| the reason I switched. Now I can use AAC for music, SBC-XQ for
| video and interactive content and switch to mSBC when I need to
| make a call, all from the user interface.
| ta988 wrote:
| I've replaced jack by pipewire for all my audio work. It works
| pretty well, still a few xruns occasionally but it has been
| really transparent with pw-jack and reduced a lot the various
| crashes I would see with jackthat would kick all the clients from
| time to time.
| commoner wrote:
| PipeWire is how audio should be on Linux, and it's ready to use.
| No more complications between PulseAudio, ALSA, and JACK.
| PipeWire implements all 3 of these interfaces, which means you
| can use applications that depend on any or all of these
| interfaces simultaneously with no conflicts. Playing a video in
| Firefox and a track in a digital audio workstation at the same
| time works with no special configuration. PipeWire makes audio on
| Linux as easy as it is on other OSes.
|
| The Arch Wiki page describes some of the use cases for PipeWire:
| https://wiki.archlinux.org/title/PipeWire
| marcodiego wrote:
| It is a shame it took so long but it is finally here. The
| feeling may be similar to when pulseaudio arrived, but it is
| not the same thing; Pipewire implements everything that is
| needed; users will no longer need to care about handoff between
| alsa, pulseaudio and jack. It manages video streams too and the
| latest version of OBS even makes use of it to allow screen
| sharing on wayland running from flatpak. Finally!
|
| I've been watching linux since the OSS days. I used oss, alsa,
| arts, esd, jack, pulseaudio... never it has been looking as
| well aimed as it is this time. Finally!
| [deleted]
| AshamedCaptain wrote:
| I used to criticize PulseAudio a lot because for a time it was
| growing too much, acquiring way too many responsabilities,
| which would eventually make it one of those programs that is
| "way too hard to replace" in the Linux Desktop world, so we
| would get stuck with it for a time.
|
| I am glad to have been proven wrong. I was extremely surprised
| at the progress PipeWire made in a couple short years. I have
| been barely able to find any issues even after a couple of
| months of using it. In comparison, I filed a dozen PulseAudio
| bugs (some of them with patches, never applied) before I just
| gave up...
| odiroot wrote:
| From Pro Audio perspective, it's even easier than on Windows.
| Not sure about Mac OS, never tried it.
| PaulDavisThe1st wrote:
| It's not quite as easy as on macOS, but then again, macOS
| doesn't offer interapplication audio routing (the "JACK part
| of Pipewire"), so the comparison is not entirely fair. Pretty
| close though.
| cpuguy83 wrote:
| There's a low-latency, free/OSS driver to do this.
|
| MacOS is a little confusing with it because you have to
| configure it in the MIDI setup utility, but it works very
| well.
|
| Not to mention commercial product from Rogue Amoeba which
| is fantastic.
| cpuguy83 wrote:
| And now I feel like an idiot for posting this having read
| who you are
| nitrogen wrote:
| It does help the rest of us though. I'll also mention for
| the same reason that there was a thing called ReWire on
| Windows, not sure what became of it.
| PaulDavisThe1st wrote:
| Rewire is fairly different. It still exists, and also
| existed for macOS too. But to use it, applications have
| to be explicitly coded to use it (and linked against the
| rewire SDK).
|
| That's quite different from JACK, SoundFlower, Hijack and
| the innumerable other inter-application audio routing
| systems for macOS, which can be used without the
| applications knowing anything about them.
| marcodiego wrote:
| Pipewire allows any app to be an element on a patchbay:
| https://gitlab.freedesktop.org/ryuukyu/helvum
| PaulDavisThe1st wrote:
| I know what Pipewire does ... I wrote JACK :)
|
| I was describing what macOS does not not allow, and
| that's routing audio between applications. When I say
| that, I don't mean that it is impossible - there are
| numerous tools (including JACK) that will allow it - but
| it doesn't come with just CoreAudio itself.
| marcodiego wrote:
| Thanks for writing Jack! I love the fact that I can play
| something in vmpk, render using qsynth, process in
| rackarrack and record directly in audacity. The routing
| feature alone sets Linux apart from the competition and
| I'm happy it influenced pipewire to implement it.
|
| Linux is already deployed in some commercial daws and it
| will soon be an RTOS. Hope music production will have
| more and better options because of this.
| PaulDavisThe1st wrote:
| There have been "RTOS" versions of Linux for more than 20
| years. The current mainstream kernel already includes
| almost all of the RT_PREEMPT patch set that makes it more
| or less an RTOS if you want it to be.
| codedokode wrote:
| I am not sure if ALSA playback should go through an audio
| daemon. Some audio applications (for example audio workstations
| that you have mentioned) want to have exclusive access to an
| audio card with minimum latency, without any sample
| conversions, any volume adjustment and ALSA (as I understand)
| was supposed to provide such access. Audio daemon prevents them
| from getting it. Passing data through a daemon adds latency.
|
| Wouldn't it be better if daemons like PulseAudio or PipeWire
| gave control of an audio card to an application that wants
| exclusive access?
|
| For example, Windows API can provide exclusive access to an
| audio card.
| keithwinstein wrote:
| Yes, PulseAudio and JACK do this as well -- there is a DBus
| API that makes them give up an ALSA device to an application
| that wants direct access.
| http://git.0pointer.net/reserve.git/tree/reserve.txt
| JoshTriplett wrote:
| PulseAudio already covers the ALSA interface, but I'm glad that
| PipeWire now unifies those two with JACK and audio workstation
| needs, as well as handling video.
| tgsovlerkhgsel wrote:
| Does it fix the Bluetooth audio mess? Ubuntu 21.04 still can't
| do videoconferencing properly via Bluetooth as only ancient
| 'string on a tin can' codecs are supported.
|
| And getting it to just stick to unidirectional audio (relying
| on the internal mic for input, which seems like the only
| practical option) took some serious trial and error. It still
| occasionally sends a stream to my headphones when nothing is
| playing, which prevents other devices from using them (my
| headphones let you connect two devices but only play audio from
| one of them).
|
| If it does address these issues, I hope Ubuntu will soon
| officially support it (I've learned better than to use non-
| defaults, it just invites pain).
| capableweb wrote:
| > Does it fix the Bluetooth audio mess? Ubuntu 21.04 still
| can't do videoconferencing properly via Bluetooth as only
| ancient 'string on a tin can' codecs are supported.
|
| https://wiki.archlinux.org/title/PipeWire > 4 Troubleshooting
| > 4.8 Low audio quality on Bluetooth
|
| > I've learned better than to use non-defaults, it just
| invites pain
|
| Funny, after using Ubuntu for many years I switched to Arch,
| just because I got hit by so many upgrade issues when "things
| should just work". With Arch I can only blame myself, which
| is refreshing.
| hmry wrote:
| It did for me. I switched from Pulse to PipeWire and my
| bluetooth headphones started working right away. Quite the
| experience.
| corty wrote:
| Agreed. The latest Debian upgrade installed pipewire for
| me, and I didn't even notice, everything just worked fine!
| And that after years and years of fiddling with alsa and
| pulseaudio configs, uninstalling pulseaudio, hacks upon
| hacks to get stuff working with either, etc.
| glandium wrote:
| Debian 11 doesn't make pipewire replace pulseaudio, alsa
| or jack.
| corty wrote:
| Should have mentioned, I'm running testing/unstable.
| After the stable release, all the new experimental stuff
| for the next release floods into unstable.
| heavyset_go wrote:
| > _Does it fix the Bluetooth audio mess_
|
| Yes, one of the biggest features of Pipewire is proper
| Bluetooth headset support. It's the reason I switched to it.
| throwdbaaway wrote:
| It actually does more than fixing the mess now. With
| pipewire >=0.3.34, there is now support for a2dp duplex
| with both faststream and aptx-ll codecs (if the headset
| also supports them, of course). No more hsp/hfp crap.
|
| I think linux + bluez + pipewire is the first ever
| software-only stack that can achieve this, as a USB dongle
| would be required on other platforms. We shall declare 2021
| as the year of linux on the desktop!
| AceJohnny2 wrote:
| "There are now _4_ competing standards "
|
| https://xkcd.com/927/
| smoldesu wrote:
| I'd love to hear how you think Pipewire and ALSA/Jack are
| competing.
| mmerlin wrote:
| Pipewire seems more like a multiplexer/bridge for the
| existing standards.
| tootie wrote:
| I'm completely confused reading the home page. What actual use
| cases is this for? Like what applications are served by it?
| captn3m0 wrote:
| Pipewire is great, but it is sadly lacking in end-user
| documentation. With pulseaudio, if something broke or needed
| tweaking - I had thousands of forum posts to go through. Even the
| Arch Wiki has a PulseAudio/Troubleshooting section with various
| configuration suggestions.
|
| For Pipewire, there is no end-user documentation that I've found
| so far.
|
| On one my setups, and all media stops playing, including videos
| if I forget to plug in my headphone. Restarting pipewire or
| plugging in devices after that doesn't seem to help, and I have
| no idea about the pipewire configuration files to even attempt
| any changes. I would really appreciate some end user debugging
| and configuration related documents.
| mjevans wrote:
| Currently you want bleeding edge PipeWire. Many underrun issues
| are addressed with newer versions. Archlinux seems to stay
| updated, if you're not using a rolling distro (E.G. Debian) you
| might need to pin some packages from a future version.
| captn3m0 wrote:
| This is on Arch. All the logs pretend that it's all
| functional. I think it might just be a Intel NUC issue.
| encryptluks2 wrote:
| Bleeding edge indicates the software is using an unstable
| branch. The stable branch of software (non-beta) is not
| considered bleeding edge.
| eloeffler wrote:
| I haven't used it yet, but could it be that you haven't checked
| for a while?
| https://wiki.archlinux.org/title/PipeWire#Troubleshooting There
| are a couple of sections there
| captn3m0 wrote:
| Nopes, I've tried most of this already.
| prvc wrote:
| >With pulseaudio, if something broke or needed tweaking
|
| >I had thousands of forum posts to go through.
|
| That points to what sounds like two disadvantages, if anything.
| captn3m0 wrote:
| That was part of my point - PA's troubleshooting/tweaking
| experience was terrible, but it was still feasible.
| prvc wrote:
| If you were to experience a novel or rare problem with
| PulseAudio, you would be in the same boat. The likelihood
| of a user encountering a problem is more apt than assuming
| as a given that you're dealing with a problem.
| wmanley wrote:
| See also some background in this LWN article:
| https://lwn.net/Articles/847412/
___________________________________________________________________
(page generated 2021-09-12 23:00 UTC)