PipeWire: The Linux audio/video bus • Hacker News Board

Re: PipeWire: The Linux audio/video bus

#181

Post by bluGill » Thu, Mar 04, 2021, 2:02 PM UTC

tialaramex wrote: post #159

bluGill wrote: post #55

Earlier quoted context omitted.

Trivia, FreeBSD looked at Alsa and decided they were using a rewrite as an excuse to not fix OSS and so they dug in and fixed OSS so it worked.

You know how some people say C thinks every computer is just a fancier PDP-11 ? OSS thinks every computer's audio playback devices are just fancier CT Soundblasters. If you've got a typical generic PC with Intel HDA or AC'97 (or indeed, an actual PCI Soundblaster) and what you'd like to have happen is that you can run your VoIP software, and listen to MP3s and also have new mails go "bing!" then "all the world is a S…

PulseAudio sits above the level of OSS/ALSA to do that magic. Layers are often a good things when it separates concerns and makes the whole easier to handle.

Re: PipeWire: The Linux audio/video bus

#182

Post by warmwaffles » Thu, Mar 04, 2021, 2:03 PM UTC

bluGill wrote: post #74

dbrgn wrote: post #4

The fact that PipeWire has the potential to replace both PulseAudio (for consumer audio) and Jack (for pro audio) with a unified solution is very exciting.

Particularly if you are on the pro audio side. Consumer audio can ignore pro-audio for the most part. However everyone on pro-audio needs to do something consumer audio once in a while, if only to run a web browser.

What is pro audio? I'm naive when it comes to this.

Re: PipeWire: The Linux audio/video bus

#183

Post by andrewzah » Thu, Mar 04, 2021, 2:57 PM UTC

ledbettj wrote: post #9

nitsky wrote: post #3

PipeWire has worked very well for me both as a drop-in replacement for PulseAudio and to enable screen sharing on Wayland.

It also worked as drop in replacement for PulseAudio for me, except all my audio now had stutters and pops. I ended up going back to Pulse. I got suggestions that I could go tweak buffer sizes stuff in a config file somewhere, but for my simple desktop use case I'd rather my audio just sounds right out of the box. Hopefully this sort of thing gets straightened out, because having to muck with config files to make my…

FWIW I had issues with it on debian 10, until I built and installed it from master. It was a bit smoother on debian 11 but I couldn't get bluetooth to work.

Re: PipeWire: The Linux audio/video bus

#184

Post by justaj » Thu, Mar 04, 2021, 3:47 PM UTC

wang_li wrote: post #165

justaj wrote: post #85

Earlier quoted context omitted.

I think you've hit one of the most painful topics of ALSA: Its documentation.

Check out the "Perfect Setup" for Pulse Audio: https://www.freedesktop.org/wiki/Software/PulseAudio/Documen... Sounds on linux is a shitshow.

Yeah I'm aware that PA has relatively a lot of documentation, but I'd still like to see ALSA documented. Even if a tiny bit more.

Re: PipeWire: The Linux audio/video bus

#185

Post by patrakov » Thu, Mar 04, 2021, 4:21 PM UTC

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…

> Saying rewindable audio is a non-feature might simplify the codebase, but if it makes it work badly for most use cases, it ought to be rethought.

Rewindable audio is a non-feature because nobody except two or three people in the world (specifically, David Henningsson, Christopher Snowhill and maybe Georg Chini) can write non-trivial DSP code that correctly supports rewinds.

Re: PipeWire: The Linux audio/video bus

#186

Post by patrakov » Thu, Mar 04, 2021, 4:31 PM UTC

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

> Why can't you just increase buffer sizes and write more data to them to avoid frequency of wake ups?

Because then software volume will take too long to apply, and a new stream will have to wait (again, too long) until everything currently in the queue has been played. PulseAudio tried to solve this with rewinds, but failed to do it correctly. ALSA plugins other than hw and the simplest ones (that just shuffle data around without any processing) also contain a lot of code that attempt to process rewinds but the end result is wrong.

Re: PipeWire: The Linux audio/video bus

#187

Post by dbrgn » Thu, Mar 04, 2021, 5:04 PM UTC

warmwaffles wrote: post #182

bluGill wrote: post #74

Earlier quoted context omitted.

Particularly if you are on the pro audio side. Consumer audio can ignore pro-audio for the most part. However everyone on pro-audio needs to do something consumer audio once in a while, if only to run a web browser.

What is pro audio? I'm naive when it comes to this.

Setups for professional music production. This usually requires JACK (https://jackaudio.org/) as audio server, which allows synchronizing and connecting multiple applications.

For example, you can have Ardour (https://ardour.org/) as DAW, but use another application like Hydrogen (http://hydrogen-music.org/) for creating drum samples. JACK connects the two applications using a virtual patchbay that allows using Hydrogen as an Input for Ardour. Essentially any application can be an input and/or an output.

JACK also provides synchronization using a "master clock", so that Hydrogen starts playing as soon as you hit the "record" button in Ardour.

Many people also use a Linux kernel optimized for low latency audio.

With PulseAudio, these things are not possible. On the other hand, consumer applications like web browsers don't usually offer direct JACK support. So bridging is necessary, by using PulseAudio as a JACK input.

Re: PipeWire: The Linux audio/video bus

#188

Post by zlynx » Thu, Mar 04, 2021, 5:05 PM UTC

darwi wrote: post #39

jcastro wrote: post #32

Earlier quoted context omitted.

> I'm not sure why this seems to be remembered so wrongly? It didn't work reliably on all chipsets/soundcards.

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 sound source feeding the pulseaudio daemon is not getting enough CPU time.

Re: PipeWire: The Linux audio/video bus

#189

Post by andrewzah » Thu, Mar 04, 2021, 5:18 PM UTC

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

Re: PipeWire: The Linux audio/video bus

#190

Post by fmoralesc » Thu, Mar 04, 2021, 5:54 PM UTC

xorcist wrote: post #6

What does real world latency look like with Pipewire? Is it comparable to jackd when used with something like Ardour?

Just tried recording from my laptop's mic - the reported latency from Ardour was 5,3ms (with 256 samples/buffer). It crashed when I went down to 128 samples/buffer.