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

41–50 of 101 posts

Re: PipeWire: Bluetooth Support Status Update

#41

Post by freeqaz »

noobermin wrote: post #38
spacemanmatt wrote: post #15

Since I switched to pipewire I've had the best Linux audio end-user experience with BlueTooth devices, ever.

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

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)

Re: PipeWire: Bluetooth Support Status Update

#42

Post by lxgr »

ComputerGuru wrote: post #12
ajsnigrutin wrote: post #11

Earlier quoted context omitted.

Was latency ever an issue with movies? I know mine works without issue on pulseaudio+bluez by delaying the video to sync it with audio (which is actually noticable with an old noname speaker when you pause/play the video - the video stalls, then (i guess) the audio buffers are filled, and movie starts playing with syned a/v, and then when pausing, maybe half a second of audio is still played after you've paused it).

Definitely an issue with Netflix on Ubuntu. Enough that I prefer to “obtain” via other means the content I have paid access then watch it in mpv (where I must still manually introduce a video delay). The delay you describe should be only as long as it takes for the audio packet to be processed by the audio stack as the video syncs with the audio and not the other way around. But I don’t think Bluetooth blocks for an…

> But I don’t think Bluetooth blocks for an ack of each packet

It definitely does, at least for unidirectional/"music" audio (i.e. using A2DP).

A2DP uses ARQ and additionally introduces some buffering to make transmissions more robust in adverse radio environments, at the expense of latency.

Re: PipeWire: Bluetooth Support Status Update

#43

Post by waplot »

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 should just stick to audio, cuz that part of it feels like feature creep.

Re: PipeWire: Bluetooth Support Status Update

#44

Post by e12e »

noobermin wrote: post #38
spacemanmatt wrote: post #15

Since I switched to pipewire I've had the best Linux audio end-user experience with BlueTooth devices, ever.

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

Very much. It's more like Jack all over again, but more friendly - than pulseaudio.

Re: PipeWire: Bluetooth Support Status Update

#45

Post by pabs3 »

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

Re: PipeWire: Bluetooth Support Status Update

#46

Post by patrickthebold »

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…

I can't answer all your questions, but OBS uses pipewire (I think for wayland support[1]), so there's that.

[1] https://github.com/obsproject/obs-studio/pull/4287

Re: PipeWire: Bluetooth Support Status Update

#47

Post by pabs3 »

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…

This LWN article is a good backgrounder on PipeWire:

https://lwn.net/Articles/847412/

Re: PipeWire: Bluetooth Support Status Update

#49

Post by ncmncm »

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…

Pipewire is driven by the need to handle synchronized media from multiple sources delivered to multiple sinks in real time with minimal, constant latency. The reference problem is cars, which often have a dash cam, back-up cam, dash video display, instrument panel display, bluetooth phone connection, radio receiver, satellite receiver, audio amplifier, dash microphone, backseat video display with audio, seatbelt alarm, and more besides, that all have to be managed sensibly with minimal engagement.

Handling audio without video fails if they have to be kept in sync.

Anyway that's my outsider's impression.

Re: PipeWire: Bluetooth Support Status Update

#50

Post by ncmncm »

noobermin wrote: post #38
spacemanmatt wrote: post #15

Since I switched to pipewire I've had the best Linux audio end-user experience with BlueTooth devices, ever.

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. We don't live in a world compatible with that model anymore.

Post reply on HN