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

PipeWire: The Linux audio/video bus

lwn.net

Post reply on HN
Print view View original

191–200 of 203 posts

Re: PipeWire: The Linux audio/video bus

#191

Post by chenxiaolong »

andrewzah wrote: post #189
chenxiaolong wrote: post #10

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

"My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile." What configuration did you have to do to get this to work? I'm also using pipewire built from the latest master (PipeWire 0.3.22).

In `/etc/pipewire/media-session.d/bluez-monitor.conf`, I uncommented:

    bluez5.msbc-support = true
    bluez5.sbc-xq-support = true
You'll also need to make sure you're on a kernel supporting the WBS fallback patch[1], which should be the case if you have the latest 5.10 kernel or the 5.12 development kernel.

You can check if it's working by running `info all` in pw-cli. It'll mention if the bluez codec is "mSBC".

[1] https://patchwork.kernel.org/project/bluetooth/patch/2020121...

Re: PipeWire: The Linux audio/video bus

#192

Post by labawi »

zlynx wrote: post #188
darwi wrote: post #39

Earlier quoted context omitted.

Indeed. It also glitches like hell in case of any system load.

That's why PulseAudio and PipeWire run as real-time. Or they should. Back when Pulse was new and I was running Gentoo I used to help other Gentoo users get their real-time settings correct. I believe we used rtprio in limits.conf. I don't recall when RTKit became a thing. If your sound daemon is running as real-time and still missing deadlines then there's something wrong with your system hardware. Or I suppose, the…

I think they indeed should run at a (low) real-time priority, but only if they are limited to a fraction of total available CPU power, with say cgroups or similar.

Otherwise they can easily lock up the system, and that should not be the default configuration.

Re: PipeWire: The Linux audio/video bus

#193

Post by severino »

teddyfrozevelt wrote: post #114
severino wrote: post #97

Earlier quoted context omitted.

I gave JACK a try more than a decade ago, and I remember how cool it was to be able to pipe the audio from one application to the input of another (unrelated) app, possibly adding effects or transformations in between. But JACK never became "mainstream" so I never got to use it for anything serious, but I miss the flexibility it offered even for non professional use-cases. What I wonder is if PipeWire will allow this…

I'm running PipeWire on Arch and I can do it through `pw-jack carla`[1]. You can do surprisingly advanced stuff through the JACK compatibility. [1] https://i.imgur.com/EFUxR41.png

Hey, it looks nice! But, are you required to be running JACK? I mean, isn't this routing capability part of the PipeWire's core?

Re: PipeWire: The Linux audio/video bus

#194

Post by jpetso »

trasz wrote: post #175
cycloptic wrote: post #164

Earlier quoted context omitted.

I mean Linux, it does the same but reversed: the kernel implements the ALSA API, and libaoss is provided for backwards compatibility in userspace with OSS. What else should they have done? The ALSA API is not the same as OSS and has a different set of features.

Feature set doesn’t really depend on the API, FreeBSD implements all that functionality despite using OSS.

It sounds like Linux and BSD both have an implementation for both APIs, only implemented in different ways? If so, I don't much see where the problem is with this solution.

Re: PipeWire: The Linux audio/video bus

#195

Post by teddyfrozevelt »

severino wrote: post #193
teddyfrozevelt wrote: post #114

Earlier quoted context omitted.

I'm running PipeWire on Arch and I can do it through `pw-jack carla`[1]. You can do surprisingly advanced stuff through the JACK compatibility. [1] https://i.imgur.com/EFUxR41.png

Hey, it looks nice! But, are you required to be running JACK? I mean, isn't this routing capability part of the PipeWire's core?

No, I don't have jackd running. Launching something with `pw-jack` (AFAIK) makes that use the PipeWire libraries instead of the normal JACK ones. I think PipeWire has it's own internal graph that's compatible with ALSA, PulseAudio, and JACK, and that's how it can work with any program. Here's the output of `pw-dot` which is a PipeWire tool that dumps the graph: https://i.imgur.com/OMZCcmC.png

