Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PipeWire: Bluetooth Support Status Update

collabora.com

Post reply on HN
Print view View original

61–70 of 101 posts

Re: PipeWire: Bluetooth Support Status Update

#61

Post by snvzz »

emilyst wrote: post #52
noobermin wrote: post #38

Earlier quoted context omitted.

So is pipewire actually valuable and not just pulseaudio all over again?

It's fine when it works. It's a monstrosity when it doesn't. I spent an hour the other day trying to figure out how to tell it not to output audio through my DualSense controller haptics (which look like a four-channel audio output) when I connect it to an Intel NUC over USB. I never did succeed, and all the posts I found were basically other people asking how to do similar things.

I used pavucontrol to simply tell it to not do it. Once is enough.

In the sound cards list, just set to disabled.

Re: PipeWire: Bluetooth Support Status Update

#62

Post by doublepg23 »

R0flcopt3r wrote: post #22
4khilles wrote: post #14

Earlier quoted context omitted.

I have the same issue on the latest Fedora. It's very disappointing that bluetooth connectivity isn't a solved problem in 2022 (at least on Linux, haven't noticed any issues in Windows for a while). Are we ever going to get to a point where bluetooth "just works"?

I have daily bluetooth issues on Windows. Someone decided it was a good idea to have bluetooth jabra speakers/microphones for our meetingrooms... It takes 5 minutes to do the pair/connect/set correct device dance... every. day. My macbook can't even figure out that it should try to connect to my offce trackpad after I have had it connected to my home trackpad! Thankfully it has a built in trackpad that I can use to m…

Is that with an M1?

I had a 12" MacBook no-adjectives in the past which didn't even work with AirPods well. I was hoping the M1 would have a better BT stack (the iPhone's...)

Re: PipeWire: Bluetooth Support Status Update

#63

Post by WhatIsDukkha »

stavros wrote: post #57
freeqaz wrote: post #41

Earlier quoted context omitted.

Pipewire implements the APIs of Pulse, Alsa, and Jack. So instead of having to juggle between them all, you just have one service to manage and it all just works. It only took a few lines for me to switch and I've never had a Linux audio issue ever since! (And when I have, it's been my fault like my volume was turned down or my speakers were unplugged lol)

How did you switch? I'd be interested in trying this on Ubuntu.

Should be pretty close -

https://wiki.debian.org/PipeWire

Re: PipeWire: Bluetooth Support Status Update

#64

Post by snvzz »

throwaway82652 wrote: post #55
waplot wrote: post #43

Can someone explain to me what pipewire's goal is? to be a better pulseaudio? if so, in what way is it trying to be better? also, how's the codebase quality? from what i heard, pulse's codebase is a mess, so if it can improve in that sense, i guess that's a win (?) why does it do video? is trying to do media capture like OBS or be a compositor like wayland? if so why bother? those solutions exist already... maybe it…

>Can someone explain to me what pipewire's goal is? to be a better pulseaudio? Yes, and also the goal is to support video in addition to audio. >if so, in what way is it trying to be better? Well in addition to supporting video, it also supports jack clients without needing to run a separate server. There are a few other things like better security policies, but those are the major ones. >also, how's the codebase qua…

>Pulseaudio's code is fine

No, it isn't. Pulseaudio is based on a push model, which is completely broken.

Pipewire uses a pull model, like BeOS/Haiku and jack. It is suitable for pro audio, which pulseaudio could never hope to support.

Re: PipeWire: Bluetooth Support Status Update

#65

Post by snvzz »

pabs3 wrote: post #45

I had choppy audio when under high CPU load on older hardware with PipeWire, but got told that increasing the latency prevents that. The reason I don't get that with PulseAudio is that it has higher latency than PipeWire's default latency. Turns out this command works for me: pw-metadata -n settings 0 clock.force-quantum 2048

PipeWire will use SCHED_RR automatically, but Linux mainline is pretty bad at actually delivering consistently low scheduling latency.

As an alternative to increasing latency, especially if you're not running on batteries, try linux-rt. (PREEMPT_RT).

It makes scheduling latency decent. On my machines, the max column in rt-test cyclictest, after running for a day, remains at linux-rt patchset is slowly getting merged into mainline. I am hopeful that at some point we will be able to build it with PREEMPT_RT, and that desktop kernels in distributions will do that.

Re: PipeWire: Bluetooth Support Status Update

#66

Post by emilyst »

snvzz wrote: post #61
emilyst wrote: post #52

Earlier quoted context omitted.

It's fine when it works. It's a monstrosity when it doesn't. I spent an hour the other day trying to figure out how to tell it not to output audio through my DualSense controller haptics (which look like a four-channel audio output) when I connect it to an Intel NUC over USB. I never did succeed, and all the posts I found were basically other people asking how to do similar things.

I used pavucontrol to simply tell it to not do it. Once is enough. In the sound cards list, just set to disabled.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound.

For a headless system, it's useless.

Re: PipeWire: Bluetooth Support Status Update

#67

Post by kam »

emilyst wrote: post #66
snvzz wrote: post #61

Earlier quoted context omitted.

I used pavucontrol to simply tell it to not do it. Once is enough. In the sound cards list, just set to disabled.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound. For a headless system, it's useless.

`pactl` is the command line version

Re: PipeWire: Bluetooth Support Status Update

#68

Post by snvzz »

kam wrote: post #67
emilyst wrote: post #66

Earlier quoted context omitted.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound. For a headless system, it's useless.

`pactl` is the command line version

And 'ssh -X' is also a thing.

Re: PipeWire: Bluetooth Support Status Update

#69

Post by snvzz »

emilyst wrote: post #66
snvzz wrote: post #61

Earlier quoted context omitted.

I used pavucontrol to simply tell it to not do it. Once is enough. In the sound cards list, just set to disabled.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound. For a headless system, it's useless.

>For a headless system, it's useless.

DualSense is a game controller. In this context, headless is unlikely.

Re: PipeWire: Bluetooth Support Status Update

#70

Post by noobermin »

ncmncm wrote: post #50
noobermin wrote: post #38

Earlier quoted context omitted.

So is pipewire actually valuable and not just pulseaudio all over again?

Pulseaudio had to contend with a huge number of buggy drivers, adapters, and clients. The bugs very gradually got fixed under pressure from PA, with PA always blamed. (PA of course also had bugs that gradually got fixed.) PW benefits from the more sane operating environment PA enforced. I always used to delete PA because I had no desire or need ever to have more than one audio source feeding more than one audio sink.…

Going to be very real, I do not really have more than an inkling of the "world" PW inherits or whatever, but this sounds like "trust us, this time it's okay." I might need a little more convincing this isn't just another attempt to recreate a "universal framework that covers everyone's use cases." (I won't like the obvious reference)
Post reply on HN