Replace pulseaudio with pipewire as default audio server
Hello, It's been a while since pipewire has been available and some of us have even been using it for months without problems, so I'd like to propose to make it the default audio server in new Tumbleweed installations, replacing pulseaudio. Pipewire provides capture and playback of audio/video streams with minimal latency, compatibility layers with pulseaudio, jack, etc., integration with xdg-desktop-portal, really good bluetooth audio support, etc. I've already talked with Takashi Iwai and Ondrej Holecek (pulseaudio maintainers) and they support this change. If nobody has a very good argument against it, I'll do the change in the next days to install pipewire instead of pulseaudio by default on new installations. So please, reply to this mail if you have any thoughts about this. Btw, existing installations will not be modified automatically and users would have to install the wireplumber-audio package manually to perform the equivalent change. Of course, this only applies to Tumbleweed, not SLE/Leap. -- Antonio Larrosa
Op dinsdag 14 juni 2022 19:02:19 CEST schreef Antonio Larrosa:
Hello,
It's been a while since pipewire has been available and some of us have even been using it for months without problems, so I'd like to propose to make it the default audio server in new Tumbleweed installations, replacing pulseaudio.
Pipewire provides capture and playback of audio/video streams with minimal latency, compatibility layers with pulseaudio, jack, etc., integration with xdg-desktop-portal, really good bluetooth audio support, etc.
I've already talked with Takashi Iwai and Ondrej Holecek (pulseaudio maintainers) and they support this change.
If nobody has a very good argument against it, I'll do the change in the next days to install pipewire instead of pulseaudio by default on new installations. So please, reply to this mail if you have any thoughts about this. Btw, existing installations will not be modified automatically and users would have to install the wireplumber-audio package manually to perform the equivalent change.
Of course, this only applies to Tumbleweed, not SLE/Leap.
I already have wireplumber-audio installed, don t remember to have it done myself. When I try to configure audio in YaST things like playing a test sound does not work anymore, also an option to enable/disable pulseaudio seems to do nothing, so maybe such things need to be resolved first. I do have sound when I play something with MuseScore. -- fr.gr. member openSUSE Freek de Kruijf
Freek de Kruijf <freek@opensuse.org> writes: Hi Freek,
I already have wireplumber-audio installed, don t remember to have it done myself. When I try to configure audio in YaST things like playing a test sound does not work anymore, also an option to enable/disable pulseaudio seems to do nothing, so maybe such things need to be resolved first.
(1) Do you have pipewire-pulse installed? At a minimum, other then pipewire, wireplumber and wireplumber-audio, you should have pipewire-pulse and pipewire-alsa installed. (2) What is the output of: systemctl --user status pipewire wireplumber pipewire-pulse when you run it under your user account? Charles
Op woensdag 15 juni 2022 22:57:10 CEST schreef Charles Philip Chan:
Freek de Kruijf <freek@opensuse.org> writes:
Hi Freek,
I already have wireplumber-audio installed, don t remember to have it done myself. When I try to configure audio in YaST things like playing a test sound does not work anymore, also an option to enable/disable pulseaudio seems to do nothing, so maybe such things need to be resolved first.
(1) Do you have pipewire-pulse installed? At a minimum, other then pipewire, wireplumber and wireplumber-audio, you should have pipewire-pulse and pipewire-alsa installed.
Yes.
(2) What is the output of:
systemctl --user status pipewire wireplumber pipewire-pulse
when you run it under your user account?
Charles
tum:~> systemctl --user status pipewire wireplumber pipewire-pulse ● pipewire.service - PipeWire Multimedia Service Loaded: loaded (/usr/lib/systemd/user/pipewire.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2022-06-15 22:56:13 CEST; 19min ago TriggeredBy: ● pipewire.socket Main PID: 6427 (pipewire) Tasks: 2 (limit: 4564) Memory: 4.8M CPU: 104ms CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service └─ 6427 /usr/bin/pipewire ● wireplumber.service - Multimedia Service Session Manager Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2022-06-15 22:56:13 CEST; 19min ago Main PID: 6428 (wireplumber) Tasks: 4 (limit: 4564) Memory: 7.8M CPU: 220ms CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/wireplumber.service └─ 6428 /usr/bin/wireplumber ○ pipewire-pulse.service - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; vendor preset: disabled) Active: inactive (dead) This last one seems not OK!! I also notice that now I have a loudspeaker in the system tray with a green backslash. So no sound. -- fr.gr. member openSUSE Freek de Kruijf
Freek de Kruijf <freek@opensuse.org> writes: Hi Freek,
○ pipewire-pulse.service - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; vendor preset: disabled) Active: inactive (dead)
(1) Make sure you have all pulseaudio packages (not pipewire-pulse) uninstalled. (2) Now try to enable pipewire-pulse with systemctl --user enable pipewire-pulse.service under your user account and see if you get sound. Charles
Charles Philip Chan <cpchan@bell.net> writes:
(1) Make sure you have all pulseaudio packages (not pipewire-pulse) uninstalled.
I must clarify myself, I meant just the pulseaudio and pulseaudio-module-* packages. If everything thing goes well the "server name" when your running pactl info should be something like: PulseAudio (on PipeWire 0.3.51) Charles
Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan:
Charles Philip Chan <cpchan@bell.net> writes:
(1) Make sure you have all pulseaudio packages (not pipewire-pulse) uninstalled.
I must clarify myself, I meant just the pulseaudio and pulseaudio-module-* packages.
If everything thing goes well the "server name" when your running
pactl info
should be something like:
PulseAudio (on PipeWire 0.3.51)
Charles
After a reboot I do have sound again and the above command shows the given line. -- fr.gr. member openSUSE Freek de Kruijf
Op donderdag 16 juni 2022 09:35:09 CEST schreef Freek de Kruijf:
Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan:
Charles Philip Chan <cpchan@bell.net> writes:
(1) Make sure you have all pulseaudio packages (not pipewire-pulse) uninstalled.
I must clarify myself, I meant just the pulseaudio and pulseaudio-module-* packages.
If everything thing goes well the "server name" when your running
pactl info
should be something like:
PulseAudio (on PipeWire 0.3.51)
Charles
After a reboot I do have sound again and the above command shows the given line.
However, the Sound module of YaST does not do what it did before, like producing a test sound when asked for. -- fr.gr. member openSUSE Freek de Kruijf
On 2022-06-16 09:39, Freek de Kruijf wrote:
Op donderdag 16 juni 2022 09:35:09 CEST schreef Freek de Kruijf:
Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan:
Charles Philip Chan <cpchan@bell.net> writes:
After a reboot I do have sound again and the above command shows the given line.
However, the Sound module of YaST does not do what it did before, like producing a test sound when asked for.
Hasn't done since about two years on my Leap. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 6/16/22 09:51, Carlos E. R. wrote:
On 2022-06-16 09:39, Freek de Kruijf wrote:
Op donderdag 16 juni 2022 09:35:09 CEST schreef Freek de Kruijf:
Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan:
Charles Philip Chan <cpchan@bell.net> writes:
After a reboot I do have sound again and the above command shows the given line.
However, the Sound module of YaST does not do what it did before, like producing a test sound when asked for.
Hasn't done since about two years on my Leap.
The YaST Sound module has received zero maintenance or development in years. The only reason for it to be still in the distribution is that some people has opposed to drop it because, apparently, is still useful in a quite concrete scenario related to installing openSUSE in VirtualBox. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
On 2022-06-16 10:19, Ancor Gonzalez Sosa wrote:
On 6/16/22 09:51, Carlos E. R. wrote:
On 2022-06-16 09:39, Freek de Kruijf wrote:
Op donderdag 16 juni 2022 09:35:09 CEST schreef Freek de Kruijf:
Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan:
Charles Philip Chan <> writes:
After a reboot I do have sound again and the above command shows the given line.
However, the Sound module of YaST does not do what it did before, like producing a test sound when asked for.
Hasn't done since about two years on my Leap.
The YaST Sound module has received zero maintenance or development in years. The only reason for it to be still in the distribution is that some people has opposed to drop it because, apparently, is still useful in a quite concrete scenario related to installing openSUSE in VirtualBox.
My sound stops working every time I reboot this machine (leap 15.3). The only known way to get sound, on every boot, is to use the yast sound module to delete the card and add it back again. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 6/16/22 22:14, Carlos E. R. wrote:
On 2022-06-16 10:19, Ancor Gonzalez Sosa wrote:
On 6/16/22 09:51, Carlos E. R. wrote:
On 2022-06-16 09:39, Freek de Kruijf wrote:
Op donderdag 16 juni 2022 09:35:09 CEST schreef Freek de Kruijf:
Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan:
Charles Philip Chan <> writes:
After a reboot I do have sound again and the above command shows the given line.
However, the Sound module of YaST does not do what it did before, like producing a test sound when asked for.
Hasn't done since about two years on my Leap.
The YaST Sound module has received zero maintenance or development in years. The only reason for it to be still in the distribution is that some people has opposed to drop it because, apparently, is still useful in a quite concrete scenario related to installing openSUSE in VirtualBox.
My sound stops working every time I reboot this machine (leap 15.3). The only known way to get sound, on every boot, is to use the yast sound module to delete the card and add it back again.
The implementation of pipewire in tumbleweed and 15.4 is much newer then the one in 15.3 so it isn't really useful for assessing if pipewire will work for you. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Mon, 20 Jun 2022 10:15:49 +0200, Simon Lees wrote:
On 6/16/22 22:14, Carlos E. R. wrote:
On 2022-06-16 10:19, Ancor Gonzalez Sosa wrote:
On 6/16/22 09:51, Carlos E. R. wrote:
On 2022-06-16 09:39, Freek de Kruijf wrote:
Op donderdag 16 juni 2022 09:35:09 CEST schreef Freek de Kruijf:
Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan: > Charles Philip Chan <> writes:
> After a reboot I do have sound again and the above command shows the given line.
However, the Sound module of YaST does not do what it did before, like producing a test sound when asked for.
Hasn't done since about two years on my Leap.
The YaST Sound module has received zero maintenance or development in years. The only reason for it to be still in the distribution is that some people has opposed to drop it because, apparently, is still useful in a quite concrete scenario related to installing openSUSE in VirtualBox.
My sound stops working every time I reboot this machine (leap 15.3). The only known way to get sound, on every boot, is to use the yast sound module to delete the card and add it back again.
The implementation of pipewire in tumbleweed and 15.4 is much newer then the one in 15.3 so it isn't really useful for assessing if pipewire will work for you.
Right, and Carlos' problem is likely irrelevant no matter whether PA or PW. Please check whether any stale configuration is found in either dracut.conf.d or modules-load.d. You might have a leftover config from the old YaST that results in a half-baked series of audio modules (unnecessarily) included in initrd on the recent systems. Takashi
On 2022-06-20 12:55, Takashi Iwai wrote:
On Mon, 20 Jun 2022 10:15:49 +0200, Simon Lees wrote:
On 6/16/22 22:14, Carlos E. R. wrote:
On 2022-06-16 10:19, Ancor Gonzalez Sosa wrote:
On 6/16/22 09:51, Carlos E. R. wrote:
On 2022-06-16 09:39, Freek de Kruijf wrote:
Op donderdag 16 juni 2022 09:35:09 CEST schreef Freek de Kruijf: > Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan: >> Charles Philip Chan <> writes:
>> > After a reboot I do have sound again and the above command shows the > given line. > > However, the Sound module of YaST does not do what it did before, like producing a test sound when asked for.
Hasn't done since about two years on my Leap.
The YaST Sound module has received zero maintenance or development in years. The only reason for it to be still in the distribution is that some people has opposed to drop it because, apparently, is still useful in a quite concrete scenario related to installing openSUSE in VirtualBox.
My sound stops working every time I reboot this machine (leap 15.3). The only known way to get sound, on every boot, is to use the yast sound module to delete the card and add it back again.
The implementation of pipewire in tumbleweed and 15.4 is much newer then the one in 15.3 so it isn't really useful for assessing if pipewire will work for you.
Right, and Carlos' problem is likely irrelevant no matter whether PA or PW.
Please check whether any stale configuration is found in either dracut.conf.d or modules-load.d. You might have a leftover config from the old YaST that results in a half-baked series of audio modules (unnecessarily) included in initrd on the recent systems.
Ad far as I remember, this system sound has only been configured, automatically, by YaST, not by me. I have not done any switch to pipewire, and do not intend to do it till YaST does it on its own (or whatever replaces YaST one day in the future) My comment before was only meant to say that, to me, YaST sound module has a role, as I need YaST to restore sound that something else breaks on every boot. Elesar:~ # l /etc/dracut.conf.d total 24 drwxr-xr-x 2 root root 4096 May 8 22:13 ./ drwxr-xr-x 143 root root 12288 Jun 15 16:50 ../ -rw-r--r-- 1 root root 487 Apr 14 15:59 99-debug.conf -rw-r--r-- 1 root root 838 Mar 16 2021 ostree.conf Elesar:~ # Elesar:~ # l /etc/modules-load.d total 16 drwxr-xr-x 2 root root 4096 May 6 14:33 ./ drwxr-xr-x 143 root root 12288 Jun 15 16:50 ../ Elesar:~ # Only non comment content is found in ostree.conf: add_dracutmodules+=" ostree systemd " reproducible=yes This particular installation (not my normal or main one) started life around 2019-05-08. Hum, maybe before. /var/log/zypper.log-20200322.xz: 2019-05-08 23:38:38 <1> Elesar(5041) [zypper] main.cc(main):74 ===== Hi, me zypper 1.14.27 2019-05-08 23:38:38 <1> Elesar(5041) [zypper] main.cc(main):75 ===== 'zypper' 'dup' ===== /var/log/zypp/history: 2019-04-15 16:29:17|command|root@install|'/usr/bin/ruby.ruby2.5' '--encoding=utf-8' '/usr/lib/YaST2/bin/y2start' 'installation' '--arg' 'initial' 'qt' '--n oborder' '--auto-fonts' '--fullscreen'| 2019-04-15 16:29:17|install|GeoIP-data|1.6.12-lp151.1.3|noarch||openSUSE-Leap-15.1-1|bb421d5deeff78a5c9e5dbf4ad407b745647c6f7e3e7cb065659bb4bff513943| -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Il 20/06/22 22:43, Carlos E. R. ha scritto:
On 2022-06-20 12:55, Takashi Iwai wrote:
On Mon, 20 Jun 2022 10:15:49 +0200, Simon Lees wrote:
On 6/16/22 22:14, Carlos E. R. wrote:
On 2022-06-16 10:19, Ancor Gonzalez Sosa wrote:
On 6/16/22 09:51, Carlos E. R. wrote:
On 2022-06-16 09:39, Freek de Kruijf wrote: > Op donderdag 16 juni 2022 09:35:09 CEST schreef Freek de Kruijf: >> Op donderdag 16 juni 2022 00:55:47 CEST schreef Charles Philip Chan: >>> Charles Philip Chan <> writes:
>>> >> After a reboot I do have sound again and the above command shows the >> given line. >> >> > However, the Sound module of YaST does not do what it did before, > like producing a test sound when asked for.
Hasn't done since about two years on my Leap.
The YaST Sound module has received zero maintenance or development in years. The only reason for it to be still in the distribution is that some people has opposed to drop it because, apparently, is still useful in a quite concrete scenario related to installing openSUSE in VirtualBox.
My sound stops working every time I reboot this machine (leap 15.3). The only known way to get sound, on every boot, is to use the yast sound module to delete the card and add it back again.
The implementation of pipewire in tumbleweed and 15.4 is much newer then the one in 15.3 so it isn't really useful for assessing if pipewire will work for you.
Right, and Carlos' problem is likely irrelevant no matter whether PA or PW.
Please check whether any stale configuration is found in either dracut.conf.d or modules-load.d. You might have a leftover config from the old YaST that results in a half-baked series of audio modules (unnecessarily) included in initrd on the recent systems.
Ad far as I remember, this system sound has only been configured, automatically, by YaST, not by me. I have not done any switch to pipewire, and do not intend to do it till YaST does it on its own (or whatever replaces YaST one day in the future)
My comment before was only meant to say that, to me, YaST sound module has a role, as I need YaST to restore sound that something else breaks on every boot.
Elesar:~ # l /etc/dracut.conf.d total 24 drwxr-xr-x 2 root root 4096 May 8 22:13 ./ drwxr-xr-x 143 root root 12288 Jun 15 16:50 ../ -rw-r--r-- 1 root root 487 Apr 14 15:59 99-debug.conf -rw-r--r-- 1 root root 838 Mar 16 2021 ostree.conf Elesar:~ #
Elesar:~ # l /etc/modules-load.d total 16 drwxr-xr-x 2 root root 4096 May 6 14:33 ./ drwxr-xr-x 143 root root 12288 Jun 15 16:50 ../ Elesar:~ #
Only non comment content is found in ostree.conf:
add_dracutmodules+=" ostree systemd " reproducible=yes
This particular installation (not my normal or main one) started life around 2019-05-08. Hum, maybe before.
/var/log/zypper.log-20200322.xz: 2019-05-08 23:38:38 <1> Elesar(5041) [zypper] main.cc(main):74 ===== Hi, me zypper 1.14.27 2019-05-08 23:38:38 <1> Elesar(5041) [zypper] main.cc(main):75 ===== 'zypper' 'dup' =====
/var/log/zypp/history:
2019-04-15 16:29:17|command|root@install|'/usr/bin/ruby.ruby2.5' '--encoding=utf-8' '/usr/lib/YaST2/bin/y2start' 'installation' '--arg' 'initial' 'qt' '--n oborder' '--auto-fonts' '--fullscreen'| 2019-04-15 16:29:17|install|GeoIP-data|1.6.12-lp151.1.3|noarch||openSUSE-Leap-15.1-1|bb421d5deeff78a5c9e5dbf4ad407b745647c6f7e3e7cb065659bb4bff513943|
Sorry if I post here but I've delete all previuos post :| For me pipewire does not work too well as Jack replacement. I tested it for a while but here Jack is better. I also switched back to plain pulseaudio because while jack is running I need extra sink/source, otherwise sound card is "busy" and I cannot use others software... Lots of xruns even with a big buffer. No midi device with Wireplumber, ok with media-session. Daniele.
Freek de Kruijf <freek@opensuse.org> writes: Hi Freek,
After a reboot I do have sound again and the above command shows the given line.
OK I see you got sound, but it wouldn't survive a reboot- at least we know pipewire is working. Now: (1) Disable pipewire-pulse again with: systemctl --user disable pipewire-pulse under your user account. (2) Now run: systemctl --user enable pipewire.socket pipewire-pulse.socket wireplumber under your user account and reboot (although logging out and log in again should work too) and see if you get sound. I have been using this setup ever since wireplumber became stable, by following the instructions on Archwiki, and it has been rock solid. Charles
On 6/15/22 23:41, Charles Philip Chan wrote:
Freek de Kruijf <freek@opensuse.org> writes:
Hi Freek,
○ pipewire-pulse.service - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; vendor preset: disabled) Active: inactive (dead)
(1) Make sure you have all pulseaudio packages (not pipewire-pulse) uninstalled.
The pipewire-pulseaudio package has a conflict on pulseaudio so when the former is installed the latter are removed automatically.
(2) Now try to enable pipewire-pulse with
systemctl --user enable pipewire-pulse.service
Actually, note that the pipewire-pulse.service is not supposed to be enabled by default, only pipewire-pulse.socket and pipewire.socket should be enabled (Freek, could you test that?), that will make pipewire-pulse.service, pipewire.service and wireplumber.service be started automatically when needed. -- Antonio Larrosa
Op donderdag 16 juni 2022 10:55:53 CEST schreef Antonio Larrosa:
On 6/15/22 23:41, Charles Philip Chan wrote:
Freek de Kruijf <freek@opensuse.org> writes:
Hi Freek,
○ pipewire-pulse.service - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; vendor preset: disabled) Active: inactive (dead)
(1) Make sure you have all pulseaudio packages (not pipewire-pulse) uninstalled.
The pipewire-pulseaudio package has a conflict on pulseaudio so when the former is installed the latter are removed automatically.
(2) Now try to enable pipewire-pulse with
systemctl --user enable pipewire-pulse.service
Actually, note that the pipewire-pulse.service is not supposed to be enabled by default, only pipewire-pulse.socket and pipewire.socket should be enabled (Freek, could you test that?), that will make pipewire-pulse.service, pipewire.service and wireplumber.service be started automatically when needed.
-- Antonio Larrosa
This is what I have and see: tum:~> systemctl --user status pipewire-pulse.service ● pipewire-pulse.service - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2022-06-16 09:08:43 CEST; 2h 13min ago TriggeredBy: ● pipewire-pulse.socket Main PID: 3791 (pipewire-pulse) Tasks: 2 (limit: 4564) Memory: 15.4M CPU: 3min 21.413s CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire-pulse.service └─ 3791 /usr/bin/pipewire-pulse So it is not enabled, but active, and I do have sound. Apparently it gets started when I login. -- fr.gr. member openSUSE Freek de Kruijf
On 6/16/22 11:25, Freek de Kruijf wrote:
This is what I have and see: tum:~> systemctl --user status pipewire-pulse.service ● pipewire-pulse.service - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; vendor preset: disabled) [...]
That's right, and if you run: systemctl --user status pipewire-pulse.socket you should have it enabled, which is what starts the services. -- Antonio Larrosa
Op donderdag 16 juni 2022 13:11:33 CEST schreef Antonio Larrosa:
On 6/16/22 11:25, Freek de Kruijf wrote:
This is what I have and see: tum:~> systemctl --user status pipewire-pulse.service ● pipewire-pulse.service - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; vendor preset: disabled) [...]
That's right, and if you run:
systemctl --user status pipewire-pulse.socket
you should have it enabled, which is what starts the services.
-- Antonio Larrosa
Indeed. tum:~> systemctl --user status pipewire-pulse.socket ● pipewire-pulse.socket - PipeWire PulseAudio Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.socket; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-06-16 09:08:33 CEST; 4h 21min ago Until: Thu 2022-06-16 09:08:33 CEST; 4h 21min ago Triggers: ● pipewire-pulse.service Listen: /run/user/1000/pulse/native (Stream) CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pipewire-pulse.socket -- fr.gr. member openSUSE Freek de Kruijf
On Dienstag, 14. Juni 2022 19:02:19 CEST Antonio Larrosa wrote:
Hello,
It's been a while since pipewire has been available and some of us have even been using it for months without problems, so I'd like to propose to make it the default audio server in new Tumbleweed installations, replacing pulseaudio.
Pipewire provides capture and playback of audio/video streams with minimal latency, compatibility layers with pulseaudio, jack, etc., integration with xdg-desktop-portal, really good bluetooth audio support, etc.
I've already talked with Takashi Iwai and Ondrej Holecek (pulseaudio maintainers) and they support this change.
If nobody has a very good argument against it, I'll do the change in the next days to install pipewire instead of pulseaudio by default on new installations. So please, reply to this mail if you have any thoughts about this. Btw, existing installations will not be modified automatically and users would have to install the wireplumber-audio package manually to perform the equivalent change.
Of course, this only applies to Tumbleweed, not SLE/Leap.
For working from home I regularly connect to a Citrix platform and login to a virtual Windows 10 client. In this session I use Microsoft Lync for audio and video conferences. At the moment, this doesn't work with pipewire. I tried with every new version of pipewire, that comes with a snapshot, but I always had to go back to pulseaudio. With pipewire one can't control or mute the volume, very often the Citrix HDX driver is crashing - and even the installation script has to be modified manually, because it checks the presence of pulseaudio and won't install otherwise. I use the latest openSUSE package for the Citrix Workspace App and the latest HDX driver from the Citrix website, that runs on Tumbleweed without too many other problems. $ rpm -qi ICAClient Name : ICAClient Version : 20.10.0.6 Release : 0 Architecture: x86_64 Install Date: Tue Jan 11 11:04:09 2022 Group : Applications/Productivity Size : 318201388 License : Commercial Signature : (none) Source RPM : ICAClient-20.10.0.6-0.src.rpm Build Date : Tue Oct 27 11:54:55 2020 Build Host : DOCKER-TYPHKLSO.eng.citrite.net Packager : Citrix Systems, Inc Vendor : Citrix Systems, Inc URL : http://www.citrix.com/ Summary : Citrix Workspace app for Linux Description : Citrix Workspace lets you access your enterprise files, applications, and desktops from your favorite device wherever you are. Just ask your IT department how to get started. Distribution: (none) $ rpm -qi citrix-hdx-realtime-media-engine Name : citrix-hdx-realtime-media-engine Version : 2.9.400 Release : 2702 Architecture: x86_64 Install Date: Tue Jan 11 11:05:20 2022 Group : Applications/Multimedia Size : 52606534 License : GPL Signature : (none) Source RPM : citrix-hdx-realtime-media-engine-2.9.400-2702.src.rpm Build Date : Wed Jun 9 17:43:19 2021 Build Host : ubuntu16.04.6-x64 Packager : Citrix, Inc. <citrix@citrix.com> Summary : The package contains Citrix HDX RealTime audio/video service for remote terminals Description : Citrix HDX RealTime audio/video service for remote terminals is a plugin for the Citrix Workspace App for Linux (ICAClient). The Citrix Workspace App must be installed first. Distribution: (none) Bye. Michael.
On 6/15/22 22:38, mh@mike.franken.de wrote:
For working from home I regularly connect to a Citrix platform and login to a virtual Windows 10 client. In this session I use Microsoft Lync for audio and video conferences. At the moment, this doesn't work with pipewire. I tried with every new version of pipewire, that comes with a snapshot, but I always had to go back to pulseaudio.
Thanks for testing, would you be available at irc.libera.chat to do some tests and try to fix this problem?
With pipewire one can't control or mute the volume, very often the Citrix HDX driver is crashing - and even the installation script has to be modified manually, because it checks the presence of pulseaudio and won't install otherwise.
Well, the check for the presence of the pulseaudio binary could be worked-around by putting the attached file at /usr/bin/pulseaudio (assuming pipewire-pulseaudio is installed and not the real pulseaudio) and doing chmod +x /usr/bin/pulseaudio . We could even add a subpackage that people could install if needed with this workaround and appropriate package conflicts (but I wouldn't install it by default as it would be useless for 99.99% of users) In any case, the other issues would be interesting to debug.
I use the latest openSUSE package for the Citrix Workspace App and the latest HDX driver from the Citrix website, that runs on Tumbleweed without too many other problems.
$ rpm -qi ICAClient Name : ICAClient Version : 20.10.0.6
I tried downloading the package and version 22.5.0.16 is already available, just in case you want to try it (although it still does that silly check for the existence of the pulseaudio binary)
$ rpm -qi citrix-hdx-realtime-media-engine Name : citrix-hdx-realtime-media-engine
I couldn't find this package to test it though. As a last resort, pulseaudio will continue being available so you could still replace pipewire with pulseaudio on systems where you need to use the Citrix Workspace App. But I agree the ideal would be to fix this to work with pipewire. Btw, is "Citrix HDX for Skype" the same as "citrix-hdx-realtime-media-engine" ? I'm not familiar with the Citrix products but I read an user who reported the former as working with pipewire. Greetings, -- Antonio Larrosa
Hi, On Donnerstag, 16. Juni 2022 11:03:16 CEST Antonio Larrosa wrote:
On 6/15/22 22:38, mh@mike.franken.de wrote:
For working from home I regularly connect to a Citrix platform and login to a virtual Windows 10 client. In this session I use Microsoft Lync for audio and video conferences. At the moment, this doesn't work with pipewire. I tried with every new version of pipewire, that comes with a snapshot, but I always had to go back to pulseaudio.
Thanks for testing, would you be available at irc.libera.chat to do some tests and try to fix this problem?
hrm, at the moment I am very busy at work - I returned from a 4 months absence this week.
With pipewire one can't control or mute the volume, very often the Citrix HDX driver is crashing - and even the installation script has to be modified manually, because it checks the presence of pulseaudio and won't install otherwise.
Well, the check for the presence of the pulseaudio binary could be worked-around by putting the attached file at /usr/bin/pulseaudio (assuming pipewire-pulseaudio is installed and not the real pulseaudio) and doing chmod +x /usr/bin/pulseaudio . We could even add a subpackage that people could install if needed with this workaround and appropriate package conflicts (but I wouldn't install it by default as it would be useless for 99.99% of users)
This of course isn't the main problem ;)
In any case, the other issues would be interesting to debug.
I use the latest openSUSE package for the Citrix Workspace App and the latest HDX driver from the Citrix website, that runs on Tumbleweed without too many other problems.
$ rpm -qi ICAClient
Name : ICAClient Version : 20.10.0.6
I tried downloading the package and version 22.5.0.16 is already available, just in case you want to try it (although it still does that silly check for the existence of the pulseaudio binary)
I know, but this is why I wrote: "that runs on Tumbleweed without too many other problems." I usually test every new version, but 20.10.0.6 is the latest, that fulfills this criterium.
$ rpm -qi citrix-hdx-realtime-media-engine
Name : citrix-hdx-realtime-media-engine
I couldn't find this package to test it though.
https://docs.citrix.com/de-de/hdx-optimization/2-9-ltsr.html
As a last resort, pulseaudio will continue being available so you could still replace pipewire with pulseaudio on systems where you need to use the Citrix Workspace App. But I agree the ideal would be to fix this to work with pipewire.
Btw, is "Citrix HDX for Skype" the same as "citrix-hdx-realtime-media-engine" ? I'm not familiar with the Citrix products but I read an user who reported the former as working with pipewire.
I am not sure, if they are identical, but I believe they are. Did the user mention, if he had to modify some configuration? Or did it worked oob?
Greetings,
Bye. Michael.
Hi again, I installed the latest ICAclient and the latest HDX packages. They both seem to work - the first ones in a longer row of newer packages. I then uninstalled all pulseaudio packages and installed pipewire and pipewire-pulseaudio. Anything else? I lost the configuration applet in systemsettings5, though. Am I missing a necessary package here? Thx and bye. Michael.
On 6/16/22 13:23, mh@mike.franken.de wrote:
Hi again,
Hi,
I installed the latest ICAclient and the latest HDX packages. They both seem to work - the first ones in a longer row of newer packages.
I then uninstalled all pulseaudio packages and installed pipewire and pipewire-pulseaudio. Anything else?
If you installed those with: zypper in pipewire-pulseaudio or zypper in wireplumber-audio that should have installed al necessary dependencies. After that, you have to log out and log in again (a restart wouldn't hurt if it's possible, to be sure all processes are stopped/started correctly).
I lost the configuration applet in systemsettings5, though. Am I missing a necessary package here?
Exactly what configuration page are you missing? You should have the Audio module in there to configure the audio devices. -- Antonio Larrosa
On Donnerstag, 16. Juni 2022 14:37:51 CEST Antonio Larrosa wrote:
On 6/16/22 13:23, mh@mike.franken.de wrote:
Hi again,
Hi,
I installed the latest ICAclient and the latest HDX packages. They both seem to work - the first ones in a longer row of newer packages.
I then uninstalled all pulseaudio packages and installed pipewire and pipewire-pulseaudio. Anything else?
If you installed those with:
zypper in pipewire-pulseaudio
I installed it that way.
or zypper in wireplumber-audio
that should have installed al necessary dependencies. After that, you have to log out and log in again (a restart wouldn't hurt if it's possible, to be sure all processes are stopped/started correctly).
I did that, and I have the following processes running: /usr/bin/pipewire /usr/bin/wireplumber /usr/bin/pipewire-pulse
I lost the configuration applet in systemsettings5, though. Am I missing a necessary package here?
Exactly what configuration page are you missing? You should have the Audio module in there to configure the audio devices.
No, I don't have that module. Below multimedia I only have "Audio CDs" and "CDDB Retrieval". Bye. Michael.
On Donnerstag, 16. Juni 2022 23:16:03 CEST mh@mike.franken.de wrote: [...]
I did that, and I have the following processes running:
/usr/bin/pipewire /usr/bin/wireplumber /usr/bin/pipewire-pulse
I lost the configuration applet in systemsettings5, though. Am I missing a necessary package here?
Exactly what configuration page are you missing? You should have the Audio module in there to configure the audio devices.
No, I don't have that module. Below multimedia I only have "Audio CDs" and "CDDB Retrieval".
plasma5-pa seems to have been uninstalled somehow. After reinstalling it, I got my audio applet back - and also the mixer in the tray.
Bye. Michael.
On 6/16/22 12:38, mh@mike.franken.de wrote:
Hi,
On Donnerstag, 16. Juni 2022 11:03:16 CEST Antonio Larrosa wrote:
On 6/15/22 22:38, mh@mike.franken.de wrote:
For working from home I regularly connect to a Citrix platform and login to a virtual Windows 10 client. In this session I use Microsoft Lync for audio and video conferences. At the moment, this doesn't work with pipewire. I tried with every new version of pipewire, that comes with a snapshot, but I always had to go back to pulseaudio.
Thanks for testing, would you be available at irc.libera.chat to do some tests and try to fix this problem?
hrm, at the moment I am very busy at work - I returned from a 4 months absence this week.
ok, no problem, just feel free to reach me (my nickname is antlarr) when you have some time.
With pipewire one can't control or mute the volume, very often the Citrix HDX driver is crashing - and even the installation script has to be modified manually, because it checks the presence of pulseaudio and won't install otherwise.
Well, the check for the presence of the pulseaudio binary could be worked-around by putting the attached file at /usr/bin/pulseaudio (assuming pipewire-pulseaudio is installed and not the real pulseaudio) and doing chmod +x /usr/bin/pulseaudio . We could even add a subpackage that people could install if needed with this workaround and appropriate package conflicts (but I wouldn't install it by default as it would be useless for 99.99% of users)
This of course isn't the main problem ;)
Hehe, I guess so :)
$ rpm -qi citrix-hdx-realtime-media-engine
Name : citrix-hdx-realtime-media-engine
I couldn't find this package to test it though.
https://docs.citrix.com/de-de/hdx-optimization/2-9-ltsr.html
Thanks, I had to create an account to download that package and I could install it now. I was hoping I could test something once it was installed but the very first thing it asks me is a server to connect to and having no server to test, it's not very helpful.
As a last resort, pulseaudio will continue being available so you could still replace pipewire with pulseaudio on systems where you need to use the Citrix Workspace App. But I agree the ideal would be to fix this to work with pipewire.
Btw, is "Citrix HDX for Skype" the same as "citrix-hdx-realtime-media-engine" ? I'm not familiar with the Citrix products but I read an user who reported the former as working with pipewire.
I am not sure, if they are identical, but I believe they are. Did the user mention, if he had to modify some configuration? Or did it worked oob?
It was actually a user reporting a regression because citrix stopped working with pipewire 0.3.52 due to the changes in the rates allowed by this new pipewire version and some driver issues. You can read it at: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2441 The suggested solution is to use only 48000 as allowed rate in pipewire.conf, like this: default.clock.allowed-rates = [ 48000 ] but I guess that's unrelated to your issue. -- Antonio Larrosa
On Donnerstag, 16. Juni 2022 11:03:16 CEST Antonio Larrosa wrote:
On 6/15/22 22:38, mh@mike.franken.de wrote:
For working from home I regularly connect to a Citrix platform and login to a virtual Windows 10 client. In this session I use Microsoft Lync for audio and video conferences. At the moment, this doesn't work with pipewire. I tried with every new version of pipewire, that comes with a snapshot, but I always had to go back to pulseaudio.
Thanks for testing, would you be available at irc.libera.chat to do some tests and try to fix this problem?
With pipewire one can't control or mute the volume, very often the Citrix HDX driver is crashing - and even the installation script has to be modified manually, because it checks the presence of pulseaudio and won't install otherwise.
Ok, I tested with pipewire from latest Tumbleweed snapshot, latest ICAclient and HDX media engine packages from Citrix. The problems remain: - My Plantronics headset is recognized as "other device" in the virtual windows 10 client. - I can't mute or control audio level through the button at the headset. - I get loads of error messages from wfica (see attachement). - Sound quality is bad. - The HDX engine is crashing sometimes. So for the moment I revert to pulseaudio again, because I need a working HDX media engine for our audio conferences at work. Bye. Michael.
On Freitag, 17. Juni 2022 00:07:09 CEST mh@mike.franken.de wrote:
On Donnerstag, 16. Juni 2022 11:03:16 CEST Antonio Larrosa wrote:
On 6/15/22 22:38, mh@mike.franken.de wrote:
For working from home I regularly connect to a Citrix platform and login to a virtual Windows 10 client. In this session I use Microsoft Lync for audio and video conferences. At the moment, this doesn't work with pipewire. I tried with every new version of pipewire, that comes with a snapshot, but I always had to go back to pulseaudio.
Thanks for testing, would you be available at irc.libera.chat to do some tests and try to fix this problem?
With pipewire one can't control or mute the volume, very often the Citrix HDX driver is crashing - and even the installation script has to be modified manually, because it checks the presence of pulseaudio and won't install otherwise.
Ok, I tested with pipewire from latest Tumbleweed snapshot, latest ICAclient and HDX media engine packages from Citrix. The problems remain: - My Plantronics headset is recognized as "other device" in the virtual windows 10 client. - I can't mute or control audio level through the button at the headset. - I get loads of error messages from wfica (see attachement). - Sound quality is bad. - The HDX engine is crashing sometimes.
So for the moment I revert to pulseaudio again, because I need a working HDX media engine for our audio conferences at work.
JFYI: I had to go back to Citrix Workspace app for Linux version 20.10.0.6. With the newer versions, even with the latest it is not possible to start a remote desktop session from within the virtual Citrix client to any other windows machine. No idea if this is a windows or a Citrix problem.
Bye. Michael.
Hi! On 6/14/22 19:02, Antonio Larrosa wrote:
It's been a while since pipewire has been available and some of us have even been using it for months without problems, so I'd like to propose to make it the default audio server in new Tumbleweed installations, replacing pulseaudio.
Pipewire provides capture and playback of audio/video streams with minimal latency, compatibility layers with pulseaudio, jack, etc., integration with xdg-desktop-portal, really good bluetooth audio support, etc.
Does Pipewire actually fully replace PulseAudio feature-wise? I'm still somewhat surprised how PulseAudio, that took the Linux community years to mature, is suddenly supposed to be immediately replaced by something that has been around for such a short time. Adrian
On 6/16/22 13:49, John Paul Adrian Glaubitz wrote:
Hi!
On 6/14/22 19:02, Antonio Larrosa wrote:
It's been a while since pipewire has been available and some of us have even been using it for months without problems, so I'd like to propose to make it the default audio server in new Tumbleweed installations, replacing pulseaudio.
Pipewire provides capture and playback of audio/video streams with minimal latency, compatibility layers with pulseaudio, jack, etc., integration with xdg-desktop-portal, really good bluetooth audio support, etc.
Does Pipewire actually fully replace PulseAudio feature-wise? I'm still somewhat surprised how PulseAudio, that took the Linux community years to mature, is suddenly supposed to be immediately replaced by something that has been around for such a short time.
It might be because it builds on top of Pulse (Most applications just see it as pulse), this has some interesting side effects in that if you look at some pulse mixers in tools designed for pipewire you see alot of extra connections but its still functional. On Tumbleweed and Leap 15.4 pipewire has replaced all my Pulse usage and 95% of my Jack use cases with the other 5% being pretty obscure. My setups tend to use 2-3 soundcards sometimes at the same time with one generally being low latency. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 6/16/22 11:22, Simon Lees wrote:
Does Pipewire actually fully replace PulseAudio feature-wise? I'm still somewhat surprised how PulseAudio, that took the Linux community years to mature, is suddenly supposed to be immediately replaced by something that has been around for such a short time.
It might be because it builds on top of Pulse (Most applications just see it as pulse), this has some interesting side effects in that if you look at some pulse mixers in tools designed for pipewire you see alot of extra connections but its still functional.
So, it's basically a fork of PulseAudio? Adrian
John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> writes: Hi John,
So, it's basically a fork of PulseAudio?
No, it is not. It was originally developed for low latency video capture and playback, but the author quickly realize that the framework can be used for audio too. It has emulation libraries for pulseaudio, Jackd and ALSA, so that pulseaudio, Jackd and vanilla ALSA clients can connect to it without modification. This is a stop gap measure until programs support the native pipewire API (I know, at least mpd support pipewire natively). The server's latency is low enough to replace Jackd completely for professional use (which pulseaudio cannot do). This being said, the sound server's features are not completely yet. For some advanced features, it might require a pulseaudio module, such as network access, For this I put: ,---- | pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24 `---- in my Window Maker autostart file, as part of my mpd setup. Here are the benefits of Pipewire: - Capture and playback of audio and video with minimal latency. - Real-time Multimedia processing on audio and video. - Multiprocess architecture to let applications share multimedia content. - Seamless support for PulseAudio, JACK, ALSA and GStreamer applications. - Sandboxed applications support. See Flatpak for more info.[1] I am really exited about this server as opposed to pulseaudio with it's terrible latency. Charles Footnotes: [1] https://pipewire.org/
W dniu 17.06.2022 o 23:50, Charles Philip Chan pisze:
This being said, the sound server's features are not completely yet. For some advanced features, it might require a pulseaudio module, such as network access, For this I put:
,---- | pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24 `----
in my Window Maker autostart file, as part of my mpd setup.
When using pipewire, the command "pactl load-module" doesn't load pulseaudio modules. They are reimplemented as a part of pipewire-pulse compatibility layer. https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/src/modules/m...
Adam Mizerski <adam@mizerski.pl> writes: Hi Adam,
When using pipewire, the command "pactl load-module" doesn't load pulseaudio modules. They are reimplemented as a part of pipewire-pulse compatibility layer.
https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/src/modules/m...
Thanks, for the info- it was committed a week ago. I only needed that feature once in a while and haven't noticed. I was following the instructions on Archwiki. [1] I see, now they have change the info to: ,---- | To share the local audio devices load the appropriate modules on the host (make sure to use the local IP address): | | $ pactl load-module module-native-protocol-tcp listen=192.168.1.10 | $ pactl load-module module-zeroconf-publish | | Then load the discovery module on the clients: | | $ pactl load-module module-zeroconf-discover `---- Is this still wrong? Footnotes: [1] https://wiki.archlinux.org/title/PipeWire#Sharing_audio_devices_with_compute...
Charles Philip Chan <cpchan@bell.net> writes:
Adam Mizerski <adam@mizerski.pl> writes:
Hi Adam,
When using pipewire, the command "pactl load-module" doesn't load pulseaudio modules. They are reimplemented as a part of pipewire-pulse compatibility layer.
https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/src/modules/m...
Thanks, for the info- it was committed a week ago. I only needed that feature once in a while and haven't noticed. I was following the instructions on Archwiki. [1]
OK, I tested it out by unloading and reloading the module with pactl. The result is that the module "module-native-protocol-tcp" does load. This is the documentation on freedesktop.org: ,---- | Network Support | | | | The PipeWire PulseAudio server has fairly complete network support. The only module that is not yet implemented is the RTP network streaming module (but the ROC module is an alternative). | | module-native-protocol-tcp | | | | Use: | | | | pactl load-module module-native-protocol-tcp [port=<port, default:4713>] [listen=<ip, default:127.0.0.1>] | | | | This loads a new server listening on the given port and IP.[1] | `---- Now, I am confused. Charles Footnotes: [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PulseAudio#m...
W dniu 18.06.2022 o 15:56, Charles Philip Chan pisze:
Adam Mizerski <adam@mizerski.pl> writes:
Hi Adam,
When using pipewire, the command "pactl load-module" doesn't load pulseaudio modules. They are reimplemented as a part of pipewire-pulse compatibility layer.
https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/src/modules/m...
Thanks, for the info- it was committed a week ago.
Uhmm.. If what you're referring to is this box at the top of gitlab page saying "pulse-server: module-switch-on-connect: remove dead code and one allocation Barnabás Pőcze authored 1 week ago" It's about a last change made in this directory. The whole thing exists for much longer time. In the pipewire changelog you can see for example that module-simple-protocol-tcp and module-native-protocol-tcp were added to pipewire in version 0.3.26.
I only needed that feature once in a while and haven't noticed. I was following the instructions on Archwiki. [1]
I see, now they have change the info to:
,---- | To share the local audio devices load the appropriate modules on the host (make sure to use the local IP address): | | $ pactl load-module module-native-protocol-tcp listen=192.168.1.10 | $ pactl load-module module-zeroconf-publish | | Then load the discovery module on the clients: | | $ pactl load-module module-zeroconf-discover `----
Is this still wrong?
Why would it be wrong? I don't understand your doubts. I'll try to explain it again: PulseAudio contains some implementation of modules. Pipewire doesn't use them. Instead, Pipewire has its own reimplementation of those modules. So if you have a system using Pipewire, the command "pactl load-module" talks with Pipewire to load a pipewire module. It just happens that the reimpelemtation is quite good at being a drop-in replacement. I hope this helps. Or maybe we're just talking past each other.
Adam Mizerski <adam@mizerski.pl> writes: Hi Adam,
I hope this helps. Or maybe we're just talking past each other.
To clarify things more, I didn't realize that the modules were reimplemented and are actually Pipewire modules. I thought you meant pactl would not load any modules. Sorry for the noise. Charles
Am Samstag, 18. Juni 2022, 22:22:48 CEST schrieb Adam Mizerski:
W dniu 18.06.2022 o 15:56, Charles Philip Chan pisze:
Adam Mizerski <adam@mizerski.pl> writes:
Hi Adam,
When using pipewire, the command "pactl load-module" doesn't load pulseaudio modules. They are reimplemented as a part of pipewire-pulse compatibility layer.
https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/src/module s/module-protocol-pulse/modules
Thanks, for the info- it was committed a week ago.
Uhmm.. If what you're referring to is this box at the top of gitlab page saying
"pulse-server: module-switch-on-connect: remove dead code and one allocation Barnabás Pőcze authored 1 week ago"
It's about a last change made in this directory.
The whole thing exists for much longer time. In the pipewire changelog you can see for example that module-simple-protocol-tcp and module-native-protocol-tcp were added to pipewire in version 0.3.26.
I only needed that feature once in a while and haven't noticed. I was following the instructions on Archwiki. [1]
I see, now they have change the info to:
,----
| To share the local audio devices load the appropriate modules on the | host (make sure to use the local IP address): | | | | $ pactl load-module module-native-protocol-tcp listen=192.168.1.10 | $ pactl load-module module-zeroconf-publish | | | | Then load the discovery module on the clients: | | | | $ pactl load-module module-zeroconf-discover
`----
Is this still wrong?
Why would it be wrong? I don't understand your doubts.
I'll try to explain it again: PulseAudio contains some implementation of modules. Pipewire doesn't use them. Instead, Pipewire has its own reimplementation of those modules. So if you have a system using Pipewire, the command "pactl load-module" talks with Pipewire to load a pipewire module. It just happens that the reimpelemtation is quite good at being a drop-in replacement.
I hope this helps. Or maybe we're just talking past each other.
Thank you for this explanation, but it would be irritating less when pw-commands and pa-commands are not mixed. A clean change from pa to pw would be nice to deinstall pa completly to test pw and reinstall pa when pw fails. In this time for me pa works much more stable than pw but far not rock solid - This can be an issue of trx40-board mit usb-audio - but if not I hope pw will be matured some time. -- Mit freundlichen Grüßen, Richard Werth
On 6/16/22 06:19, John Paul Adrian Glaubitz wrote:
On 6/14/22 19:02, Antonio Larrosa wrote:
It's been a while since pipewire has been available and some of us have even been using it for months without problems, so I'd like to propose to make it the default audio server in new Tumbleweed installations, replacing pulseaudio.
Pipewire provides capture and playback of audio/video streams with minimal latency, compatibility layers with pulseaudio, jack, etc., integration with xdg-desktop-portal, really good bluetooth audio support, etc.
Does Pipewire actually fully replace PulseAudio feature-wise? I'm still somewhat surprised how PulseAudio, that took the Linux community years to mature, is suddenly supposed to be immediately replaced by something that has been around for such a short time.
Ah, just found a very comprehensive LWN article on the topic: https://lwn.net/Articles/847412/ Adrian
participants (13)
-
Adam Mizerski -
Ancor Gonzalez Sosa -
Antonio Larrosa -
Antonio Larrosa -
Carlos E. R. -
Charles Philip Chan -
Daniele -
Freek de Kruijf -
John Paul Adrian Glaubitz -
mh＠mike.franken.de -
Richard Werth -
Simon Lees -
Takashi Iwai