Using Pipewire instead of Pulseaudio in Slackware 15

~red · 11-10-2021, 06:48 AM

Quote:

Originally Posted by LuckyCyborg

Well, this daemon supervisor is now part of Slackware -current, but probably would be nice to have it available for 14.2 via SBo, thought...

And honestly, it's right on a daemon supervisor, designed to work with the init scripts - it's not related to PipeWire at all.

BUT, it's developer added (on request) a feature which is really useful for us to handle the PipeWire daemons on user side: the ability to auto-quit on user logout.

However, even this particular feature added kindly at our request, has nothing to do with PipeWire. As well, you can control this way any daemons supposed to be controlled on the user side. e.g. a VPN service.

That's WHY I wonder if it's good to promote this mix of daemon supervisor with the PipeWire controls...

Rather, how about a package which ships those XDG autostart files and installation/uninstallation scripts to switch forth or back the PulseAudio setup and its autostart file?

BUT, probably the best would be to have a split of PulseAudio package on client libraries and tools, and a separate server package, e.g pulseaudio-server, which later could be not installed or blacklisted.

The seperate package was what I exactly thought about and wrote it at first actually, but doesn't it only increase packages / blacklist amount of packages?
I first packaged pipewire itself with these configs but well in term of speed and compatibility this is way better because only things I needed was client.conf.new and pipewire .desktop's, and mentioning exact "pipewire-pulse" daemon-binary at client.conf, you can also ignore removing pulseaudio.desktop although I don't know if this is case with everyone else too or not

Yet only packages I needed to blacklist were daemon and pulseaudio itself, because to prevent promoting new configs but I can choose not to apply them in every update but eh..

brobr · 11-10-2021, 08:16 AM

Quote:

Originally Posted by marav

Code:

l/libxml2-2.9.12-x86_64-5.txz:  Rebuilt.
  Applied upstream patch:
  [PATCH] Work around lxml API abuse.

Now compilation with your command worked at my end ;-)
(that is with the options I previously disabled, i.e. -Ddocs -Dtests -Dinstrospection, removed (default))

coralfang · 11-14-2021, 08:33 AM

Any advice for contents of /etc/asound.conf ?
Since the addition of pulseaudio to slackware previously, i've used this ever since:

Code:

# ALSA system-wide config file                                         	 
# By default, redirect to PulseAudio:                                    
pcm.default pulse                                                        
ctl.default pulse

However, after following the advice for setting up pipewire i'm getting some sound issues within some native applications (specifically games) where there is no audible sound output.

Does anyone know what asound.conf should contain to resolve this?

Here's output confirming i have pipewire setup correctly if any use:

Code:

> $ pactl info                                                       
Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 82
Tile Size: 65472
User Name: jigoku
Host Name: darkstar.local
Server Name: PulseAudio (on PipeWire 0.3.39)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_00_14.2.analog-stereo
Default Source: alsa_input.usb-046d_0825_9435FA20-02.mono-fallback
Cookie: a2c9:8a8e

enorbet · 11-14-2021, 06:51 PM

I'm not yet using Pipewire, but ev erything works on my box with both ALSA and Pulse with Pulse almost never used unless absolutely required.

My /etc/asound.conf is setup the ALSA way like this ...

Code:

 # ALSA system-wide config file
# By default, redirect to PulseAudio:
pcm.!default {
  type hw
  card II
  device "hw:0,0"
}
ctl.!default {
  type hw
  card II
}

Just use "aplay -l" to see how ALSA identifies your hardware.

I'm not certain this won't be needed with nor anathema to Pipewire, but it's a good start.

brobr · 11-15-2021, 08:38 AM

Sorry, my system is getting messed up atm (So obviously, I am not an expert). After attaching an usb-audio-device, things have gone weird. And not clear where/how to control settings.

Anyway, before I lost my devices or contact with pulse-audio (see below) I had comparable outputs for /etc/asound.conf and pactl info. A web-search suggested that some games (do all or just particular games give sound problems?) could get controlled via openal (see /etc/openal; `alsoft-config`); maybe they need setting to go through pulse??.

