[SOLVED] How Do I Get The Pipewire Pulseaudio Compatibility To Work in Fedora 39?
FedoraThis forum is for the discussion of the Fedora Project.
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.
How Do I Get The Pipewire Pulseaudio Compatibility To Work in Fedora 39?
Esteemed Colleagues,
On my Fedora 39 system, the pipewire packages are installed, and the
pulseaudio packages -- which are incompatible with the pipewire
packages -- are not:
The mpv command (which defaults, as it should, to "mpv -ao=pulse")
fails, for failure to connect to a pulseaudio server.
The pipewire-pulse command claims to start, in the words of its manual
page, "a drop-in replacement for the PulseAudio daemon". It does not:
$ pipewire-pulse -v
[E][25431.837538] mod.protocol-pulse | [ utils.c: 45 get_runtime_dir()] could not find a suitable runtime directory in$PULSE_RUNTIME_PATH and $XDG_RUNTIME_DIR
[W][25431.837628] mod.protocol-pulse | [ server.c: 998 servers_create_and_start()] pulse-server 0x5630c09d25d0: failed to parse address 'unix:native': No such file or directory
[E][25431.837694] mod.protocol-pulse | [ pulse-server.c: 5542 pw_protocol_pulse_new()] 0x5630c09d25d0: no servers could be started: No such file or directory
[E][25431.838072] pw.conf | [ conf.c: 573 load_module()] 0x5630c099fb60: could not load mandatory module "libpipewire-module-protocol-pulse": No such file or directory
[E][25431.839121] default | [ pipewire.c: 105 main()] failed to create context: No such file or directory
$
I can hear sound by invoking mpv with the "--audio-device=alsa/hdmi"
argument, but that is bogus. The audio device should be configured in
pulseaudio, not specified every time one needs to use audio.
Moreover, there are programs like firefox (and perhaps others) in
which the audio device cannot be specified, and pulseaudio is assumed.
I can install the pulseaudio packages, but only by removing the
pipewire packages. This is what I have done on many of my other
systems, and it works. But, because pipewire is supposed to be so
bloody wonderful, I want to figure out how to use it, starting with my
Fedora 39 system on which it is installed by default. So how do I get
pipewire-pulse to work?
As always, thank you in advance for any and all replies.
Esteemed Colleagues,
On my Fedora 39 system, the pipewire packages are installed, and the pulseaudio packages -- which are incompatible with the pipewire packages -- are not:
The mpv command (which defaults, as it should, to "mpv -ao=pulse") fails, for failure to connect to a pulseaudio server. The pipewire-pulse command claims to start, in the words of its manual page, "a drop-in replacement for the PulseAudio daemon". It does not:
Code:
$ pipewire-pulse -v
[E][25431.837538] mod.protocol-pulse | [utils.c: 45 get_runtime_dir()] could not find a suitable runtime directory in$PULSE_RUNTIME_PATH and $XDG_RUNTIME_DIR
[W][25431.837628] mod.protocol-pulse | [server.c: 998 servers_create_and_start()] pulse-server 0x5630c09d25d0: failed to parse address 'unix:native': No such file or directory
[E][25431.837694] mod.protocol-pulse | [pulse-server.c: 5542 pw_protocol_pulse_new()] 0x5630c09d25d0: no servers could be started: No such file or directory
[E][25431.838072] pw.conf | [conf.c: 573 load_module()] 0x5630c099fb60: could not load mandatory module "libpipewire-module-protocol-pulse": No such file or directory
[E][25431.839121] default | [pipewire.c: 105 main()] failed to create context: No such file or directory
I can hear sound by invoking mpv with the "--audio-device=alsa/hdmi" argument, but that is bogus. The audio device should be configured in pulseaudio, not specified every time one needs to use audio. Moreover, there are programs like firefox (and perhaps others) in which the audio device cannot be specified, and pulseaudio is assumed. I can install the pulseaudio packages, but only by removing the pipewire packages. This is what I have done on many of my other systems, and it works. But, because pipewire is supposed to be so bloody wonderful, I want to figure out how to use it, starting with my Fedora 39 system on which it is installed by default. So how do I get pipewire-pulse to work?
As always, thank you in advance for any and all replies.
Did you read/think about what you posted?? You start by saying you don't have pulseaudio installed...and are surprised you can't play sound through pipewire-to-pulseaudio??? Some easily-found commands (did you do any research??)
Code:
Use pulseaudio: sudo dnf swap --allowerasing pipewire-pulseaudio pulseaudio
Use pipewire: sudo dnf swap --allowerasing pulseaudio pipewire-pulseaudio
You have to reboot to stop/start the services (did you do this??)
I have both /usr/bin/pipewire and /usr/bin/pipewire-pulse started by systemd
from which I understand that pipewire-pulse is not, as its documentation
incorrectly states, a "drop-in replacement for the PulseAudio daemon",
inasmuch as pulseaudio is not started by systemd, one types "pulseaudio --start"
on the command line.
This led to a search for the systemd service that must be started in
order to invoke those commands. Thus:
These files, instead of residing underneath the system subdirectory
of the systemd directory, reside underneath the user subdirectory,
which I did not know, until now, existed.
It appears from the documentation that one is expected to invoke
such services in the following 3-step procedure:
This does not, however, work, so I must be missing something:
Code:
$ systemctl --user enable pipewire
Failed to enable unit: Process org.freedesktop.systemd1 exited with status 1
$
As you can see, I did not get past the first step of the
3-step procedure. Also, before doing the above, I installed
all of the packages that you listed in your post (even ones
that I was sure I did not need, like kde-settings-pulseaudio).
Nonetheless, the command failed, as you can see from the above.
What is the correct way to obtain functionality from this
soi-disant "drop-in replacement for the PulseAudio daemon"?
As always, thank you in advance for any and all replies.
In particular, even replies containing personal attacks are welcome,
if they contain useful information.
You wrote:
I have both /usr/bin/pipewire and /usr/bin/pipewire-pulse started by systemd
from which I understand that pipewire-pulse is not, as its documentation incorrectly states, a "drop-in replacement for the PulseAudio daemon", inasmuch as pulseaudio is not started by systemd, one types "pulseaudio --start" on the command line. This led to a search for the systemd service that must be started in order to invoke those commands. Thus:
These files, instead of residing underneath the system subdirectory of the systemd directory, reside underneath the user subdirectory, which I did not know, until now, existed.
It appears from the documentation that one is expected to invoke such services in the following 3-step procedure:
This does not, however, work, so I must be missing something:
Code:
$ systemctl --user enable pipewire
Failed to enable unit: Process org.freedesktop.systemd1 exited with status 1
As you can see, I did not get past the first step of the 3-step procedure. Also, before doing the above, I installed all of the packages that you listed in your post (even ones
that I was sure I did not need, like kde-settings-pulseaudio). Nonetheless, the command failed, as you can see from the above. What is the correct way to obtain functionality from this soi-disant "drop-in replacement for the PulseAudio daemon"?
As always, thank you in advance for any and all replies. In particular, even replies containing personal attacks are welcome, if they contain useful information.
Apparently you are still ignoring things; you were handed two commands that perform things you want to do, along with a link with scripts to go back and forth. Did you read those things??? Try them?? You *STILL* don't answer the question of "did you reboot?" either. You seem to post things and ignore good bits of what you're told, on the rare occasions you follow up. The fact you've been asked things and not followed up many times, and seemingly don't do much research or pay attention to what you're told isn't a 'personal attack'...it's a fact, and it's plain rude.
You were given commands and seemingly ignored them; you were given a link with scripts and seemingly ignored IT too. If you don't install the packages, you can't start them.
It seems that the original poster ("OP") failed to make himself
clear, when he wrote:
I can install the pulseaudio packages, but only by removing the
pipewire packages. This is what I have done on many of my other
systems, and it works. But, because pipewire is supposed to be so
bloody wonderful, I want to figure out how to use it, starting with my
Fedora 39 system on which it is installed by default. So how do I get
pipewire-pulse to work?
The "dnf swap" command, which was recommended in response to the
above, installs the pulseaudio packages, and removes the pipewire
packages. It is thus hard to understand how it can be proposed
as an answer to the OP's question. The OP asked how to obtain
sound from the pipewire packages; he had already indicated his
awareness that one can obtain sound by uninstalling the pipewire
packages, and installing the pulseaudio packages. But apparently
he failed to express himself clearly.
Fedora 39, which presumably is intended to be functional after it
has been installed, comes with the pipewire packages by default.
The pipewire packages include a program called "pipeware-pulse"
which purports to be "a drop-in replacement for the PulseAudio
daemon". "Drop-in replacement" means that programs like mpv and
firefox which formerly obtained sound from pulseaudio can obtain
sound in the same way from pipewire-pulse instead. The OP's
question was: How does one successfully invoke the "pipewire-pulse"
command? Invoking it from the command line, as one invokes
"pulseaudio --start" from the command line, failed. Apparently
it must not be invoked from the command line, but, rather,
from systemd. How is that done? The "systemctl --user enable pipewire"
command fails. Also, although not explicitly stated in the
earlier post, the command "systemctl --user start pipewire",
the command "systemctl --user enable pipewire-pulse", and the
command "systemctl --user start pipewire-pulse", all fail, all
with the error message "Process org.freedesktop.systemd1 exited with status 1".
How does one successfully invoke the "pipewire-pulse" command
on Fedora 39? All replies will be greatly appreciated, and will
be carefully read.
It seems that the original poster ("OP") failed to make himself clear, when he wrote:
I can install the pulseaudio packages, but only by removing the
pipewire packages. This is what I have done on many of my other
systems, and it works. But, because pipewire is supposed to be so
bloody wonderful, I want to figure out how to use it, starting with my
Fedora 39 system on which it is installed by default. So how do I get
pipewire-pulse to work?
The "dnf swap" command, which was recommended in response to the above, installs the pulseaudio packages, and removes the pipewire packages. It is thus hard to understand how it can be proposed as an answer to the OP's question. The OP asked how to obtain sound from the pipewire packages; he had already indicated his awareness that one can obtain sound by uninstalling the pipewire packages, and installing the pulseaudio packages. But apparently he failed to express himself clearly.
Fedora 39, which presumably is intended to be functional after it has been installed, comes with the pipewire packages by default. The pipewire packages include a program called "pipeware-pulse" which purports to be "a drop-in replacement for the PulseAudio daemon". "Drop-in replacement" means that programs like mpv and firefox which formerly obtained sound from pulseaudio can obtain sound in the same way from pipewire-pulse instead. The OP's question was: How does one successfully invoke the "pipewire-pulse" command? Invoking it from the command line, as one invokes
"pulseaudio --start" from the command line, failed. Apparently it must not be invoked from the command line, but, rather, from systemd. How is that done? The "systemctl --user enable pipewire" command fails. Also, although not explicitly stated in the earlier post, the command "systemctl --user start pipewire", the command "systemctl --user enable pipewire-pulse", and the command "systemctl --user start pipewire-pulse", all fail, all with the error message "Process org.freedesktop.systemd1 exited with status 1".
How does one successfully invoke the "pipewire-pulse" command on Fedora 39? All replies will be greatly appreciated, and will be carefully read.
Carefully read, perhaps...understood doesn't seem likely. And your condescending manner in responding with things like "the OP failed to make himself clear" certainly doesn't give many folks reason to want to try to help you, as you did before with your snark about removing your email address from your posts a while back.
You were asked to run two commands by smallpond: "pactl info" and "rpm -qa |grep -e pipe -e pulse"; if you 'carefully read' that post, you'd have run those commands and posted the output. You apparently did not, and smallpond even gave you a list of the relevant packages. Again, if you are missing packages, things *WILL NOT WORK* and *WILL NOT START*...can't be more clear than that, and your own errors that you posted indicate things are missing. Many threads deal with this exact issue...again, you appear to not bother looking despite your many years being here and using Linux:
Code:
List things necessary:
dnf list pipewire pipewire-alsa pipewire-jack-audio-connection-kit pipewire-pulseaudio wireplumber
Install things if needed:
dnf install pipewire pipewire-alsa pipewire-jack-audio-connection-kit pipewire-pulseaudio wireplumber
dnf will either install any that aren't installed and skip any that are already installed. If you're missing any others from the list smallpond gave, install THEM too.
If you 'read carefully' the package list, you'll see "pipewire-pulseaudio"...now if you think carefully about your subject line of "...pipewire pulseaudio compatability to work...", you need BOTH.
Every one of those packages (except for pipewire-jack-audio-connection-kit,
of which more will be said later) was already installed. In particular,
the pipewire-pulseaudio package was already installed. I apologize that
that fact was (apparently) not obvious; but, inasmuch as the pipewire-pulse
command is part of the pipewire-pulseaudio package, the pipewire-pulseaudio
package would have to have been already installed, before the first article
in this thread was written, otherwise the invocation of "pipewire-pulse -v"
would have produced a "command not found" diagnostic, rather than the
5-line error message that was presented there.
The pipewire-jack-audio-connection-kit package was not installed, because
it was incompatible with the already-installed jack-audio-connection-kit
package. The "dnf install" command required a "--allowerasing" argument
to install it. I was skeptical that replacing the jack-audio-connection-kit
package with the pipewire-jack-audio-connection-kit package would make any
difference, but I replaced the jack-audio-connection-kit package with the
pipewire-jack-audio-connection-kit package, and it did not make any
difference. Invoking the "pipewire-pulse" command from the command line
still fails with the same error message as before, and the four "systemctl --user"
commands that failed before, still fail, with the same error message as before.
There was an implied request for the output of "rpm -qa |grep -e pipe -e pulse"
and of "pactl info". Here is the output of the former command:
which is exactly what one would expect if there is no pipewire
command running with my user identification number -- and,
indeed, there is not; an invocation of that command from the
command line fails with an error message similar to the
error message produced by a command-line invocation of pipewire-pulse:
Code:
$ pipewire
[E][91949.442586] mod.protocol-native | [module-protocol-: 716 init_socket_name()] server 0x5555e7d53300: name pipewire-0 is not an absolute path and no runtime dir found. Set one of PIPEWIRE_RUNTIME_DIR, XDG_RUNTIME_DIR or USERPROFILE in the environment
[E][91949.443406] pw.conf | [ conf.c: 577 load_module()] 0x5555e7d2db70: could not load mandatory module "libpipewire-module-protocol-native": No such file or directory
[E][91949.444726] default | [ pipewire.c: 105 main()] failed to create context: No such file or directory
$
Clearly, a successful invocation of the pipewire program depends on
conditions beyond those required by the pulseaudio program, which
required no conditions at all, one could simply type "pulseaudio --start"
on the command line, and it would start. However, there is at least
one reader of this thread who has successfully run both pipewire and
pipewire-pulse "started by systemd". How is this done? As always, I
shall be grateful for any and all replies, and all replies will be read
carefully.
I agree things used to be much simpler before systemd made our lives so wonderful. It turns out there are a bunch of services. The ones in /etc/systemd/user that you found pointed me to four more:
It looks like the services are enabled by default in Fedora and started by entering the session. For me, that's X-Windows/KDE as not all my applications run in Wayland and I'm not a Gnome fan but that shouldn't matter to pipewire. The only dependencies I can see are that dbus works, pulseaudio is not enabled, and $XDG_RUNTIME_DIR is defined (for me it is /run/user/1000/).
Every one of those packages (except for pipewire-jack-audio-connection-kit, of which more will be said later) was already installed. In particular, the pipewire-pulseaudio package was already installed. I apologize that that fact was (apparently) not obvious; but, inasmuch as the pipewire-pulse command is part of the pipewire-pulseaudio package, the pipewire-pulseaudio package would have to have been already installed, before the first article in this thread was written, otherwise the invocation of "pipewire-pulse -v" would have produced a "command not found" diagnostic, rather than the 5-line error message that was presented there.
The pipewire-jack-audio-connection-kit package was not installed, because it was incompatible with the already-installed jack-audio-connection-kit package. The "dnf install" command required a "--allowerasing" argument to install it. I was skeptical that replacing the jack-audio-connection-kit package with the pipewire-jack-audio-connection-kit package would make any difference, but I replaced the jack-audio-connection-kit package with the pipewire-jack-audio-connection-kit package, and it did not make any difference. Invoking the "pipewire-pulse" command from the command line still fails with the same error message as before, and the four "systemctl --user" commands that failed before, still fail, with the same error message as before.
There was an implied request for the output of "rpm -qa |grep -e pipe -e pulse" and of "pactl info". Here is the output of the former command:
which is exactly what one would expect if there is no pipewire command running with my user identification number -- and, indeed, there is not; an invocation of that command from the command line fails with an error message similar to the error message produced by a command-line invocation of pipewire-pulse:
Code:
$ pipewire
[E][91949.442586] mod.protocol-native | [module-protocol-: 716 init_socket_name()] server 0x5555e7d53300: name pipewire-0 is not an absolute path and no runtime dir found. Set one of PIPEWIRE_RUNTIME_DIR, XDG_RUNTIME_DIR or USERPROFILE in the environment
[E][91949.443406] pw.conf | [ conf.c: 577 load_module()] 0x5555e7d2db70: could not load mandatory module "libpipewire-module-protocol-native": No such file or directory
[E][91949.444726] default | [ pipewire.c: 105 main()] failed to create context: No such file or directory
Clearly, a successful invocation of the pipewire program depends on conditions beyond those required by the pulseaudio program, which required no conditions at all, one could simply type "pulseaudio --start" on the command line, and it would start. However, there is at least one reader of this thread who has successfully run both pipewire and pipewire-pulse "started by systemd". How is this done? As always, I shall be grateful for any and all replies, and all replies will be read carefully.
The commands weren't 'implied'..they were given to you as diagnostic steps, so having to explicitly tell someone who 'reads carefully' to execute them seems superfluous. You're missing three packages from the list, if they escaped your notice: kpipewire, pulseaudio-qt, and pipewire-codec-aptx. May not make a difference, but cannot hurt to make sure things are the same, since someone else has this working and you do not. You were also asked specifically if you rebooted after doing such things, but have yet to answer. You were given commands (dnf swap), but don't bother posting the exact output of such things past a snotty "It is thus hard to understand how it can be proposed as an answer to the OP's question". If you're not going to post the results of commands, why bother asking people to try to help you???
The "pulseaudio-qt" package was already installed, as shown earlier.
The "pipewire-codec-aptx" and "kpipewire" packages have now also been
installed.
I don't think that systemd, and the wonderful lives to which its
adoption has led, is to blame. Or if it is to blame, it is not
entirely to blame. On Linux distributions that have systemd -- which
is most of them -- the "pulseaudio --start" command works. The
adoption of systemd has not impaired its functionality. However, the
so-called "drop-in replacement" for pulseaudio is not working.
Presumably it can be made to work if certain unknown conditions --
upon which pulseaudio does not depend, but upon which its "drop-in
replacement" does, apparently, depend -- are met. One reader of this
thread has suggested that these conditions are: that dbus works,
pulseaudio is not enabled, and $XDG_RUNTIME_DIR is defined. I tested
that hypothesis: I launched dbus, and defined XDG_RUNTIME_DIR;
pulseaudio is certainly not enabled, it is not even installed. I then
invoked all of the systemctl commands that had recently been
suggested. Every single one still fails, in the same way as before:
Code:
$ eval `dbus-launch --auto-syntax`
$ mkdir /tmp/bogus
$ chmod 700 /tmp/bogus
$ export XDG_RUNTIME_DIR=/tmp/bogus
$ systemctl status --user default.target
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user pipewire.service
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user pipewire.socket
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user pipewire-pulse.service
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user pipewire-pulse.socket
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl --user restart pipewire.socket pipewire-pulse
Failed to restart pipewire.socket: Process org.freedesktop.systemd1 exited with status 1
See user logs and 'systemctl --user status pipewire.socket' for details.
Failed to restart pipewire-pulse.service: Process org.freedesktop.systemd1 exited with status 1
See user logs and 'systemctl --user status pipewire-pulse.service' for details.
However, some progress has been made. Or perhaps "progress" is the
wrong word. But there has been a change. The "pipewire" and
"pipewire-pulse" command can now be invoked manually, and they do not
immediately fail. But they still don't work. The "pactl" command has
no knowledge of any of the audio devices, even though the "id" command
clearly shows that the user is in the "audio" group and has access to
the audio devices (but this was already known when the first article
in this thread was posted, because the user is able to play sound with
"mpv -audio-device=alsa/hdmi", a command that is repeated below to
contrast its successful behavior with the unsuccessful behavior of
"mpv -ao=pulse"):
So, the "pipewire" and "pipewire-pulse" commands can now be invoked.
How do we get them to work? As always, thank you in advance for any
and all replies.
The "mpv -ao=pulse" command now produces sound on my Fedora 39 system.
It is now also possible to get sound from firefox (which, as far as I
can tell, assumes PulseAudio output, and cannot be configured
otherwise -- please correct me if I am wrong). After posting this
message, I shall mark this thread as solved. However, I will still
appreciate any replies that will solve the "systemctl --user" problem.
Every single "systemctl --user" command that has been suggested here
continues to fail, with an error message that is a variation on the
theme of "Process org.freedesktop.systemd1 exited with status 1".
But it is possible to get pipewire-pulse to work without it. This is
what one must do: The XDG_RUNTIME_DIR environment variable (it is
possible that other environment variables will also work) must be set
in three programs: pipewire, pipewire-pulse, and wireplumber
("wireplumber" is the program that was missing in the previous
example, posted yesterday afternoon). Those three processes must have
the same user identification number ("uid"), and the value of the
XDG_RUNTIME_DIR variable must be the name of a directory that is owned
by the same uid, with 700 permissions. If these conditions are met,
then pipewire, pipewire-pulse, and wireplumber can be invoked
manually, otherwise they will fail. In particular, it does not appear
that dbus is necessary.
The selinux label of all three of those programs, after I invoked
them, was "system_u:system_r:unconfined_service_t", which allows
access to any directory. If anyone figures out how to invoke those
three programs with "systemctl --user", I do not know what their
selinux labels would be under those circumstances, and it is possible
that it would impose conditions on the directory named by the
XDG_RUNTIME_DIR variable.
The program requesting sound must also have the XDG_RUNTIME_DIR
environment variable set to the same value, and must have the same
uid. These conditions expose, as a lie, the assertion that
pipewire-pulse is a "drop-in replacement" for PulseAudio, as the
"pulseaudio" program does not impose those conditions on its clients.
The "pacmd" program is not available (but I had known that in
advance), so one must use the "pactl" program to obtain its
functionality, to the extent that one can. Thus instead of typing
"pacmd set-default-sink 1", one types "pactl set-default-sink 50"
(the sink and source numbers are different). Often the pactl options
are different from the corresponding pacmd options (e.g., one types
"pactl list sinks" instead of "pacmd list-sinks").
The functionality of "pipewire-pulse" as a network server has not been
tested. Here is what is known at this point: the three programs
"pipewire", "pipewire-pulse", and "wireplumber" do not bind to any
network sockets when they are first invoked, as evidence by a
subsequent invocation of "netstat -nap" (but there are an astonishing
number of Unix-domain sockets). If you type "pactl load-module
module-native-protocol-tcp" then the "netstat -nap" command will
report that "pipewire-pulse" is now listening on TCP port 4713, for
both IPv4 and IPv6. If we now assume, for purposes of this example,
that this program is running on a machine with IP address 1.2.3.4,
presumably a program running on another computer can set the
PULSE_SERVER environment variable to "1.2.3.4" to obtain sound from
the sound server. It might, however, be necessary to use syntax
similar to "tcp:1.2.3.4:4713", because presumably the port would not
be 4713, and would therefore have to be explicitly specified using
that alternate syntax in the PULSE_SERVER variable on the client
machine, if a "pipewire-pulse" program owned by a different user had
already bound a socket to port 4713. This might be problematic,
though, because on a Fedora system, after a typical installation, only
TCP port 4713, and UDP port 4713, have the "pulseaudio_port_t" label.
None of this has been tested; and I hope that there will be replies to
this posting (despite my having marked it as solved) that will report
on the success or failure of such tests. Presumably the readers of
this thread know that a Fedora system, after a typical installation,
has "firewalld" enabled, and therefore it might be necessary to invoke
"firewall-cmd --add-port=4713/tcp", depending on how the firewall has
been set up, before testing whether the system can function as a sound
server.
Esteemed Colleagues:
The "mpv -ao=pulse" command now produces sound on my Fedora 39 system. It is now also possible to get sound from firefox (which, as far as I can tell, assumes PulseAudio output, and cannot be configured otherwise -- please correct me if I am wrong). After posting this message, I shall mark this thread as solved. However, I will still appreciate any replies that will solve the "systemctl --user" problem. Every single "systemctl --user" command that has been suggested here continues to fail, with an error message that is a variation on the theme of "Process org.freedesktop.systemd1 exited with status 1".
And again, you don't post exactly what you're typing in or what the exact error(s)/message(s) are, but somehow expect us to be able to help. From one of the links you were given that you said you were going to "carefully read":
But it is possible to get pipewire-pulse to work without it. This is what one must do: The XDG_RUNTIME_DIR environment variable (it is possible that other environment variables will also work) must be set in three programs: pipewire, pipewire-pulse, and wireplumber ("wireplumber" is the program that was missing in the previous example, posted yesterday afternoon). Those three processes must have the same user identification number ("uid"), and the value of the XDG_RUNTIME_DIR variable must be the name of a directory that is owned by the same uid, with 700 permissions. If these conditions are met, then pipewire, pipewire-pulse, and wireplumber can be invoked manually, otherwise they will fail. In particular, it does not appear that dbus is necessary.
So you mean the wireplumber package, that was *GIVEN TO YOU IN POST #7* (including a single command to INSTALL anything wasn't there), was missing??? The one you said in post #8 that was present when you stated, "Every one of those packages (except for pipewire-jack-audio-connection-kit, of which more will be said later) was already installed"??
Did you 'carefully read' post #7???
Quote:
The selinux label of all three of those programs, after I invoked them, was "system_u:system_r:unconfined_service_t", which allows access to any directory. If anyone figures out how to invoke those three programs with "systemctl --user", I do not know what their selinux labels would be under those circumstances, and it is possible that it would impose conditions on the directory named by the XDG_RUNTIME_DIR variable.
The program requesting sound must also have the XDG_RUNTIME_DIR environment variable set to the same value, and must have the same uid. These conditions expose, as a lie, the assertion that pipewire-pulse is a "drop-in replacement" for PulseAudio, as the "pulseaudio" program does not impose those conditions on its clients. The "pacmd" program is not available (but I had known that in advance), so one must use the "pactl" program to obtain its functionality, to the extent that one can. Thus instead of typing "pacmd set-default-sink 1", one types "pactl set-default-sink 50" (the sink and source numbers are different). Often the pactl options are different from the corresponding pacmd options (e.g., one types "pactl list sinks" instead of "pacmd list-sinks").
The functionality of "pipewire-pulse" as a network server has not been tested. Here is what is known at this point: the three programs "pipewire", "pipewire-pulse", and "wireplumber" do not bind to any network sockets when they are first invoked, as evidence by a subsequent invocation of "netstat -nap" (but there are an astonishing
number of Unix-domain sockets). If you type "pactl load-module module-native-protocol-tcp" then the "netstat -nap" command will report that "pipewire-pulse" is now listening on TCP port 4713, for both IPv4 and IPv6. If we now assume, for purposes of this example, that this program is running on a machine with IP address 1.2.3.4, presumably a program running on another computer can set the PULSE_SERVER environment variable to "1.2.3.4" to obtain sound from the sound server. It might, however, be necessary to use syntax
similar to "tcp:1.2.3.4:4713", because presumably the port would not be 4713, and would therefore have to be explicitly specified using that alternate syntax in the PULSE_SERVER variable on the client machine, if a "pipewire-pulse" program owned by a different user had already bound a socket to port 4713. This might be problematic, though, because on a Fedora system, after a typical installation, only TCP port 4713, and UDP port 4713, have the "pulseaudio_port_t" label. None of this has been tested; and I hope that there will be replies to this posting (despite my having marked it as solved) that will report on the success or failure of such tests. Presumably the readers of this thread know that a Fedora system, after a typical installation, has "firewalld" enabled, and therefore it might be necessary to invoke "firewall-cmd --add-port=4713/tcp", depending on how the firewall has been set up, before testing whether the system can function as a sound server.
Again, you fail to mention having selinux enabled, or your need/desire to use things as a network sound server, yet somehow expect us to be able to assist. When you're given commands to run and don't run them, don't give details, and change the story later on, it doesn't give most folks any desire to try to help.
You're getting the --user problems because of selinux, and adjusting the service and/or selinux to allow pipewire can be done (there are how-to guides you can look up yourself).
The wireplumber package was installed, as stated earlier. The
installation of a program does not bring with it the knowledge that it
must be invoked, in order to provide sound to a PulseAudio client.
There are many programs that are installed. Probably over a hundred.
They do not all have to be invoked, in order to provide sound to a
PulseAudio client. Only pipewire, pipewire-pulse, and wireplumber
need to be invoked. This is only three, out of the hundred, or maybe
even more than a hundred, programs, that have been installed. The
belief expressed in the previous post, that not knowing that
wireplumber needed to be invoked, means that wireplumber was "missing",
is puzzling.
The belief that the failures of "systemctl --user" are attributable to
SELinux is also puzzling. The failures of "systemctl --user" are
demonstrably not attributable to SELinux. Or, more precisely, if the
failures of "systemctl --user" are attributable to SELinux, they are
demonstrably not solely attributable to SELinux, because when SELinux
enforcement is turned off, the "systemctl --user" commands continue to
fail exactly as before. The following terminal session shows every
"systemctl --user" command that has been recommended at some point
within this thread, failing; the exact same error messages that were
shown above, are (perhaps unnecessarily) repeated below:
Code:
# setenforce 0
# exit
logout
$ systemctl status --user default.target
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user
Failed to read server status: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user pipewire.service
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user pipewire.socket
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user pipewire-pulse.service
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl status --user pipewire-pulse.socket
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl start --user default.target
Failed to start default.target: Process org.freedesktop.systemd1 exited with status 1
See user logs and 'systemctl --user status default.target' for details.
$ systemctl start --user pipewire.service
Failed to start pipewire.service: Process org.freedesktop.systemd1 exited with status 1
See user logs and 'systemctl --user status pipewire.service' for details.
$ systemctl start --user pipewire.socket
Failed to start pipewire.socket: Process org.freedesktop.systemd1 exited with status 1
See user logs and 'systemctl --user status pipewire.socket' for details.
$ systemctl start --user pipewire-pulse.service
Failed to start pipewire-pulse.service: Process org.freedesktop.systemd1 exited with status 1
See user logs and 'systemctl --user status pipewire-pulse.service' for details.
$ systemctl start --user pipewire-pulse.socket
Failed to start pipewire-pulse.socket: Process org.freedesktop.systemd1 exited with status 1
See user logs and 'systemctl --user status pipewire-pulse.socket' for details.
$ systemctl --user daemon-reload
Failed to reload daemon: Process org.freedesktop.systemd1 exited with status 1
$
More can now be reported about connecting to "pipewire-pulse" over TCP.
After the invocation of "pactl load-module module-native-protocol-tcp",
the "pipewire-pulse" program binds a socket to port 4713 in both IPv4
and IPv6 (presumably a different port would be used, if port 4713 were
in use, but this has not been tested). The "pipewire-pulse" program
can now accept connections from remote clients; but it has now lost
the ability to provide sound to local clients. A locally resident
"firefox" or "mpv -ao=pulse" (or any other program that requests sound
using the PulseAudio protocols) now fails, unless it is given a
PULSE_SERVER environment variable containing the name (e.g., "localhost")
or IP address (e.g., "127.0.0.1" or "[::1]") of the local machine.
This behavior further exposes, as a lie, the assertion that
pipewire-pulse is a "drop-in replacement" for the "pulseaudio" program,
as when a pulseaudio server is configured to accept TCP connections,
by inserting the lines
into the "/etc/pulse/default.pa" file, locally resident PulseAudio
clients are still able to obtain sound without their having to define
a PULSE_SERVER environment variable. In this regard, the
"pipewire-pulse" program lacks important functionality that is
present in the "pulseaudio" program.
Moreover, the "pipewire", "pipewire-pulse", and "wireplumber" programs
must not have a PULSE_SERVER environment variable when they are
invoked. If any of them has a PULSE_SERVER environment variable, it
will fail immediately. Or perhaps -- this is an intriguing idea that
has not been tested -- these programs may have a PULSE_SERVER variable
whose value is the name or IP address of another computer where sound
is available thru a TCP connection to a PulseAudio-compatible server.
If this is true, it implies an intriguing possibility that sound may
be made available to clients who traverse a chain of sound servers,
connecting to a sound server, which then connects to another sound
server (perhaps not directly accessible to the client), and so on.
Perhaps readers of this thread will test this hypothesis, and report
whether it is correct.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
