Using Pipewire instead of Pulseaudio in Slackware 15
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hey
Wouldn't be the time for a new thread "wireplumber instead of pulse or pipewire" ?
With an end here : use Pat's scripts
hum
wireplumber is not a pipewire replacement
and for me, there is nothing left to say since wireplumber is now on SBo
all necessary information is here in this thread
do you see anything else to add ?
EDIT:
And FYI, I use wireplumber as media-session since the release of Fedora 35
First as a POC of my slackbuild
Then as it worked fine I stayed with it, but clearly, not using any specific configuration, I don't make any difference with pipewire-media-session
Highlights
- Improved graph reconfiguration.
- Extra configuration options for streams and filters with config
rules and environment variable.
- Improve module-pulse-tunnel latency, stability and error recovery.
- pw-top, pw-cli and pw-link improvements.
- Fix a channelmixer upmixing clipping issue.
- The ROC module has seen many improvements.
- Many more bugfixes and improvements.
Location: The Glorious People's Republic of Austin
Posts: 178
Rep:
Quote:
Originally Posted by coralfang
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.
I just figured out the problem with this, and it has to do with ALSA passing audio to the pulse device in the default asound.conf file. Most games that use FMOD for audio will run 'pulseaudio --check' to test whether the system uses Pulse, then fall back to ALSA if that test fails. Slackware's 'asound.conf' defaults to Pulse as well, and so the sound system fails to register the right devices. You can check if this is the case in your instance by symlinking pulseaudio to /bin/true, then trying to run your game (I put a symlink in /usr/local/bin, to minimize changes to system files).
The above will work, but it's effectively using the pulseaudio module for pipewire when it does not need to. I was able to successfully run games with working sound by redirecting ALSA directly to pipewire:
/etc/asound.conf:
Code:
# ALSA system-wide config file
# Fall back to Pipewire:
pcm.!default {
type pipewire
hint {
show on
description "Pipewire Sound Server"
}
}
ctl.!default {
type pipewire
}
Can you check whether that works for you too? This might be something to add to the enable/disable scripts.
Last edited by bl0tt0; 04-28-2022 at 11:06 PM.
Reason: wrong asound.conf file
On a related note to the last release, I just got note that Wim Taymans closed the issue I opened a year ago about pipewire not exiting when a user logs out. To quote him: "I think this is now implemented."... https://gitlab.freedesktop.org/pipew...0#note_1357938
I dont have any machines running -current at the moment (I will on the weekend). Can anybody confirm that? I.e. Run the pipewire daemons, without the daemon supervising program, and see if pipewire exits when you log out. I didnt see anything mentioning that change in pipewire's latest release so I want to know if that was actually fixed.
On a related note to the last release, I just got note that Wim Taymans closed the issue I opened a year ago about pipewire not exiting when a user logs out. To quote him: "I think this is now implemented."... https://gitlab.freedesktop.org/pipew...0#note_1357938
I dont have any machines running -current at the moment (I will on the weekend). Can anybody confirm that? I.e. Run the pipewire daemons, without the daemon supervising program, and see if pipewire exits when you log out. I didnt see anything mentioning that change in pipewire's latest release so I want to know if that was actually fixed.
I asked a friend to take a look into latest PipeWire 0.3.51 source code and he told that:
- there is no support for elogind, which is required for conversation with elogind, to find when the user logouts.
- there is support for a systemd units and a systemd feature named "service activation" which simplifies handling of the 3 daemons.
Unfortunatelly, does not look that the PipeWire developers did something with a vague resemblance with what PulseAudio do for handling its auto-quiting via (e)logind.
Probably Mr. Taymans refers to something happening on default usage with systemd. Zombie processes? Who knows...
Last edited by LuckyCyborg; 04-29-2022 at 03:47 PM.
I asked a friend to take a look into latest PipeWire 0.3.51 source code and he told that:
- there is no support for elogind, which is required for conversation with elogind, to find when the user logouts.
- there is support for a systemd units and a systemd feature named "service activation" which simplifies handling of the 3 daemons.
Unfortunatelly, does not look that the PipeWire developers did something with a vague resemblance with what PulseAudio do for handling its auto-quiting via (e)logind.
Probably Mr. Taymans refers to something happening on default usage with systemd. Zombie processes? Who knows...
Well nothing in the announce referred to any kind of functionality related to exiting or user sessions so I figured as much. I'll try tomorrow anyway but my hopes aren't high.
On a related note to the last release, I just got note that Wim Taymans closed the issue I opened a year ago about pipewire not exiting when a user logs out. To quote him: "I think this is now implemented."... https://gitlab.freedesktop.org/pipew...0#note_1357938
I dont have any machines running -current at the moment (I will on the weekend). Can anybody confirm that? I.e. Run the pipewire daemons, without the daemon supervising program, and see if pipewire exits when you log out. I didnt see anything mentioning that change in pipewire's latest release so I want to know if that was actually fixed.
I'm on 15.0 and pipewire exits when I log out. Using KDE and runlevel3+startx.
If I log out from the kde menu and then type logout from the shell, I can confirm pipewire daemons are no longer running from a root shell.
I'm on 15.0 and pipewire exits when I log out. Using KDE and runlevel3+startx.
If I log out from the kde menu and then type logout from the shell, I can confirm pipewire daemons are no longer running from a root shell.
If you used the enable-pipewire.sh script then that is the expected behaviour. The problem was that pipewire doesnt exit when a user logs out, so the 'daemon' program was added to supervise it. That script just sets it up automatically.
I had opened that issue before slackware added daemon to manage pipewire. I was hoping they fixed it so it would function similar to pulseaudio and exit on its own, without a supervising process. However, I just tested out a freshly updated current machine with pipewire 0.3.51 and it still leaves processes behind after logging out. In the end, we still need daemon to babysit pipewire.
If you used the enable-pipewire.sh script then that is the expected behaviour. The problem was that pipewire doesnt exit when a user logs out, so the 'daemon' program was added to supervise it. That script just sets it up automatically.
I had opened that issue before slackware added daemon to manage pipewire. I was hoping they fixed it so it would function similar to pulseaudio and exit on its own, without a supervising process. However, I just tested out a freshly updated current machine with pipewire 0.3.51 and it still leaves processes behind after logging out. In the end, we still need daemon to babysit pipewire.
I've never expected to be otherwise.
Last edited by LuckyCyborg; 04-30-2022 at 03:35 PM.
If you used the enable-pipewire.sh script then that is the expected behaviour. The problem was that pipewire doesnt exit when a user logs out, so the 'daemon' program was added to supervise it. That script just sets it up automatically.
I had opened that issue before slackware added daemon to manage pipewire. I was hoping they fixed it so it would function similar to pulseaudio and exit on its own, without a supervising process. However, I just tested out a freshly updated current machine with pipewire 0.3.51 and it still leaves processes behind after logging out. In the end, we still need daemon to babysit pipewire.
Well now I'm really confused. I don't have a script named "enable_pipewire.sh"
All I did was rotate the autostart files in /etc/xdg/autostart so that they launch with my DE. This only works for xdg compliant desktops, but as far as I can tell only 3 programs are getting run and their lifecycle is being managed appropriately.
Of course now that I look at the actual command I can see what it's doing...
Well now I'm really confused. I don't have a script named "enable_pipewire.sh"
All I did was rotate the autostart files in /etc/xdg/autostart so that they launch with my DE. This only works for xdg compliant desktops, but as far as I can tell only 3 programs are getting run and their lifecycle is being managed appropriately.
Of course now that I look at the actual command I can see what it's doing...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