My soundmishap started last week; have removed all jack stuff to try to get back to a clean pipewire/puklse setup, but no luck....
(logging out and then in doesn't do anything; got pid's but it seems that things get blocked...the pulseaudiplugin icon in the systray is grayed out on logging in;.. and:

Code:

pactl info
Connection failure: Connection refused
...
bash-5.1$ for i in $(ls  ~/.run/*pid); do echo $i; cat $i ; done
/home/rob/.run/pipewire-media-session.pid
9833
/home/rob/.run/pipewire-pulse.clientpid
9867
/home/rob/.run/pipewire-pulse.pid
9865
/home/rob/.run/pipewire.clientpid
27258
/home/rob/.run/pipewire.pid
27249

And only the pulse-pid is in /run/user/1000/pulse;
before, there was a pipewire-0 in /run/user/1000, but that's not there anymore..)

Upon rebooting, stuff is going again, but gui-interface (PulseAudioPlugin) quite inconsistent; does not report running set up (or not helpful changing output from internal to audio-interface; works only via the mixer; all players set to pulse for audio-output)

0XBF · 11-16-2021, 03:46 PM

@brobr

Reverting from pipewire-jack should just require removing the symlinks, or if you used the ldconfig conf file, removing that and re-running ldconfig to restore the correct links to actual jack. It shouldn't affect the operation of the pipewire-pulse daemon however so I'm not sure what's going on there.

There's been a few suggestions throughout this thread for how to enable pipewire so you'll have to reverse whichever one you used. E.g. if you disabled pulseaudio autospawning, then you'll have to change that back in $HOME/.conifg/pulse/client.conf. If you deleted xdg autostart files and replaced with pipewire, same thing to reverse it. This is why I like using my script method from a profile script. Just have to comment out the starting of pipewire and it automatically reverts to pulseaudio.

Also on the subject of pipewire-jack, I still think its not on par with jack, both in performance and in convenience to configure, as you point out. I switched back to using jack instead of pipewire-jack again because I can push my audio interface down to smaller buffer sizes without xruns with jack, where pipewire-jack still gives occasional xruns. I don't know why since its the same system configuration in both cases but it would seem that pipewire-jack is still in need of some work.

------------------------------------------

Pipewire-pulse I've found no problems with using. I'm not sure why its breaking for some people like coralfang, but then I dont play too many games. The few that I do play I have been using the "conty" script, not the full multilib/wine setup. I'm also just using the default asound.conf that redirects audio to 'pulse' (or pipewire-pulse, which provides its own pulseaudio server), which is the same as what coralfang posted. Sorry I cant help much otherwise.

brobr · 11-16-2021, 06:48 PM

@0XBF Thanks a lot for the pointers.

Since pipewire-0.3.40 I have not been using jack (yet) with pipewire; but only pipewire with pulse (mainly to test the new audio-interface and how sound can be (re-)directed; now again through pavu-control, which seems to be fine again ;-).

The latency can be controlled via /etc/pipewire/jack.conf (from /usr/share/pipewire/jack.conf); this should enable the user to change settings that influence xruns, which can also be done per application;

Quote:

In the config file (i.e. jack.conf), you can set the node.latency property to something like 256/48000 to run all JACK applications at a 5.3ms latency or less

see: https://gitlab.freedesktop.org/pipew...CK#nodelatency, https://gitlab.freedesktop.org/pipew...pewire_latency, https://gitlab.freedesktop.org/pipew...k-applications

Did you try any of these options? The normally used buffer size of 1024 is not low enough to prevent xruns (if I understand it all correctly):

Quote:

If no client specifies a latency, a default is used:
default.clock.quantum = 1024

from https://gitlab.freedesktop.org/pipew...ng-buffer-size

Then of course there is this two-horned bit of info from https://gitlab.freedesktop.org/pipew...shooting#xruns

Quote:

There are 2 causes of xruns:

1.Application's can't complete the cycle in time. It can be because the kernel didn't wake them up in time or that they didn't get enough time allocated.
2.Driver timing are to tight. The driver is not woken up fast enough to keep the buffer filled.

1 can cause 2. 2 can be improved by adding more buffering (increasing headroom). Adding headroom does not improve 1.
With pw-top you can see what causes the xruns. If the application xruns are increasing, it's 1. If it's only the driver increasing xruns, it's 2. If both are increasing it's 1 causing 2.

The biggest problem a beginner in the sound-stuff, like me, encounters is that the information is sometimes not very clear.
(I do not understand above quote as terms 'increasing headroom', 'more buffering' seems difficult to translate to a setting say, lowering of the 1024 quantum)
And how the hierarchy of settings and programs works out in practice; what controls what is not obvious:

Quote:

Some applications (Ardour, guitarix, etc) have an option to change the buffer size with a menu option. (from the Config-PipeWire page)

Does the Ardour default take over from the jack.conf settings or is it overruled? That makes understanding/problem-solving not so easy (and one has to remember/trace all the changes that have been made to these settings).

Further, there is a suggestion that jack could take over from pipewire (at the very bottom of the Config-JACK page):

Quote:

PipeWire can function as a JACK client but this needs to be explicitly enabled in alsa-monitor.conf with alsa.jack-device = true.

But one gets very insecure what this all means/does when it says there, in /usr/share/pipewire/media-session.d/alsa-monitor.conf:

Code:

properties = {
    # Create a JACK device. This is not enabled by default because
    # it requires that the PipeWire JACK replacement libraries are
    # not used by the session manager, in order to be able to
    # connect to the real JACK server.
    #alsa.jack-device = false

    # Reserve devices.
    #alsa.reserve = true
}

Would this imply that the pipewire.jack module is not needed for pipewire to be run like this? (i.e. the current Slackware pipewire package next to jack from SBo without any re-/crosscompiling needed??)

Would this imply it would be possible to run all sound via Jack?
Would this mean that Jack always has to be on for sound in such a set-up, even this might be not very resource friendly?

There is no real info that answers these questions (or I have missed it..or misunderstood it completely)

The major hassle I would like to evade is that a sound device used by pipwire-pulse blocks jack and vice versa, which forces to close stuff (say when working with ardour) to check a web-video (showing ardour use..)

0XBF · 11-16-2021, 09:50 PM

Quote:

Originally Posted by brobr

The latency can be controlled via /etc/pipewire/jack.conf (from /usr/share/pipewire/jack.conf); this should enable the user to change settings that influence xruns, which can also be done per application;

see: https://gitlab.freedesktop.org/pipew...CK#nodelatency, https://gitlab.freedesktop.org/pipew...pewire_latency, https://gitlab.freedesktop.org/pipew...k-applications

Did you try any of these options? The normally used buffer size of 1024 is not low enough to prevent xruns (if I understand it all correctly):

from https://gitlab.freedesktop.org/pipew...ng-buffer-size

The buffer size of 1024/48000Hz is a safe default that jack and pipewire-jack use. Its too much latency to play a guitar through a simulated amp and listing back live IMO. I like to drop that down to 128 or 256 samples per buffer for playing and recording, which has the same latency as standing around 6 - 10 feet from an amp, depending on added hardware latency. Also this is getting down to the limits of my USB3 audio interface.

I've used both jack and pipewire-jack for this and I still get occasional xruns with pipewire-jack. The only difference is pipewire has a realtime module that controls priority so that could maybe be tweaked. Everything else is the same software, with the same config. I have a perfectly functioning and convenient setup with jack though so I'm sticking with that for now. I'll keep playing with pipewire for regular system audio.

Quote:

Originally Posted by brobr

The biggest problem a beginner in the sound-stuff, like me, encounters is that the information is sometimes not very clear.
(I do not understand above quote as terms 'increasing headroom', 'more buffering' seems difficult to translate to a setting say, lowering of the 1024 quantum)

I'm not sure what you already know about recording audio on linux or in general, but the "quantum" or "buffer" size sets how many samples are buffered (audio is communicated in "chunks" of samples), which is at the sample rate frequency. E.g. 256/48000 is 256 samples in a buffer, at a sample rate of 48000Hz (or 48000 samples per second). Dividing those numbers like that gives the time it takes to fill the buffer, which is the software latency. 256/48000 = 0.00533, or 5.33 milliseconds. This is better for recording with live playback, but more intensive on a system. If it cant keep up and fill the buffer in time, an xrun occurs. These create "pops" and glitches in the audio. Tweaks like using irq priorities for your audio hardware, realtime/preempt kernel, and other performance tweaks help to reduce these occurrences, but primarily it takes a decent audio interface with fast communications.

Eric Hameleers/AlienBob has some good articles on his blog for tweaking a slackware system for realtime audio performance. See here: https://alien.slackbook.org/blog/con...-use-as-a-daw/

I should also note that low latency only really matters for live monitoring while playing, where having too many milliseconds of delay throws your playing off. You can run everything else in jack at something more comfortable like 1024/48000 for things like programing midi or mixing tracks.

Quote:

Originally Posted by brobr

And how the hierarchy of settings and programs works out in practice; what controls what is not obvious:

Does the Ardour default take over from the jack.conf settings or is it overruled? That makes understanding/problem-solving not so easy (and one has to remember/trace all the changes that have been made to these settings).

If you run ardour while pipewire-jack is built and configured, ardour will just see it as a running jack server and connect. With a running jack server you cant change the settings for the buffer, sample rate, etc. in Ardour. I think you can change these things with the pipewire cli tools but I just edit the config and restartpipewire. This is part of why I find regular jack more convenient.

Ardour works nicely with either jack or pipewire-jack. I prefer routing audio on the mixer strips with ardour rather than the qjackctl graph.

Quote:

Originally Posted by brobr

Further, there is a suggestion that jack could take over from pipewire (at the very bottom of the Config-JACK page):

But one gets very insecure what this all means/does when it says there, in /usr/share/pipewire/media-session.d/alsa-monitor.conf:

Code:

properties = {
    # Create a JACK device. This is not enabled by default because
    # it requires that the PipeWire JACK replacement libraries are
    # not used by the session manager, in order to be able to
    # connect to the real JACK server.
    #alsa.jack-device = false

    # Reserve devices.
    #alsa.reserve = true
}

Would this imply that the pipewire.jack module is not needed for pipewire to be run like this? (i.e. the current Slackware pipewire package next to jack from SBo without any re-/crosscompiling needed??)

Would this imply it would be possible to run all sound via Jack?
Would this mean that Jack always has to be on for sound in such a set-up, even this might be not very resource friendly?

There is no real info that answers these questions (or I have missed it..or misunderstood it completely)

The major hassle I would like to evade is that a sound device used by pipwire-pulse blocks jack and vice versa, which forces to close stuff (say when working with ardour) to check a web-video (showing ardour use..)

I haven't tried out routing audio like that with pipewire but it sounds interesting. My guess would be it provides a pipewire "node" available in the graph of jack for routing audio from the system. Pulseaudio has jack modules as well which allow you to make connections in jacks graph (I think pulseaudio needs to be rebuilt against jack for this). That way you can route audio from a browser (just an example) in qjackctl while using jack for other audio as well. I try not to run browsers when recording audio though because they're resource hogs.

Also there isn't much harm in having jack always on, if the buffer is set to something non intensive like 1024/48000. I use my recording machine for work and gaming as well. I run jack at 1024/48000Hz for audio all day long, then just set lower buffer sizes if I'm playing around with a guitar or keyboard.

brobr · 11-17-2021, 01:14 PM

Thanks a lot for this. Eric's DAW-page is very helpful as well; at the moment stuck on its predecessor's (https://alien.slackbook.org/blog/exp...ic-production/) discussion section; very interesting. No need to reinvent the wheel, as usual ;-)

coralfang · 11-17-2021, 05:14 PM

Quote:

Originally Posted by enorbet

I'm not yet using Pipewire, but ev erything works on my box with both ALSA and Pulse with Pulse almost never used unless absolutely required.

My /etc/asound.conf is setup the ALSA way like this ...

Code:

 # ALSA system-wide config file
# By default, redirect to PulseAudio:
pcm.!default {
  type hw
  card II
  device "hw:0,0"
}
ctl.!default {
  type hw
  card II
}

Just use "aplay -l" to see how ALSA identifies your hardware.

I'm not certain this won't be needed with nor anathema to Pipewire, but it's a good start.

Apparently no changes from using that setup either. Maybe it's an issue with pipewire directly and not pulse/alsa configs, as the few games i'm having trouble with will play sound correctly when i revert back to just pulseaudio.

~red · 11-17-2021, 08:20 PM

Okay, I made it totally independed this time.
Thank you LuckyCyborg for this suggestion!

marav · 11-21-2021, 05:40 AM

Wireplumber ( pipewire-media replacement) slackbuild with the latest wireplumber 0.4.5 :

https://gitlab.com/maravtdm/slackwar...er/wireplumber

EDIT : moved here
https://gitlab.com/maravtdm/wireplumber-slackbuild.git

nobodino · 11-21-2021, 06:25 AM

@marav: tried to build it but...
---------------
Program glib-compile-resources found: YES (/usr/bin/glib-compile-resources)
Program python3 (sphinx, sphinx_rtd_theme, breathe, sphinx.ext.graphviz) found: NO modules: sphinx
Program python3 (lxml) found: YES (/usr/bin/python3) modules: lxml
Program doxygen found: YES 1.9.2 (/usr/bin/doxygen)

../docs/meson.build:34:0: ERROR: Running ['/usr/bin/sphinx-build', '--version'] failed

A full log can be found at /tmp/wireplumber-0.4.5/meson-build/meson-logs/meson-log.txt
----------------

marav · 11-21-2021, 07:07 AM

Quote:

Originally Posted by nobodino

@marav: tried to build it but...
---------------
Program glib-compile-resources found: YES (/usr/bin/glib-compile-resources)
Program python3 (sphinx, sphinx_rtd_theme, breathe, sphinx.ext.graphviz) found: NO modules: sphinx
Program python3 (lxml) found: YES (/usr/bin/python3) modules: lxml
Program doxygen found: YES 1.9.2 (/usr/bin/doxygen)

../docs/meson.build:34:0: ERROR: Running ['/usr/bin/sphinx-build', '--version'] failed

A full log can be found at /tmp/wireplumber-0.4.5/meson-build/meson-logs/meson-log.txt
----------------

I just compiled on my VM with a clean and up-to-date Slackware installation
With Lua 5.4.3 from Slackers repository

nothing to report

Code:

wireplumber 0.4.5

    Lua version                    : 5.4.3 (built-in)
    systemd conf data              : NO
    libsystemd                     : NO
    libelogind                     : YES

  For documentation
    Python 3 Sphinx related modules: NO
    Doxygen                        : YES
    sphinx-build                   : NO

  For introspection
    Python 3 lxml module           : NO
    Doxygen                        : YES
    g-ir-scanner                   : YES

  Subprojects
    lua                            : YES

Code:

...
Slackware package /tmp/wireplumber-0.4.5-x86_64-1.txz created.

marav · 11-21-2021, 07:46 AM

Quote:

Originally Posted by marav

Wireplumber ( pipewire-media replacement) slackbuild with the latest wireplumber 0.4.5 :

https://gitlab.com/maravtdm/slackwar...er/wireplumber

Moved here :

https://gitlab.com/maravtdm/wireplumber-slackbuild.git