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

PipeWire 0.3.62

gitlab.freedesktop.org

Post reply on HN
Print view View original

51–60 of 98 posts

Re: PipeWire 0.3.62

#51

Post by jancsika »

bluGill wrote: post #36
RedShift1 wrote: post #23

Earlier quoted context omitted.

I don't even know why this is even necessary. Back in the day I just set up the ALSA daemon to save/restore volume levels and that was it. In all programs I select ALSA as output and boom done. So I'm confused to why pulse audio and pipewire even exist.

Because the complexity of audio is hard. If you just have a desktop system with stereo speakers it is easy. However if you ever plug a set of headphones in things get hard. Should all sound now go through the headphones or not? Different people will want different answers (I have headphones plugged in all the time, but I'm not wearing them all the time, so if someone sends me an IM I need the beep to come out the reg…

> Should all sound now go through the headphones or not?

The correct answer to that specific question: as a sane default, all sound should now go through the headphones. That's a sane default on the Iphone, probably on Macbooks, and it also happens to be the one that at least a stock Gnome or Ubuntu desktop chooses. In fact I have trouble thinking of a saner default than that one!

Forgetting about sane defaults seems to be a common problem in FOSS communication. It's unfortunate, because describing something as unknowable can convince a new developer to avoid inspecting the code around that particular problem.

E.g., it took a long time for Gnome to get the sane default I describe above. I'd bet that lurking in the appropriate mailing list history is at least one didactic post from an audio developer explaining how we can never truly know what a user's preferred setup could be.

Re: PipeWire 0.3.62

#52

Post by throw903290 »

codedokode wrote: post #44

Knowledgeable people, please explain. Wouldn't it be better if applications used ALSA for audio output? In this case they could work without Pulseaudio and with (because Pulseaudio adds a sink to ALSA). This way the application doesn't need to know which audio daemon it uses. What are the downsides of this approach?

I use pure Alsa on virtual machines. Image is stripped down so much it barely runs XServer.

Another reason is future proofing. PipeWire is yet another audio protocol, and may not be around in 5 or 10 years.

Not everything has PipeWire. Some flavours of linux has support for 10 years. Even some of my desktop boxes still use Pulseaudio.

And finally what PipeWire actually offers? If you need to dump audio into output, ALSA seems sufficient.

Re: PipeWire 0.3.62

#53

Post by amaranth »

codedokode wrote: post #46
amaranth wrote: post #41

Earlier quoted context omitted.

Raw ALSA can only have one program playing sound unless your hardware has support for hardware mixing (this would generally mean it's very old and also very expensive). More likely you are/were using ALSA's dmix plugin which is a small barebones version of the core functionality of pulseaudio or pipewire. They replace dmix but also give you things like per-program volume control, better latency, better power usage, b…

I am not sure about "better latency". The latency with Pulseaudio cannot be controlled via GUI and is often quite large (on order of hundred ms or more). In my opinion, to get minimum latency one needs to access audio card directly, without intermediate daemons.

PulseAudio optimizes for power consumption but tries to be adaptive to handle lower latency as well. PipeWire seems to optimize for latency but try to be adaptive to reduce power consumption as well. These are conflicting desires, lower latency requires higher power usage because you have to use shorter buffers instead of just giving the sound card a big chunk of audio to work through and putting the CPU to sleep. JACK could potentially still do better and ALSA could potentially still do better than even that but PipeWire's goal is to be close enough or even match JACK while still having all the other features people use PulseAudio for.

Re: PipeWire 0.3.62

#54

Post by CameronNemo »

sph wrote: post #20
lionkor wrote: post #14

I use PipeWire on my desktop and laptop, and its doing a better job than pulse ever did. That said, I've had daily issues with it, from it slowing video playback (weirdly, by about 10 seconds over 20 minutes or so, only noticable when watching something synchronized with someone else), over crackling noises with speakers when no audio is playing, to straight up lags and skips every few seconds with certain devices. A…

If you haven't, post an issue on the Pipewire repo. I've found that the main author, Wim Taymans, is very proactive in fixing any issue if they're reproducible. I've opened two bugs, and two times he fixed them personally in less than a week, which is incredible for an open source project of that size.

I've had the same experience. Had a couple issues and they ended up fixed in the next version.

Re: PipeWire 0.3.62

#55

Post by pxc »

seba_dos1 wrote: post #30
lionkor wrote: post #14

I use PipeWire on my desktop and laptop, and its doing a better job than pulse ever did. That said, I've had daily issues with it, from it slowing video playback (weirdly, by about 10 seconds over 20 minutes or so, only noticable when watching something synchronized with someone else), over crackling noises with speakers when no audio is playing, to straight up lags and skips every few seconds with certain devices. A…

> That said, I've had daily issues with it, from it slowing video playback (weirdly, by about 10 seconds over 20 minutes or so, only noticable when watching something synchronized with someone else), over crackling noises with speakers when no audio is playing, to straight up lags and skips every few seconds with certain devices. How is that "better than pulse ever did"? The only issue I had with PulseAudio on severa…

> Crackling noises or desynchronized video playback would instantly take it into "unacceptable" territory.

> Sounds like you have severe issues with both PA and PW. Maybe your hardware is the problem?

Seconding this! My experience with PA and PW has been basically identical to yours. If possible, GP, try some different hardware! You shouldn't have to put up with that crap.

Re: PipeWire 0.3.62

#56

Post by esaym »

jelicicm wrote: post #5

Stumbled into PipeWire few months ago when trying to setup Bluetooth headset on Ubuntu OS. It's superior to PulseAudio, but... Really unbelievable to comprehend that Linux distros have such bad support for Bluetooth audio headsets - something very common in today's tech world. Android, Windows and Apple's OS all very efficiently switch from A2DP codec which is excellent for audio playback, but has no possibility for…

Wideband (mSBC) support was added into Pulseaudio 15 btw: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1...

It also added support for using higher bitpools for the SBC codec (sbc, sbc_xq_453, sbc_xq_512, sbc_xq_552) which pushes its quality above APTx and the other proprietary codecs. Info about bitpools and SBC here: https://habr.com/en/post/456182/

Re: PipeWire 0.3.62

#57

Post by aidenn0 »

Only slightly OT; does anyone have a solution for playing audio from ssh? The best I have so far is to pick a program that I know is under X (here xterm) and run something like:

    eval "env $(cat /proc/"$(pgrep -n xterm)"/environ |xargs -0 -n1 printf '%q ') bash"
To get the environment setup right.

Re: PipeWire 0.3.62

#58

Post by dlundqvist »

throw903290 wrote: post #52
codedokode wrote: post #44

Knowledgeable people, please explain. Wouldn't it be better if applications used ALSA for audio output? In this case they could work without Pulseaudio and with (because Pulseaudio adds a sink to ALSA). This way the application doesn't need to know which audio daemon it uses. What are the downsides of this approach?

I use pure Alsa on virtual machines. Image is stripped down so much it barely runs XServer. Another reason is future proofing. PipeWire is yet another audio protocol, and may not be around in 5 or 10 years. Not everything has PipeWire. Some flavours of linux has support for 10 years. Even some of my desktop boxes still use Pulseaudio. And finally what PipeWire actually offers? If you need to dump audio into output, A…

From what I've read PW's official stance is to keep using the existing protocols such as PA and JACK. PW comes with a PA-compatible server, replacement JACK client libraries and an ALSA plugin. So it supports clients from all three at the same time. Precisely so software does not need to be rewritten (I imagine).

Re: PipeWire 0.3.62

#59

Post by rjzzleep »

RedShift1 wrote: post #23
lionkor wrote: post #14

I use PipeWire on my desktop and laptop, and its doing a better job than pulse ever did. That said, I've had daily issues with it, from it slowing video playback (weirdly, by about 10 seconds over 20 minutes or so, only noticable when watching something synchronized with someone else), over crackling noises with speakers when no audio is playing, to straight up lags and skips every few seconds with certain devices. A…

I don't even know why this is even necessary. Back in the day I just set up the ALSA daemon to save/restore volume levels and that was it. In all programs I select ALSA as output and boom done. So I'm confused to why pulse audio and pipewire even exist.

Most of the things people below say ALSA didn't have, OSSv4 actually had. But basically, they made it proprietary, Linux switched to ALSA, and when OSSv4 became open source again it lost traction. But from my experience at the time, it had none of the problems ALSA had, it had none of the problems pulseaudio had, and it had none of the problems ESD had.

This is a clear case of when ideology won over an objectively better product to the detriment of all users for more than a decade.

Re: PipeWire 0.3.62

#60

Post by jraph »

aidenn0 wrote: post #57

Only slightly OT; does anyone have a solution for playing audio from ssh? The best I have so far is to pick a program that I know is under X (here xterm) and run something like: eval "env $(cat /proc/"$(pgrep -n xterm)"/environ |xargs -0 -n1 printf '%q ') bash" To get the environment setup right.

(edit: I might have misunderstood your comment, but see my edit at the end)

If you use PulseAudio or pipewire-pulse on your local computer and that both computers are on the same network (or at least the machine you ssh into can access your local machine, possibly through a tunnel - PulseAudio listen to port 4713 by default), you can set the PULSE_SERVER environment variable.

  PULSE_SERVER=X.X.X.X whatever_should_play_a_sound
Where X.X.X.X is the domain or IP of your local machine. Your local machine needs to be configured to allow remote computers to play sound locally (by loading module module-native-protocol-tcp as far as I know - a papref setting is available for PulseAudio).

If the computer you ssh into has Pulseaudio or pipewire-pulse, on your local machine you can run:

  PULSE_SERVER=Y.Y.Y.Y pavucontrol
Where Y.Y.Y.Y is your ssh server, and set the default output sink to your local computer's. Then it will play things through your local computer. You need to setup your local computer so it advertises its PulseAudio service, and your server needs to have the module-zeroconf-discover module loaded.

You can load a module with pactl (for both PulseAudio or pipewire-pulse):

  pactl load-module module-zeroconf-discover
  pactl load-module module-native-protocol-tcp listen=0.0.0.0
edit: and if you just want to play something on your remote machine, then `PULSE_SERVER=localhost` can work. export $(dbus-launch) instead of your command possibly works too. With Pipewire on Debian I noticed it works out of the box though.
Post reply on HN