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

71–80 of 98 posts

Re: PipeWire 0.3.62

#71

Post by traverseda »

codedokode wrote: post #45
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 ALSA doesn't allow two programs to use the same audio card simultaneously. ALSA is good for exclusive access, when you want to remove everything between an application and audio card. Also ALSA cannot do other nice things, like switching audio output when you plug an USB audio card.

It can and does as it was configured by most distributions.

Re: PipeWire 0.3.62

#72

Post by yjftsjthsd-h »

wereallterrrist wrote: post #67
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.

Man, how much are distros + bad user config hurting user "Linux" reports. Thank god for NixOS where (1) we do a decent job of base config and (2) user config errors are basically trivially identifiable. 1. Open `pulsemixer` to monitor pulse clients 2. `ssh localhost "pacat Observe that pacat is showing as a pulse client. This stuff is really easy and should absolutely just work.

Did you reply to the wrong comment? This doesn't seem relevant to remote audio

Re: PipeWire 0.3.62

#73

Post by wereallterrrist »

yjftsjthsd-h wrote: post #72
wereallterrrist wrote: post #67

Earlier quoted context omitted.

Man, how much are distros + bad user config hurting user "Linux" reports. Thank god for NixOS where (1) we do a decent job of base config and (2) user config errors are basically trivially identifiable. 1. Open `pulsemixer` to monitor pulse clients 2. `ssh localhost "pacat Observe that pacat is showing as a pulse client. This stuff is really easy and should absolutely just work.

Did you reply to the wrong comment? This doesn't seem relevant to remote audio

Um, it's just an example? Does this somehow help?

1. (term1) `ssh remote pulsemixer`

2. (term2) `ssh remote "pacat Observe that (1) you can see a new client appear on the remote, and (2) audio will play from the default playback device on the remote (and you can trivially change that device with `pulsemixer`)

EDIT: for your speakers/ears-sake, I recommend turning down the default playback device before doing this.

Re: PipeWire 0.3.62

#74

Post by megous »

mort96 wrote: post #37
trifurcate wrote: post #31

Earlier quoted context omitted.

Excuse my ignorance, but don't monitors take their clock signal from the host? I would think that synchronizing a stream of frames to the display refresh rate is a mismatch to handle on the display end, not the host end where frames might get doubled or skipped (and eventually introduce long-term timing errors). This is assuming an 60Hz rate advertised by the monitor.

I don't know whether the clock is technically in the host machine or in the monitor, I imagine it depends on the type of connection. But the idea of a different "display clock" and "playback clock" still applies, since a program's own timekeeping based on usleep + gettimeofday will be different from the monitor clock, wherever that happens to reside. And unless you're using some kind of variable refresh rate, the mon…

Pixel clock is generated on the host. All the VSYNC/HSYNC pulse timings are also generated by the host. Monitor has little choice but to respect it, or refuse to operate.

On some embedded platforms, if you can't get a precise clock you need from clock subystem, or massage the display mode timing to fit whatever pixel clock you can generate, you may be running your display at 34 FPS instead of 60 FPS if you're not careful eneough. And you'll barely notice unless you measure it, or try to play video or do anything else sensitive to timing.

Re: PipeWire 0.3.62

#75

Post by pengaru »

lazyier wrote: post #39
seba_dos1 wrote: post #30

Earlier quoted context omitted.

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

I estimate about 75% chance it's a configuration problem on his end. The "I hate Pulse Audio and especially Lennart" crowd tends to want to either go back to "Alsa" or tried at some point to install the old OSS drivers and then gave up. This means trying to configure dmix to work properly, trying to configure your audio outputs with tools like 'alsamixer' and things of that nature. This is about a 100% guaranteed app…

As someone using strictly alsa/dmix/alsamixer for decades now, I'm surprised to learn my OS audio is a dumpster fire.

To me it's a low-feature deterministic stack that rarely does what I don't want it to.

But I haven't introduced a bunch of fuel for the fire like bluetooth audio devices either... to each their own.

Re: PipeWire 0.3.62

#76

Post by codethief »

viraptor wrote: post #9
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…

Not sure if this is what you were pointing out here, so just in case: Pipewire does allow you to switch BT codecs including the ones which do better bidi quality. Including autoswitching if you want it to happen automatically https://wiki.archlinux.org/title/PipeWire#Automatic_profile_... (you can switch manually as well)

I came here to say the same thing. This feature has had its fair share of bugs over the last year but lately (using Wireplumber) it's been working quite reliably for me. I no longer use any Bluetooth USB dongles!

Re: PipeWire 0.3.62

#77

Post by codethief »

jchw wrote: post #25
jelicicm wrote: post #12

Earlier quoted context omitted.

Sorry, not saying that. I do have an option of either A2DP or HSP. I was not familiar with auto switch. But you kind people have filled me in in this thread. A2DP sounds amazing for listening to music, no problems there. The problem is the hassle of switching between profiles, since I tend to use my headphones in work environment (calls, meetings) - this is the reason I still keep a pair of cabled headphones around.

Interesting. Not sure what the deal is. Someone is suggesting that at least for PulseAudio, it could just be the older version of PulseAudio that shipped with Ubuntu. However, you should be able to get it working on Pipewire just as well. Pipewire stuff is still pretty immature, so your distro may have an older and less stable Wireplumber at the moment. In that case, it might be worth just trying to set the Pipewire…

+1 For Pipewire + Wireplumber! With it, automatic codec switching has worked quite well for me!

Re: PipeWire 0.3.62

#78

Post by wtay »

codedokode wrote: post #47
kobalsky wrote: post #43

Earlier quoted context omitted.

pulseaudio exists because it's user friendly. JACK exists becase some people need low latency and dynamic control over non-trivial audio routing. pipewire attempts to bring the best of both worlds and make it container friendly for security purposes.

> JACK exists becase some people need low latency Wouldn't latency be lower if the application would access audio card directly without any daemons in between?

The answer is, surpisingly maybe, no. JACK (and PipeWire) manage to add features without adding any latency to what ALSA can provide. Will it consume more CPU? yes, it does...

Re: PipeWire 0.3.62

#79

Post by wtay »

rjzzleep wrote: post #59
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.

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 be…

OSS relies on mixing in the kernel, which is bad for reasons explained here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

Also with OSS you still can't seamlessly switch between devices, bluetooth or arbitrary signal routing between apps. So, no... good riddance.

Re: PipeWire 0.3.62

#80

Post by Arnavion »

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.

https://news.ycombinator.com/item?id=30621077

(And yes, I use pipewire. The socket is pipewire-pulse's.)

Post reply on HN