Re: PipeWire: The Linux audio/video bus

#196

Post by aidenn0 »

freeqaz wrote: post #13
londons_explore wrote: post #7

Without audio buffer rewinding, you're going to have to suffer random stutters and jumpiness every time your system comes under heavy load. Your system does an NMI because you plugged the power cable in? Your audio will glitch. It will also mean you won't be able to sit with an idle CPU while playing music - the audio daemon will have to wake up to reload buffers multiple times per second, killing battery life unacce…

I'm not sure I understand this. Why can't you just increase buffer sizes and write more data to them to avoid frequency of wake ups? Edit: does this help? https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

Because sometimes latency matters:

- You want a "ding" sound within Xms of the time a user performs some action.

- You want a volume change to happen within Yms of the user pressing the volume up/down keys

Without buffer rewinding, your buffer size when playing music cannot be longer than the smallest of such requirements.

With buffer rewinding, your buffer size can be very long when playing media, and if a latency-sensitive event happens, you throw away the buffer. This reduces wakeups and increases the batch size for mixing, which is good for battery life.

The PipeWire people seem fairly smart, so they are probably aware of this, but I'd like to see power numbers on say a big-little ARM system of PW compared to PA.

Re: PipeWire: The Linux audio/video bus

#197

Post by trasz »

jpetso wrote: post #194
trasz wrote: post #175

Earlier quoted context omitted.

Feature set doesn’t really depend on the API, FreeBSD implements all that functionality despite using OSS.

It sounds like Linux and BSD both have an implementation for both APIs, only implemented in different ways? If so, I don't much see where the problem is with this solution.

They don’t. And the problem is that replacing a popular API with a proprietary one, like ALSA, creates a lot of work for everyone, for no reason other than NIH.

Re: PipeWire: The Linux audio/video bus

#198

Post by Delk »

vetinari wrote: post #179
Delk wrote: post #119

Earlier quoted context omitted.

In the early 00's (before PulseAudio), my desktop had an old SoundBlaster Live PCI card that was pretty common around the turn of the millennium. ALSA dmix Just Worked with that one. Any other hardware I encountered required some kind of software mixing, IIRC. Not that my experience was extensive, but I got the impression that hardware or driver support for dmix wasn't that common.

Dmix was that software mixing; in the early 00's there were some cards capable of mixing in hardware and dmix was not used for them.

Okay, I guess I've got it wrong then. Thanks for the clarification.

Re: PipeWire: The Linux audio/video bus

#199

Post by rcxdude »

dralley wrote: post #127
OJFord wrote: post #18

It's great to see pipewire coming along, pulseaudio development seems to (to a spectator) to have been a little.. well.. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge... https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

While that seems like a huge cluster, it does kind of seem that the patch rejections come from a set of principles. If the patches would improve Bluetooth audio at the expense of breaking existing features, saying "we don't break existing features" is a valid position to hold.

I don't think the issue was breaking existing features, it was a classic 'perfect being the enemy of good' situation. PA maintainers wanted to support dynamically loading the involved codecs due to potential (but not particularly well demonstrated) concerns about licensing and inclusion in certain distros. But they didn't really have the manpower to actually do this (and especially they disagreed with the person actually doing the work on how to go about doing this), so they just sat on an MR for ages while the situation improved for no-one (worst case it gets merged and then disabled at compile time by some distros). Meanwhile frustrations arose because the contributer wanted to help users and the maintainers just seemed like a roadblock to doing this, and the maintainers utterly failed to de-escalate the situation.

Re: PipeWire: The Linux audio/video bus

#200

Post by wedesoft »

onli wrote: post #19

> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application a…

I used the PulseAudio simple API only to find out that it didn't work. Only when I changed to the normal API it started working.
Post reply on HN