The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
users to use pipewire instead of pulseaudio (which broke the use of
VLC, but also apparently ogg123 with the alsa device). IMHO, this is
a bad use of Recommends. It is not up to applications to choose what
sound server to use, even via a meta-package like vlc.
Shouldn't there be something in the policy about that?
On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote:
The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
users to use pipewire instead of pulseaudio (which broke the use of
VLC, but also apparently ogg123 with the alsa device). IMHO, this is
a bad use of Recommends. It is not up to applications to choose what
sound server to use, even via a meta-package like vlc.
Shouldn't there be something in the policy about that?
Nothing forces pipewire on you. If you don't want it, don't install it.
It isn't a dependency.
And for the record: you get pipewire installed because libpipewire-0.3-0 recommends it.
On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote:
The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
users to use pipewire instead of pulseaudio (which broke the use of
VLC, but also apparently ogg123 with the alsa device). IMHO, this is
a bad use of Recommends. It is not up to applications to choose what
sound server to use, even via a meta-package like vlc.
Shouldn't there be something in the policy about that?
Nothing forces pipewire on you. If you don't want it, don't install it.
It isn't a dependency.
And for the record: you get pipewire installed because libpipewire-0.3-0 recommends it.
On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
And for the record: you get pipewire installed because libpipewire-0.3-0 recommends it.
For a similar situation, I advocated to add a apt option so that apt
only install Recommends of the packages on the command line, but not Recommends of dependencies (and not Recommends of Recommends).
This would make recommends more usable but less deterministic.
On 2022-05-16 16:14:02 +0000, Bill Allombert wrote:
On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
And for the record: you get pipewire installed because libpipewire-0.3-0 recommends it.
For a similar situation, I advocated to add a apt option so that apt
only install Recommends of the packages on the command line, but not Recommends of dependencies (and not Recommends of Recommends).
This would make recommends more usable but less deterministic.
So, if I understand correctly, this implies that if a package A needs
package B and package B recommends package C, and if it happens that
A needs C, then package A should also depend on or recommend C.
And what about upgrades? Should Recommends be checked only for
manually installed packages?
I do not fully understand the relationships between the different sound servers, for example I think pulseaudio can use ALSA as one of its^^^^ I do
backends, but do I think that they all need to be co-installable without
interfering with the operation of each other, because some applications
There is, unfortunately, a catch here. In order for any of the
applications that require a sound server to work, one of them must be installed. For example, mpd links with libasound, libpipewire, and
libpulse. If each of these libs simply provides the glue to another
package that provides the middleware and drivers, and for the reasons
stated above they each only Suggest their middleware package, then it is possible for _none_ of the sound servers to be installed.
I do not fully understand the relationships between the different sound servers, for example I think pulseaudio can use ALSA as one of its
backends, but do I think that they all need to be co-installable without interfering with the operation of each other, because some applications appear to only use pulseaudio and others only pipewire. Clearly from
the original message in this thread, installing pipewire breaks at least
some setups when using VLC and ogg123.
This is definitely a bug, either of severity "serious" (violates
Debian Policy definition of "Recommends") or "critical" (breaks
other software). But I think to sort this out will require the sound
server maintainers to come up with a way for the user specify which
sound server to use, and then have a metapackage that forces at
least one of them to be installed.
I think you (Vincent) are fully justified in filing a bug against
libpipewire of severity at least "serious", however it may take more
than just downgrading the Recommends to Suggests in order to straighten
this out correctly.
On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote:
The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
users to use pipewire instead of pulseaudio (which broke the use of
VLC, but also apparently ogg123 with the alsa device). IMHO, this is
a bad use of Recommends. It is not up to applications to choose what
sound server to use, even via a meta-package like vlc.
Shouldn't there be something in the policy about that?
Nothing forces pipewire on you. If you don't want it, don't install it.
It isn't a dependency.
And for the record: you get pipewire installed because libpipewire-0.3-0 recommends it.
Here, this could be
Recommends: pipewire | pulseaudio
Indeed, for a remote VM, it is silly to recommend a sound server,
just because a library appears in the chain of dependencies:
joooj:~> apt-get install -s atril | grep '^Inst pipewire'
Ditto for the gnucash accounting software
On Thu, 26 May 2022 at 17:21:27 +0200, Vincent Lefevre wrote:
Here, this could be
Recommends: pipewire | pulseaudio
Those are not interchangeable.
pipewire started as a multiplexer for video streams, and only later
gained audio capabilities. The reason most people with pipewire will
have it installed is that it's necessary when doing screen-sharing or screencasting from a Wayland environment like GNOME.
If you're *also* using pipewire as an audio multiplexing server, which
is not the default for any installation of Debian yet (but might be in future), then you will also need pipewire-pulse, which has two purposes:
* it configures the pipewire service to open the audio device;
* it provides a separate PulseAudio-compatible server which acts as a
wire-protocol-compatible replacement for pulseaudio
Without pipewire-pulse, pipewire is only a video multiplexer, not an
audio multiplexer.
pipewire is actually more like a metapackage, which pulls in the packages that are needed to have Pipewire actually work for a particular library architecture (libpipewire-0.3-0 cannot pull in libpipewire-0.3-modules itself, because that would be a circular dependency), together with the pipewire service from the primary architecture (pipewire-bin).
Indeed, for a remote VM, it is silly to recommend a sound server,
just because a library appears in the chain of dependencies:
joooj:~> apt-get install -s atril | grep '^Inst pipewire'
It looks like that's happening because atril depends on WebKitGTK, a relatively complete web browser engine, which uses xdg-desktop-portal
to invoke per-user services across a sandbox boundary (so that it can
provide the web APIs people expect from it, without having arbitrary
websites able to access your webcam without your permission).
xdg-desktop-portal depends on pipewire because one of the services it provides is access to webcams, and another is screen-sharing and screencasting. Both of those use the Pipewire video protocol to get the actual frames across the sandbox boundary.
Maybe Atril never actually uses WebKitGTK to access arbitrary websites,
but WebKitGTK is a fully-featured web browser engine, so it has to
be prepared to do anything that an arbitrary website expects to work,
and that includes (for example) the Jitsi web frontend.
Ditto for the gnucash accounting software
Same dependency here: it depends on WebKitGTK.
On Thu, 26 May 2022 at 17:21:27 +0200, Vincent Lefevre wrote:
Indeed, for a remote VM, it is silly to recommend a sound server,
just because a library appears in the chain of dependencies:
joooj:~> apt-get install -s atril | grep '^Inst pipewire'
It looks like that's happening because atril depends on WebKitGTK, a relatively complete web browser engine, which uses xdg-desktop-portal
to invoke per-user services across a sandbox boundary (so that it can
provide the web APIs people expect from it, without having arbitrary
websites able to access your webcam without your permission).
xdg-desktop-portal depends on pipewire because one of the services it provides is access to webcams, and another is screen-sharing and screencasting. Both of those use the Pipewire video protocol to get the actual frames across the sandbox boundary.
Maybe Atril never actually uses WebKitGTK to access arbitrary websites,
but WebKitGTK is a fully-featured web browser engine, so it has to
be prepared to do anything that an arbitrary website expects to work,
and that includes (for example) the Jitsi web frontend.
Ditto for the gnucash accounting software
Same dependency here: it depends on WebKitGTK.
On Thu, May 26, 2022 at 10:09:32PM +0200, Jonas Smedegaard wrote:
It looks like that's happening because atril depends on
WebKitGTK, a relatively complete web browser engine, which uses xdg-desktop-portal to invoke per-user services across a sandbox
boundary (so that it can provide the web APIs people expect from
it, without having arbitrary websites able to access your webcam
without your permission).
Ditto for the gnucash accounting software
Same dependency here: it depends on WebKitGTK.
To me, this highlights why libraries should rarely declare strong relationship to executables: Some consumers of WebKitGTK would want
to recommend xdg-desktop-portal, while others like gnucash would
not.
Email applications like astroid and balsa and evolution probably use WebKitGTK for rendering html and have not use for xdg-desktop-portal
at all.
It was actually due to a problem in Evolution that we made WebKitGTK
depend on xdg-desktop-portal (later downgraded to a recommendation):
https://bugzilla.redhat.com/show_bug.cgi?id=1845743 https://bugs.webkit.org/show_bug.cgi?id=213148
It looks like that's happening because atril depends on
WebKitGTK, a relatively complete web browser engine, which uses xdg-desktop-portal to invoke per-user services across a sandbox
boundary (so that it can provide the web APIs people expect from
it, without having arbitrary websites able to access your webcam
without your permission).
Ditto for the gnucash accounting software
Same dependency here: it depends on WebKitGTK.
To me, this highlights why libraries should rarely declare strong relationship to executables: Some consumers of WebKitGTK would want
to recommend xdg-desktop-portal, while others like gnucash would
not.
Email applications like astroid and balsa and evolution probably use WebKitGTK for rendering html and have not use for xdg-desktop-portal
at all.
On Thu, 26 May 2022 at 17:21:27 +0200, Vincent Lefevre wrote:
Here, this could be
Recommends: pipewire | pulseaudio
Those are not interchangeable.
pipewire started as a multiplexer for video streams, and only later
gained audio capabilities. The reason most people with pipewire will
have it installed is that it's necessary when doing screen-sharing or screencasting from a Wayland environment like GNOME.
If you're *also* using pipewire as an audio multiplexing server, which
is not the default for any installation of Debian yet (but might be in future), then you will also need pipewire-pulse, which has two purposes:
* it configures the pipewire service to open the audio device;
* it provides a separate PulseAudio-compatible server which acts as a
wire-protocol-compatible replacement for pulseaudio
Without pipewire-pulse, pipewire is only a video multiplexer, not an
audio multiplexer.
pipewire is actually more like a metapackage, which pulls in the packages that are needed to have Pipewire actually work for a particular library architecture (libpipewire-0.3-0 cannot pull in libpipewire-0.3-modules itself, because that would be a circular dependency), together with the pipewire service from the primary architecture (pipewire-bin).
Indeed, for a remote VM, it is silly to recommend a sound server,
just because a library appears in the chain of dependencies:
joooj:~> apt-get install -s atril | grep '^Inst pipewire'
It looks like that's happening because atril depends on WebKitGTK, a relatively complete web browser engine, which uses xdg-desktop-portal
to invoke per-user services across a sandbox boundary (so that it can
provide the web APIs people expect from it, without having arbitrary
websites able to access your webcam without your permission).
xdg-desktop-portal depends on pipewire because one of the services it provides is access to webcams, and another is screen-sharing and screencasting. Both of those use the Pipewire video protocol to get the actual frames across the sandbox boundary.
Maybe Atril never actually uses WebKitGTK to access arbitrary websites,
but WebKitGTK is a fully-featured web browser engine, so it has to
be prepared to do anything that an arbitrary website expects to work,
and that includes (for example) the Jitsi web frontend.
It was actually due to a problem in Evolution that we made WebKitGTK
depend on xdg-desktop-portal (later downgraded to a recommendation):
https://bugzilla.redhat.com/show_bug.cgi?id=1845743 https://bugs.webkit.org/show_bug.cgi?id=213148
Ok, so Evolution uses sandboxing
On Fri, May 27, 2022 at 01:03:57AM +0200, Jonas Smedegaard wrote:
It was actually due to a problem in Evolution that we made WebKitGTK depend on xdg-desktop-portal (later downgraded to a recommendation):
https://bugzilla.redhat.com/show_bug.cgi?id=1845743 https://bugs.webkit.org/show_bug.cgi?id=213148
Ok, so Evolution uses sandboxing
It's WebKit that does. The web content is handled by a process
(separate from the UI process) that runs inside a bubblewrap sandbox.
In this case you need the portal in order to have access to the font settings:
https://github.com/flatpak/flatpak/issues/2861#issuecomment-494145504
It won't fail horribly if you don't have the portal installed, if
you're using X11 in principle it should work fine, but under Wayland
you won't get antialiased fonts.
with the installation of
vlc-plugin-pipewire, VLC was automatically using pipewire
and apparently ditto with ogg123 (via ALSA, which I had as the default)
However, for the support of bluetooth devices, libspa-0.2-bluetooth
is needed, but it isn't even pulled when pipewire is installed!
But xdg-desktop-portal just depends
on the libpipewire-0.3-0 library package. If it needs more than
the library, then I suppose that it should also recommend pipewire
directly and not expect that the library will do it.
In this case you need the portal in order to have access to theIMHO, such explanations could be useful to users, who may wonder why xdg-desktop-portal-gtk is recommended or why some features are not
font settings:
available (in case the Recommends got broken, but this is unnoticed
by the user). That could be some file under the /usr/share/doc/libwebkit2gtk-4.0-37 directory.
If vlc-plugin-pipewire is prioritized higher than other audio backends,
then I can see how that could happen. It's probably premature for vlc-plugin-pipewire to be prioritized higher than PulseAudio or ALSA in Debian.
The dependency graph around this stuff is complicated, particularly in
a distribution like Debian where the answer to "do we try to support A
or B?" is always "yes". Some early-adopter distributions have switched
to Pipewire as their preferred audio service, replacing PulseAudio,
and in *those* distributions, it would make sense to prioritize vlc-plugin-pipewire ahead of other audio backends - but Pipewire was not sufficiently mature to replace PulseAudio in bullseye, and it remains
to be seen whether it will be sufficiently mature to replace PulseAudio
in bookworm.
If Pipewire was only an audio service, then the right thing to do would be
to make sure it was completely optional and not pulled in by depenencies,
but it's a video service too, and during a global pandemic with a lot of people working and socializing remotely, not having working screen-sharing
or screencasting in GNOME/KDE (together with not having working webcams
in sandboxed Flatpak/Snap apps) seemed like a sufficiently major issue
to make Pipewire worth the headaches it can cause.
and apparently ditto with ogg123 (via ALSA, which I had as the default)
I don't know why that would be. The Pipewire module for libasound is in pipewire-audio-client-libraries, which nothing depends on.
Could it be the case that the chain of Recommends pulled in wireplumber (which Recommends pipewire-pulse) instead of the preferred alternative pipewire-media-session (which was not always listed first, see #999363), resulting in pipewire-pulse taking over audio routing from PulseAudio?
However, for the support of bluetooth devices, libspa-0.2-bluetooth
is needed, but it isn't even pulled when pipewire is installed!
That's needed for Bluetooth audio, *if* you are using Pipewire for audio, which (as a distribution) we are not yet aiming to do. It isn't needed
(or useful) if you are only using Pipewire as a video multiplexer.
pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth,
if people consider Bluetooth audio to be sufficiently important to
justify that (of course, every critical feature for one user is considered "bloat" by someone else, so we can't win). pipewire probably shouldn't,
until such time as we are ready to recommend Pipewire as a replacement
for PulseAudio.
But xdg-desktop-portal just depends
on the libpipewire-0.3-0 library package. If it needs more than
the library, then I suppose that it should also recommend pipewire
directly and not expect that the library will do it.
Perhaps. If I add that Recommends, how many angry bug reports are we
going to get accusing me of forcing people to use Pipewire against
their will?
On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
If vlc-plugin-pipewire is prioritized higher than other audio backends, then I can see how that could happen. It's probably premature for vlc-plugin-pipewire to be prioritized higher than PulseAudio or ALSA in Debian.
The dependency graph around this stuff is complicated, particularly in
a distribution like Debian where the answer to "do we try to support A
or B?" is always "yes". Some early-adopter distributions have switched
to Pipewire as their preferred audio service, replacing PulseAudio,
and in *those* distributions, it would make sense to prioritize vlc-plugin-pipewire ahead of other audio backends - but Pipewire was not sufficiently mature to replace PulseAudio in bullseye, and it remains
to be seen whether it will be sufficiently mature to replace PulseAudio
in bookworm.
If Pipewire was only an audio service, then the right thing to do would be to make sure it was completely optional and not pulled in by depenencies, but it's a video service too, and during a global pandemic with a lot of people working and socializing remotely, not having working screen-sharing or screencasting in GNOME/KDE (together with not having working webcams
in sandboxed Flatpak/Snap apps) seemed like a sufficiently major issue
to make Pipewire worth the headaches it can cause.
So I suppose that the solution should be that PulseAudio have the
priority over Pipewire.
and apparently ditto with ogg123 (via ALSA, which I had as the default)
I don't know why that would be. The Pipewire module for libasound is in pipewire-audio-client-libraries, which nothing depends on.
It has never been installed.
Could it be the case that the chain of Recommends pulled in wireplumber (which Recommends pipewire-pulse) instead of the preferred alternative pipewire-media-session (which was not always listed first, see #999363), resulting in pipewire-pulse taking over audio routing from PulseAudio?
The wireplumber package was installed from 2021-10-26 to 2021-10-29
only. So, perhaps ogg123 was using something else. But the ogg123
audio stream was not appearing in pavucontrol, and the sound was
sent to the speaker of my laptop instead of the bluetooth speakers.
However, for the support of bluetooth devices, libspa-0.2-bluetooth
is needed, but it isn't even pulled when pipewire is installed!
That's needed for Bluetooth audio, *if* you are using Pipewire for audio, which (as a distribution) we are not yet aiming to do. It isn't needed
(or useful) if you are only using Pipewire as a video multiplexer.
The issue appeared automatically with the upgrade of the vlc package.
pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth, if people consider Bluetooth audio to be sufficiently important to
justify that (of course, every critical feature for one user is considered "bloat" by someone else, so we can't win). pipewire probably shouldn't, until such time as we are ready to recommend Pipewire as a replacement
for PulseAudio.
So why did Sebastian Ramacher reassign bug 1011035 to pipewire?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22
But xdg-desktop-portal just depends
on the libpipewire-0.3-0 library package. If it needs more than
the library, then I suppose that it should also recommend pipewire directly and not expect that the library will do it.
Perhaps. If I add that Recommends, how many angry bug reports are we
going to get accusing me of forcing people to use Pipewire against
their will?
Fewer: This is already an issue because xdg-desktop-portal depends
on libpipewire-0.3-0, which recommends pipewire. The advantage would
be that packages just depending on libpipewire-0.3-0 would not pull
pipewire. So, this would solve the pipewire issue in some cases.
Said otherwise, this would not change anything for xdg-desktop-portal,
but could improve things for other packages (if xdg-desktop-portal and
other packages pulling pipewire are not installed).
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote:[...]
On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
That's needed for Bluetooth audio, *if* you are using Pipewire for audio, which (as a distribution) we are not yet aiming to do. It isn't needed (or useful) if you are only using Pipewire as a video multiplexer.
The issue appeared automatically with the upgrade of the vlc package.
pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth, if people consider Bluetooth audio to be sufficiently important to justify that (of course, every critical feature for one user is considered
"bloat" by someone else, so we can't win). pipewire probably shouldn't, until such time as we are ready to recommend Pipewire as a replacement for PulseAudio.
So why did Sebastian Ramacher reassign bug 1011035 to pipewire?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22
If pipewire-pulse is the better place for this relationship, feel free
to reassign it.
On 2022-05-28 10:41:34 +0200, Sebastian Ramacher wrote:
On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote:[...]
On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
That's needed for Bluetooth audio, *if* you are using Pipewire for audio,
which (as a distribution) we are not yet aiming to do. It isn't needed (or useful) if you are only using Pipewire as a video multiplexer.
The issue appeared automatically with the upgrade of the vlc package.
pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth,
if people consider Bluetooth audio to be sufficiently important to justify that (of course, every critical feature for one user is considered
"bloat" by someone else, so we can't win). pipewire probably shouldn't, until such time as we are ready to recommend Pipewire as a replacement for PulseAudio.
So why did Sebastian Ramacher reassign bug 1011035 to pipewire?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22
If pipewire-pulse is the better place for this relationship, feel free
to reassign it.
My comment was on "until such time as we are ready to recommend
Pipewire as a replacement for PulseAudio". If Debian is not ready
to use Pipewire as a replacement for PulseAudio, then VLC shouldn't
try to use Pipewire by default instead of PulseAudio. So that would
be a bug in VLC.
On 2022-05-30 10:43:58 +0200, Vincent Lefevre wrote:[...]
On 2022-05-28 10:41:34 +0200, Sebastian Ramacher wrote:
On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote:[...]
On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
That's needed for Bluetooth audio, *if* you are using Pipewire for audio,
which (as a distribution) we are not yet aiming to do. It isn't needed
(or useful) if you are only using Pipewire as a video multiplexer.
The issue appeared automatically with the upgrade of the vlc package.
[...]My comment was on "until such time as we are ready to recommend
Pipewire as a replacement for PulseAudio". If Debian is not ready
to use Pipewire as a replacement for PulseAudio, then VLC shouldn't
try to use Pipewire by default instead of PulseAudio. So that would
be a bug in VLC.
Let me clear this up a bit:
* vlc does not use pipewire by default.
* vlc-plugin-pipewire depends on libpipewire-0.3 and that's it.
a) pipewire package enables pipewire service by default
Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard <jonas@jones.dk> a écrit :
a) pipewire package enables pipewire service by default
Indeed, but pipewire service doesn't take control of audio over
pulseaudio. Only pipewire-pulse does that.
So, if you don't want to use pipewire for audio, then don't install pipewire-pulse and that's it.
What is the real issue with pipewire service?
libpipewire recommends pipewire for a reason [1], do you mean this is
not a good reason?
[1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1
libpipewire recommends pipewire for a reason [1], do you mean this is
not a good reason?
[1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1
libpipewire dlopens modules from pipewire (such as `libspa-support.so`),
and relies on being able to connect to the pipewire daemon to function.
Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard <jonas@jones.dk> a écrit :
a) pipewire package enables pipewire service by default
Indeed, but pipewire service doesn't take control of audio over
pulseaudio. Only pipewire-pulse does that.
So, if you don't want to use pipewire for audio, then don't install pipewire-pulse and that's it.
What is the real issue with pipewire service?
libpipewire recommends pipewire for a reason [1], do you mean this is
not a good reason?
[1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1
What issues?a) pipewire package enables pipewire service by default
Indeed, but pipewire service doesn't take control of audio over
pulseaudio. Only pipewire-pulse does that.
This is incorrect. The pipewire-pulse package was not installed
at all (pipewire-pulse had been installed automatically in
October 2021 due to dependencies, but the change was reverted,
and the package got removed on my machine 3 days later).
I don't know whether this could cause the issue, but
pipewire-media-session was installed, because pipewire-bin
recommends it. There were already issues with it in the past:
https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/The context of this was "replace pipewire-media-session with wireplumber"
which says:
* Remove pipewire-media-session from Recommends.
(Closes: #995116, #996994, #997859)
Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard <jonas@jones.dk> a écrit :
a) pipewire package enables pipewire service by default
Indeed, but pipewire service doesn't take control of audio over
pulseaudio. Only pipewire-pulse does that.
On Tue, May 31, 2022 at 10:55:55AM +0200, Vincent Lefevre wrote:
a) pipewire package enables pipewire service by default
Indeed, but pipewire service doesn't take control of audio over pulseaudio. Only pipewire-pulse does that.
This is incorrect. The pipewire-pulse package was not installed
at all (pipewire-pulse had been installed automatically in
October 2021 due to dependencies, but the change was reverted,
and the package got removed on my machine 3 days later).
I don't know whether this could cause the issue, butWhat issues?
pipewire-media-session was installed, because pipewire-bin
recommends it. There were already issues with it in the past:
https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
which says:
* Remove pipewire-media-session from Recommends.The context of this was "replace pipewire-media-session with wireplumber"
(Closes: #995116, #996994, #997859)
and it was rolled back in the next upload as you can see in d/changelog.
They are about pipewire-media-session vs wireplumber and/or affect people installing pipewire-pulse as far as I can see.a) pipewire package enables pipewire service by default
Indeed, but pipewire service doesn't take control of audio over pulseaudio. Only pipewire-pulse does that.
This is incorrect. The pipewire-pulse package was not installed
at all (pipewire-pulse had been installed automatically in
October 2021 due to dependencies, but the change was reverted,
and the package got removed on my machine 3 days later).
Sorry. Actually it got removed because I downgraded the pipewire
packages back to the previous version (it's clearer with the /var/log/apt/term.log* log files).
I don't know whether this could cause the issue, but pipewire-media-session was installed, because pipewire-binWhat issues?
recommends it. There were already issues with it in the past:
The ones mentioned below ("Closes: ...").
So "pipewire-media-session was installed" is indeed irrelevant.https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
which says:
* Remove pipewire-media-session from Recommends.The context of this was "replace pipewire-media-session with wireplumber"
(Closes: #995116, #996994, #997859)
Indeed, this is what happened with pipewire 0.3.39-1, as I can see
in my dpkg logs and the changelog:
* Change priority order between pipewire-media-session and wireplumber,
WirePlumber is now the recommended session manager.
and this is what led to the pipewire-pulse installation.
Anyway, when I upgraded the vlc package two weeks ago, this had the
effect that PulseAudio was no longer used as the sound server (for
both vlc and ogg123), though pipewire was already installed (due to
a Recommends from libpipewire-0.3-0, itself due to a Depends from xdg-desktop-portal). The only new package was vlc-plugin-pipewire,
due to
* debian/control: Recommend vlc-plugin-pipewire
pipewire-pulse was not installed.
On Tue, May 31, 2022 at 11:43:06AM +0200, Vincent Lefevre wrote:
Indeed, this is what happened with pipewire 0.3.39-1, as I can see
in my dpkg logs and the changelog:
* Change priority order between pipewire-media-session and wireplumber,
WirePlumber is now the recommended session manager.
and this is what led to the pipewire-pulse installation.So "pipewire-media-session was installed" is indeed irrelevant.
So there's something contradictory. If the pipewire service alone
doesn't take control of audio over pulseaudio, then the only culprit
would be pipewire-media-session. Or what? A bug in pipewire, which
would actually take control of audio even without pipewire-pulse?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 339 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:05:30 |
| Calls: | 7,466 |
| Calls today: | 2 |
| Files: | 12,691 |
| Messages: | 5,627,862 |