4 ms·

"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.

"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. This: https://github.com/werman/noise-suppression-for-voice#pipewire 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)

artogahr 4y ago
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.
- gerdesj 4y ago
  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.
nyanpasu64 4y ago
I'm convinced that splitting out management logic and pipewire-pulse was the wrong choice so far for desktops. It exposes regular users to the failure modes of race conditions (https://bugs.kde.org/show_bug.cgi?id=438565#c21 https://bugs.kde.org/show_bug.cgi?id=438565#c21, likely https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/102 https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues..., https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2409 https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/24...) and inscrutable wireplumber "100% CPU burning" bugs deep in Lua interpreter call stacks, as the price of complexity which only benefits complex users like cars.
- quotemstr 4y ago
  > wrong choice so far for desktops 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.
  - pjmlp 4y ago
    As proven by OpenGL and Vulkan, consistency only happens on paper, then there is the actual hardware, drivers, OS specific issues,...
    - quotemstr 4y ago
      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?
      - pjmlp 4y ago
        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.
  - 4y ago
fisian 4y ago
For me it wasn't about being next to a road but just to compensate for a bad microphone. After using RNNoise directly, now I use EasyEffects with a preset I found here: https://gist.github.com/MateusRodCosta/a10225eb132cdcb97d7c458526f93085 https://gist.github.com/MateusRodCosta/a10225eb132cdcb97d7c4... It reduces the background noise to be barely noticeable.
- Zardoz84 4y ago
  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.

artogahr 4y ago

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.

gerdesj 4y ago
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.

nyanpasu64 4y ago

I'm convinced that splitting out management logic and pipewire-pulse was the wrong choice so far for desktops. It exposes regular users to the failure modes of race conditions (https://bugs.kde.org/show_bug.cgi?id=438565#c21 https://bugs.kde.org/show_bug.cgi?id=438565#c21, likely https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/102 https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues..., https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2409 https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/24...) and inscrutable wireplumber "100% CPU burning" bugs deep in Lua interpreter call stacks, as the price of complexity which only benefits complex users like cars.

quotemstr 4y ago
> wrong choice so far for desktops 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.
- pjmlp 4y ago
  As proven by OpenGL and Vulkan, consistency only happens on paper, then there is the actual hardware, drivers, OS specific issues,...
  - quotemstr 4y ago
    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?
    - pjmlp 4y ago
      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.
- 4y ago

fisian 4y ago

For me it wasn't about being next to a road but just to compensate for a bad microphone. After using RNNoise directly, now I use EasyEffects with a preset I found here: https://gist.github.com/MateusRodCosta/a10225eb132cdcb97d7c458526f93085 https://gist.github.com/MateusRodCosta/a10225eb132cdcb97d7c4... It reduces the background noise to be barely noticeable.

Zardoz84 4y ago
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.