Live data from Hacker News

PipeWire 0.3.62

gitlab.freedesktop.org

61–70 of 98 posts

Re: PipeWire 0.3.62

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

When using recent packages (e.g. NixOS) it's become quite good in the last ~6-ish months. It switches automatically when I open zoom, which is very nice

Re: PipeWire 0.3.62

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

I usually just mount the remote drive with sshfs and play the audio locally.

This pulseaudio approach might work with pipewire too -- I haven't tested it but I love this text-mode audio player... https://mathr.co.uk/harry/#sound

Re: PipeWire 0.3.62

#63
post #60
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…

You are misunderstanding; I want to play audio on the remote machine, not on the local machine. The remote machine is running pipewire-pulse.

Re: PipeWire 0.3.62

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

[deleted]

Re: PipeWire 0.3.62

#65
post #63
post #60

Earlier quoted context omitted.

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

You are misunderstanding; I want to play audio on the remote machine, not on the local machine. The remote machine is running pipewire-pulse.

[deleted]

Re: PipeWire 0.3.62

#66
post #63
post #60

Earlier quoted context omitted.

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

You are misunderstanding; I want to play audio on the remote machine, not on the local machine. The remote machine is running pipewire-pulse.

Yes sorry, I figured it out before seeing your comment and edited my reply.

PULSE_SERVER=localhost or export $(dbus-launch) could work.

Re: PipeWire 0.3.62

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

Re: PipeWire 0.3.62

#68

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.

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'm not really sure what the difference between "ALSA just works" and "ALSA as configured by my distribution and including the DMIX plugin just works" is.

Like at the end of the day option 2 is still "ALSA just works".

Re: PipeWire 0.3.62

#69

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…

Ehhhh OSS is really not great, even v4. Re-using Unix file I/O functions for audio sounds clever, but falls apart pretty quickly in the real world. Even in the best case where you manage to shove every audio feature into open, read, write, and ioctl, it's never going to feel good to use (type safety...).

I don't mourn the loss of OSS.

Re: PipeWire 0.3.62

#70
post #39

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…

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

Well, yeah, since when pulse showed up and started breaking people's audio it effectively replaced alsa (even though they kind of operate at different layers). So if you didn't like that, of course the solution was to rip out Poettering's bugfest and revert to alsa. Thankfully at some point pulse stabilized a lot and in my experience tends to just work out of the box these days, but people tend to have their habits set by the early versions that were pushed out before they were ready.

Post reply on HN