PulseAudio 17.0 Released With A Few New Features

[F.Ultra]

The irony, in the context of PulseAudio.

Distros deciding to make something the new default is not them forcing any one to use it.

[roviq]

Oh, and I just moved from PulseAudio to Pipewire a couple of days ago, the transition was fine, I use mpv for video, audacious for music, both have pipewire outputs.

One thing that I really enjoy with Pipewire is having back the enhanced Bluetooth codecs, and out-of-the-box to boot, because I used a 3rd party plugin for Pulseaudio but was abandoned by the author due to Pipewire having better support and being the future.

Wayland though... I'm still waiting, and using X, probably for a couple of years at least.

[reba]

Nope still too early, PulseAudio works on the console without X or Wayland running, pipewire still cannot do that without problems.

Uh - yes it can!?

Just tested it myself because I couldn't believe your claim - and yes, I can totally play an mp3 from the boot tty without any X or wayland using pw-play.

NAME

pw-cat - Play and record media with PipeWire

SYNOPSIS

pw-cat [options] [FILE | -]
pw-play [options] [FILE | -]
pw-record [options] [FILE | -]
pw-midiplay [options] [FILE | -]
pw-midirecord [options] [FILE | -]
pw-dsdplay [options] [FILE | -]

DESCRIPTION

pw-cat is a simple tool for playing back or capturing raw or encoded media files on a PipeWire server.
It understands all audio file formats supported by libsndfile for PCM capture and playback.

It understands standard MIDI files for playback and recording.
This tool will not render MIDI files, it will simply make the MIDI events available to the graph.
You need a MIDI renderer such as qsynth, timidity or a hardware MIDI rendered to hear the MIDI.

DSD playback is supported with the DSF file format.
This tool will only work with native DSD capable hardware and will produce an error when no such hardware was found

When the FILE is - input and output will be from STDIN and STDOUT respectively.

It even automatically switched from speakers to the bluetooth headset once it switched in on. Magic on the tty.

So whoever voted you up learned something new today, too.

And why wouldn't it work? pipewire, wireplumber etc. have nothing to do with any display manager/etc. It's a separate service offering his services to any program that connects.

Maybe check if the services are up with:

systemctl --user status pipewire.service

And one of these (mutually exclusive, pipewire-media-session is still available but considered deprecated in favor to wireplumber):

​systemctl --user status wireplumber.service
systemctl --user status pipewire-media-session.service

[sobrus]

To be honest, I've been using PA since around 2011 and it always worked very well.
Actually I've got more problems (cracking sound etc) with "superior" Pipewire . Most software still use PA (even if they have Pipewire backend too).
It's a good solution unless you absolutely need low latency or bluetooth codecs.

Besides, I think PA is simpler to use and configure. Regular users need simple tools like pavucontrol, not qpwgraph or wire plumber, and 10 config files in 3 locations.

btw this is what helped me to (mostly) fix cracking sound with pipewire on my 5950x:

echo 2048 > /sys/class/rtc/rtc0/max_user_freq
echo 2048 > /proc/sys/dev/hpet/max-user-freq

(I have hpet disabled, so probably the first one works for me). This isn't either very intuitive, or easy to find out without arch wiki. and my machine isn't that old or exotic.

[markus40]

I switched over to pipewire on my laptops and Media PC/server right from the start. But had to switch back to Pulseaudio on my Media PC/server almost a year ago. After a release of pipewire the session manager switched to Wireplumber. Games and Kodi began to have an annoying tick every second on the HDMI output to my TV in the living room. I switch back to pipewire every time there is a new release. Tried a lot of 'solutions' in the configuration, like switching off suspend. But the tick continues. Pulseaudio doesn't have the same problem, so I'm glad it is still maintained.

[finalzone]

To be honest, I've been using PA since around 2011 and it always worked very well.
Actually I've got more problems (cracking sound etc) with "superior" Pipewire . Most software still use PA (even if they have Pipewire backend too).
It's a good solution unless you absolutely need low latency or bluetooth codecs.

Besides, I think PA is simpler to use and configure. Regular users need simple tools like pavucontrol, not qpwgraph or wire plumber, and 10 config files in 3 locations.

btw this is what helped me to (mostly) fix cracking sound with pipewire on my 5950x:

echo 2048 > /sys/class/rtc/rtc0/max_user_freq
echo 2048 > /proc/sys/dev/hpet/max-user-freq

(I have hpet disabled, so probably the first one works for me). This isn't either very intuitive, or easy to find out without arch wiki. and my machine isn't that old or exotic.

On which distribution and what hardware such cracking problem occurred with Pipewire? It seems like an user configuration error.

[curfew]

It's so childish to start a news article about PulseAudio by disregarding PA and advertising Pipewire in the very first sentence.

[sobrus]

It was on Manjaro stable, playing on a monitors connected to RX6800XT via displayport.

Honestly, I don't remember if it was only when playing thru both displays at once (combine sink) or just one too.
I also have line out and bluetooth headphones connected, but I don't remember if they were affected as well - don't use them often.

Of course it may be config error, especially with combine sink, as this is what I use the most and it's the only thing I've changed.
I always try to do as little changes in default config files as possible.

pipewire.conf - two alsa pcm sinks (because pipewire doesn't see both displayports at once without it)

    
{ factory = adapter
        args = {
            factory.name           = api.alsa.pcm.sink
            node.name              = "hdmisink1"
            node.description       = "DP1"
            media.class            = "Audio/Sink"
            api.alsa.path          = "hw:0,3"
            audio.channels         = 2
            audio.position         = "FL,FR"
        }
    }
    
    { factory = adapter
        args = {
            factory.name           = api.alsa.pcm.sink
            node.name              = "hdmisink2"
            node.description       = "DP2"
            media.class            = "Audio/Sink"
            api.alsa.path          = "hw:0,10"
            audio.channels         = 2
            audio.position         = "FL,FR"
        }
    }

​

And the combine sink:

 {  
name = libpipewire-module-combine-stream
    args = {
        combine.mode = sink
        node.name = "DP_display"
        node.description = "DP_Combined"
        combine.props = {
            audio.position = [ FL FR ]
        }
        stream.rules = [
            {
                matches = [
                    {
                        node.name = "hdmisink1"
                        media.class = "Audio/Sink"
                    }
                    {
                        node.name = "hdmisink2"
                        media.class = "Audio/Sink"
                    }
                ]
                actions = {
                    create-stream = {
                    }
                }
            }
        ]
    }

As far as I remember, no other changes to default config files.
Cracking occured both when combining on pipewire-pulse side (like on pure PA) and pipewire side.

[guglovich]

Too bad even something this outdated is hard to put on Void Linux.

[J.King]

Besides, I think PA is simpler to use and configure. Regular users need simple tools like pavucontrol, not qpwgraph or wire plumber, and 10 config files in 3 locations.

As long as you have pipewire-pulse installed (which I expect most people will for some time) you can continue to use pavucontrol. It works entirely seamlessly, in my experience. And, yes, as a mere mortal I'm glad it's there.