An Introduction to PipeWire
bootlin.com
bootlin.com
That single statement indicates to me that PW has got it right. Also I've been using it for 18 months now on Arch after a brief to and fro with PA where stuff failed badly for a short while. Now it is nigh on flawless and just works.
This: https://github.com/werman/noise-suppression-for-voice#pipewi... works really well and I can have my window next to a very busy road open and no one can hear it on Teams. Sorry ... Teams! I use Teams actually 8)
Isn't there value in having a single universal media routing framework that works across desktops, automobiles, and other applications? Consistency is a virtue.
> failure modes of race conditions
Race conditions in distributed systems are tricky. A global 64-bit sequence number incremented on every mutation to the PW graph would help, I think. You'd have the server reply with the latest serial number on every query operation, and mutators would supply their last-known serial numbers along with every mutation operation. If a client attempted to mutate the PW graph using an out-of-date serial number, the server would make the mutation fail. In this case, clients would re-query the PW graph state, figure out whether the intended mutation still made sense, and, if so, try again, this time with the latest sequence number. It's hard to imagine PW graph mutations being frequent enough for this approach to generate livelock too.
Software development isn't about virtues, it's about making computers do useful stuff for us humans. Consistency can help or detract from that ; there's no such thing as an absolute virtue, only technical choices that happen in a specific set of circumstances. Audio is simple enough that it does not seem to cause too much problems but for instance Wayland is absolutely and entirely made worse by trying to shoehorn it both on cars UI (where you want something locked down) and on desktop UIs (where you want random software downloaded from the internet to be able to control the whole thing for e.g. screen recording, global hotkeys, window management mods, etc etc) which are wildly different use cases
I don't want "random software" to be able to do those things. I want to grant these powers to a few select applications and not to everyone else. X11 has no intra-session security model. This lack of security doesn't make it better for desktop or form a case for maintaining X and Wayland in parallel.
To the extent Wayland still has trouble with clients that want to manage windows, it's a matter of missing protocol extensions, not architectural flaws in Wayland that make it and X11 fundamentally suited for different use-cases.
You've chosen a poor example if you're trying to use Wayland to show that we need different software stacks for different use cases. Cross-use-case software stacks are common, work well, and are fundamental parts of the computing universe.
it's more-or-less fine to have a prompt on first app launch (although I have a few times worked with elderly users who literally could not use their computer to do what they wanted because of such prompts, especially on macOs which prompts left and right and trains users to blindly click "yes" or "no")
> it's a matter of missing protocol extensions
there is an infinite amount of missing protocol extensions. As long as it isn't able to fully emulate the win32 API (which is basically what "desktop" means in terms of features) it's not enough
Audio is not simple and causes tons of problems.
and inscrutable wireplumber "100% CPU burning"
This one sucks hard, been an issue for me for ages.After using RNNoise directly, now I use EasyEffects with a preset I found here: https://gist.github.com/MateusRodCosta/a10225eb132cdcb97d7c4...
It reduces the background noise to be barely noticeable.
I use the Noise Cancelling source and it works. For a short while on Arch it crashed in use and the extra source vanished and went back to the default devices but an update fixed that within about a week.
I think you should just use the Noise Cancelling source for everything and it will work. Teams has an echo test and you can always call a friend/colleague to test.
My current workaround is to use one of the PipeWire patchbay GUIs to do ad hoc what I'd normally have as baseline configured system setup.
I've played around with patchbay software to manage existing audio streams. I've sent audio to both my headset and streaming software, adding a block of effects inbetween through JACK audio software, and used a similar JACK audio interface to put audio from a voice chat app to the front left and then piped it into my headphones.
I don't know the API for creating audio streams directly but as long as you can introduce enough sources and expose every audio output as a separate sink (i.e. one for your controller) it's all relatively easy.
I doubt game developers will make use of this any time soon, though. Maybe if the success of the Steam Deck brings a new life to Steam Machines?
I didn't play around with it much, but the controller did appear as a 5.1 (or was it 7.1?) in Linux.
Oh, and I forgot, the controller itself also has a headphone jack. The controller itself can take 3 audio streams, two of which can be used for sound.
I've added 8 (*2, stereo) channels to OBS at some point for shit and giggles and that worked fine without interrupting my normal headphones. Things can only work better without the compatibility layer.
Your biggest issue trying to get this done will probably be picking the right channels for the right controllers because you have no idea what controllers are what on other systems. An audio device dropdown after some auto detection should work, but if the controller has weird specialised channels that don't follow the normal system output (i.e. 5.1 but two channels are actually stereo headphones and not real 5.1) then configuration may be a pain.
It's a visual patch bay for Pipewire. I had no idea and I had to look it up.
My emphasis there because I love that the author got this right.
It's always been frustrating to help users tangled up in Jack only to find out they're just trying to get a single application to output audio with low-latency. (Their assumption being that Jack is the tool to attain low latency audio input/output in Linux.)
Good vibes around Pipewire and good vibes in an article describing Pipewire are a good sign for an audio server. :)
Edit: clarification, typo
I have a simple Pipewire setup. When plugging a regular 3.5mm headphone (/w a mic) it always ends up in maximum capture settings, so if I forget to open `alsamixer` and decrease the mic capture and boost levels to a reasonable level, people behind the other end of Zoom calls suffer.
If I unplug it and plug again, it resets to 100% again. How to fix this?
pw-loopback -m '[FL FR]' --playback-props='media.class=Audio/Source node.name=my-source
for loopback, is it missing something for your use case?A new thing I learned I guess. JACK treats both the output ports and input ports of the single hw device as a driver, and if the output ports (capture) generates more samples than the input ports (playback) accept, you eventually get buffer xruns.
> Note: in this simple example, the buffer size provided to ALSA by PipeWire determines the time we have to generate new data.
I thought PipeWire uses quantums, effectively ignoring ALSA periods and "racing the beam" using software timers instead.
On top of that, language bindings don't expose a lot of things. Like whether a node is muted or not.
I tried to write a tiny widget to show whether my mic is muted on not on my statusbar -- short of reverse engineering the C implementation, there's no simple way to do it.
What worries me is that we're building so much on top of something undocumented. If the devs decide to move on, what'll happen?
I wish https://github.com/wwmm/easyeffects/wiki/Community-Presets had more presets.
Has anyone had the same issues?
(Using PipeWire + pipewire-media-session)
In my daily patching I still tend to use Catia tho
What exactly did you find lacking in the Linux world? Are you an audio professional?
To get screen sharing to work on most Wayland systems, you do need Pipewire. So I learned enough to set it up. And then I learned enough to tune it for my audio recording use cases. Which wasn't actually that much work.
Agree with OP, these things don't really interest me either. I did try Pipewire; is worked as well as PulseAudio for me. The most complicated thing I do is use connect Bluetooth headphones every now and then.
I do mainly use Linux for its free software aspect, not for its technical aspects or its UX. It also happens to be the OS I like best, luckily.