"One first design choice was to avoid tackling any management logic directly inside PipeWire"
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.
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.
> Isn't there value in having a single universal media routing framework that works across desktops, automobiles, and other applications? Consistency is a virtue.
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
> 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
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.
> I want to grant these powers to a few select applications and not to everyone else.
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
Sure. Different GPU setups have different performance characteristics (e.g. tiled vs non-tiled architectures), different sets of supported extensions, and differently intriguing and exciting bugs --- but isn't it still better that, at a basic level, that we talk to them over a common set of APIs (DirectX, OpenGL, and now Vulkan) instead of having vendor- or use-case-specific whole API surfaces?
Not really, because the amount of workarounds, and extension loading, tends to increase to the point that the multiple code paths are hardly any different from having a plugin architecture, and slowly one gets a middleware engine that only uses "one" API.
It's really impressive how makes a difference. I had a portable AC running very near of where my computer are, and with RRNoise (and now EasyEffects), the noise can't be noticed. Also, I use a mechanical keyboard and barely it's noticed when I talk and I type at same time.
This looks really cool, but how do I select which microphone it uses for filtering? If I choose "Noise Canceling source" as the input device like the guide suggests, is that source picking up noise from my laptop's internal microphone, my usb headset microphone, or my bluetooth headphones' microphone? I don't see an obvious way to control that.
I only have one USB headset and it just works on my laptop and desktop so I suspect it simply attaches to all input devices.
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.
I just switched to PipeWire and it's working great. It's fantastic that it can replace both pulseaudio and jack; it seems like a massive improvement in the linux audio situation.
My only problem so far is that I can't figure out how to correctly define a custom profile for my Tascam Model 12. I created one for ALSA/PulseAudio that used to work perfectly, but it appears that PipeWire has a new config format and mechanism for this kind of thing, and I've been unable to wrangle it into a working result.
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 was playing Spider-Man with a dual sense and got wondering. That game puts out audio to your speakers, a separate audio stream to the speaker in the controller, and _another_ stream of audio for the haptics. Is this any bit possible with any Linux audio solution?
I don't see why that wouldn't be possible with Pipewire. The system will provision your application with the default audio output but through the Pipewire API you can send any audio stream(s) you want to any device(s) you want.
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?
You can route an audio stream into any channel of any audio device so even if the controller shows 9 channels, you can use all of them if you provide enough sources.
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.
> this API has been in use by the pro-audio audience and targets low-latency for audio and MIDI connections between applications.
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. :)
I hope somebody has a solution for a problem that I have and can't find anything online.
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?
Still find it odd that I will need to use pipewire-pulseaudio and parec if I want to create a loopback device and null sink so I can select a sound device that doesn't play audio locally, and record audio to send over the network. Unless someone else has done all of this with native PipeWire?
I'll try that. Last time I checked (not that long ago!) the instructions were to use pactl to create null + loopback, and parec to record and pipe to [whatever]. I'll check out pw-loopback!
> For each component (subgraph of the whole PipeWire graph), one node is the driver and is responsible for timing information.
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.
Whenever my laptop stays on for more than like a day, audio quality reduces for my pipewire setup. I have not bbeen able to debug it so far - but restarting the machine makes it go away.
Odd, are you using speakers or headphones or Bluetooth, what does pw-top say before and after quality drops, and is there anything in journalctl --user?
One of the things that bothers me about Pipewire, is that the protocol to communicate with it is undocumented -- only the reference C implementation exists.
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?
My Bluetooth devices regularly disconnect & reconnect, sometimes no longer output anything (until I disconnect/reconnect manually), or won't allow me to switch to certain codecs anymore (until I disconnect/reconnect).
Not sure at all this will help, but wireplumber is supposed to be the replacement for pipewire-media-session. So this is something easy you could try if your distribution has a package for wireplumber.
Really? I tried the first M1 Mac Minis, and bluetooth was terrible -- macOS would constantly switch to the worst quality profile. I use an iPhone on a daily basis, and I always with its bluetooth was as reliable as my Linux laptop.
What exactly did you find lacking in the Linux world? Are you an audio professional?
It's still amazing to me that people care about low-level details of their Linux system, like PipeWire. Personally, I'll use PipeWire when the most popular distro switches to it (which is Ubuntu). (If Ubuntu is already using PipeWire, good! Don't tell me. I don't want to know.) This is my act of rebellion against the Linux community, in hopes that my act of obstinance will help bring about a truly Windows-like Linux environment.
I mean I didn't care about X11 until I used Wayland and realized that I didn't just have to deal with screen tearing.
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.
I'm using X11 and I haven't seen screen tearing since the augths. I do see frequent Wayland hangs, weirdly indepdent of hardware and distro...
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.
That's because the reality is that screen tearing happens due to hw changes in certain GPUs and not X11, and Wayland compositors dumb down the GPU interface that they need to synchronize in userspace anyway and thus lack of sync logic in intel gpus doesn't cause tearing anymore.
Every time that I Try Wayland, I always get really annoying bugs. Including one that puts black both of my screens and I only can do it's a REISUB.
I would keep yet on X11, that on my case works better.
Nobody forces you to care though. Especially if everything works for you. And there are people who are interested in how their systems work, why should they not?
This site is called Hacker News - hackers are people who like to understand how things work and tweak/subvert them to their purposes. Are you here by accident?
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)