Discussion:
[gentoo-user] Pipewire not a dependency?
(too old to reply)
Michael
2022-09-28 11:00:01 UTC
Permalink
I'm trying to understand why one laptop with Plasma which had pulseaudio
removed, won't bring in pipewire as a dependency. I have set USE="-
screencast", because I don't need/want this functionality, as I have done on
other systems which nevertheless have had pipewire brought in as a dependency.

# emerge -1aNDv pipewire

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] media-libs/fdk-aac-2.0.2:0/2::gentoo USE="-examples"
ABI_X86="(64) -32 (-x32)" 2,819 KiB
[ebuild N ] media-libs/libfreeaptx-0.1.1-r1::gentoo ABI_X86="(64) -32 (-
x32)" CPU_FLAGS_X86="-avx2" 28 KiB
[ebuild N ] media-libs/sbc-2.0::gentoo USE="-static-libs" ABI_X86="(64)
-32 (-x32)" 265 KiB
[ebuild N ] media-libs/libldac-2.0.2.3-r1::gentoo ABI_X86="(64) -32 (-
x32)" 74 KiB
[ebuild N ] media-video/pipewire-0.3.56:0/0.4::gentoo USE="X bluetooth
dbus ssl udev -doc -echo-cancel -extra -gstreamer -jack-client -jack-sdk -lv2
-pipewire-alsa -sound-server (-system-service) -systemd -test -v4l -zeroconf"
ABI_X86="(64) -32 (-x32)" 1,813 KiB
[ebuild N ] media-video/wireplumber-0.4.11-r3:0/0.4::gentoo USE="elogind
(-system-service) -systemd -test" LUA_SINGLE_TARGET="lua5-4 -lua5-3" 395 KiB

Total: 6 packages (6 new), Size of downloads: 5,392 KiB


Am I meant to install pipewire manually on this system?
Nikos Chantziaras
2022-09-29 14:20:01 UTC
Permalink
Post by Michael
I'm trying to understand why one laptop with Plasma which had pulseaudio
removed, won't bring in pipewire as a dependency. I have set USE="-
screencast", because I don't need/want this functionality, as I have done on
other systems which nevertheless have had pipewire brought in as a dependency.
Probably some other package pulls it in directly, independent of the
screencast USE flag. For example media-sound/easyeffects.
Michael
2022-10-01 14:10:02 UTC
Permalink
Post by Nikos Chantziaras
Post by Michael
I'm trying to understand why one laptop with Plasma which had pulseaudio
removed, won't bring in pipewire as a dependency. I have set USE="-
screencast", because I don't need/want this functionality, as I have done
on other systems which nevertheless have had pipewire brought in as a
dependency.
Probably some other package pulls it in directly, independent of the
screencast USE flag. For example media-sound/easyeffects.
I just looked and a pipewire(d) system has only a few additional audio
applications, spek, vidcutter, easytag, none of which seem to bring in
pipewire. I think I'll have to install it manually on the system which
doesn't bring it in as some dependency. Somehow I was under the impression it
comes with Plasma these days, but perhaps I have stripped down this Plasma/kde
installation too much.
Peter Humphrey
2022-10-01 15:00:01 UTC
Permalink
Post by Michael
Post by Nikos Chantziaras
Post by Michael
I'm trying to understand why one laptop with Plasma which had pulseaudio
removed, won't bring in pipewire as a dependency. I have set USE="-
screencast", because I don't need/want this functionality, as I have done
on other systems which nevertheless have had pipewire brought in as a
dependency.
Probably some other package pulls it in directly, independent of the
screencast USE flag. For example media-sound/easyeffects.
I just looked and a pipewire(d) system has only a few additional audio
applications, spek, vidcutter, easytag, none of which seem to bring in
pipewire. I think I'll have to install it manually on the system which
doesn't bring it in as some dependency. Somehow I was under the impression
it comes with Plasma these days, but perhaps I have stripped down this
Plasma/kde installation too much.
I have no pipewire on this fairly standard Plasma box.
--
Regards,
Peter.
Mark Knecht
2022-10-01 15:00:01 UTC
Permalink
Post by Michael
Post by Michael
Post by Nikos Chantziaras
Post by Michael
I'm trying to understand why one laptop with Plasma which had
pulseaudio
Post by Michael
Post by Nikos Chantziaras
Post by Michael
removed, won't bring in pipewire as a dependency. I have set USE="-
screencast", because I don't need/want this functionality, as I have done
on other systems which nevertheless have had pipewire brought in as a
dependency.
Probably some other package pulls it in directly, independent of the
screencast USE flag. For example media-sound/easyeffects.
I just looked and a pipewire(d) system has only a few additional audio
applications, spek, vidcutter, easytag, none of which seem to bring in
pipewire. I think I'll have to install it manually on the system which
doesn't bring it in as some dependency. Somehow I was under the impression
it comes with Plasma these days, but perhaps I have stripped down this
Plasma/kde installation too much.
I have no pipewire on this fairly standard Plasma box.
I believe that pipewire, as far as KDE users are concerned, is a
distro choice about when to use it.

My Kubuntu boxes started using it recently. I had no issues and
didn't need to change any settings for any application that makes
use of sound.

YMMV,
Mark
Michael
2022-10-01 17:00:01 UTC
Permalink
Post by Michael
Post by Michael
Post by Michael
Post by Nikos Chantziaras
Post by Michael
I'm trying to understand why one laptop with Plasma which had
pulseaudio
Post by Michael
Post by Nikos Chantziaras
Post by Michael
removed, won't bring in pipewire as a dependency. I have set USE="-
screencast", because I don't need/want this functionality, as I have done
on other systems which nevertheless have had pipewire brought in as
a
Post by Michael
Post by Michael
Post by Nikos Chantziaras
Post by Michael
dependency.
Probably some other package pulls it in directly, independent of the
screencast USE flag. For example media-sound/easyeffects.
I just looked and a pipewire(d) system has only a few additional audio
applications, spek, vidcutter, easytag, none of which seem to bring in
pipewire. I think I'll have to install it manually on the system which
doesn't bring it in as some dependency. Somehow I was under the
impression
Post by Michael
Post by Michael
it comes with Plasma these days, but perhaps I have stripped down this
Plasma/kde installation too much.
I have no pipewire on this fairly standard Plasma box.
I believe that pipewire, as far as KDE users are concerned, is a
distro choice about when to use it.
My Kubuntu boxes started using it recently. I had no issues and
didn't need to change any settings for any application that makes
use of sound.
YMMV,
Mark
Thank you all for your responses. It could be some Plasma/KDE USE flag which
differs between my systems causing this. Without spending a lot of time I
wouldn't know for sure TBH.

Anyway, I ventured into pipewire because I wanted to see if Skype would work
without pulseaudio and in this system it won't. After I manually installed
pipewire Skype won't access the microphone. :-(

Re-enabling pulseaudio wants to rebuild some 30 packages including
qtwebengine. That's an overnight job on this old laptop.
Wol
2022-10-01 17:20:01 UTC
Permalink
Post by Michael
Anyway, I ventured into pipewire because I wanted to see if Skype would work
without pulseaudio and in this system it won't. After I manually installed
pipewire Skype won't access the microphone. 🙁
I've got some vague feeling that pipewire is designed to happily sit
under pulseaudio. The design aim was to replace both Jack and pulseaudio
but it basically just presents a sound device to the layers above, so
just like you can stack block devices for disk access, you can stack
jack, pulseaudio and pipewire for sound.

The big difference between a sound stack and a block stack is that a
block stack is asynchronous and latency is (relatively) unimportant. In
a sound stack some applications *demand* synchronicity, and latency is
everything. Jack is extremely latency sensitive, pulseaudio buffers and
doesn't care, and pipewire is intended to satisfy both.

So the intent was clearly to install pipewire underneath a working
pulseaudio, and just move applications across as and when.

Cheers,
Wol
Michael
2022-10-01 18:30:01 UTC
Permalink
Post by Wol
Post by Michael
Anyway, I ventured into pipewire because I wanted to see if Skype would
work without pulseaudio and in this system it won't. After I manually
installed pipewire Skype won't access the microphone. 🙁
I've got some vague feeling that pipewire is designed to happily sit
under pulseaudio. The design aim was to replace both Jack and pulseaudio
but it basically just presents a sound device to the layers above, so
just like you can stack block devices for disk access, you can stack
jack, pulseaudio and pipewire for sound.
The big difference between a sound stack and a block stack is that a
block stack is asynchronous and latency is (relatively) unimportant. In
a sound stack some applications *demand* synchronicity, and latency is
everything. Jack is extremely latency sensitive, pulseaudio buffers and
doesn't care, and pipewire is intended to satisfy both.
So the intent was clearly to install pipewire underneath a working
pulseaudio, and just move applications across as and when.
Cheers,
Wol
My very limited understanding is pipewire is meant to replace pulseaudio and
jack, rather than become part of an audio/video stack:

https://docs.pipewire.org/page_overview.html

I think applications will gradually be coded to work with pipewire, until then
suitable pipewire plugins would be required. Perhaps for Skype to work today
I will also have to enable pulseaudio, at which point it will not need
pipewire itself. The strange thing is audio playback works great with
pipewire, it's the microphone which does not appear to be capturing anything
and causes Skype to disconnect. :-/
Daniel Sonck
2022-10-01 18:40:01 UTC
Permalink
Post by Wol
Post by Michael
Anyway, I ventured into pipewire because I wanted to see if Skype would
work without pulseaudio and in this system it won't. After I manually
installed pipewire Skype won't access the microphone. 🙁
I've got some vague feeling that pipewire is designed to happily sit
under pulseaudio. The design aim was to replace both Jack and pulseaudio
but it basically just presents a sound device to the layers above, so
just like you can stack block devices for disk access, you can stack
jack, pulseaudio and pipewire for sound.
Well, it is actually designed as a drop-in replacement and won't present audio devices in the
sense pulseaudio wants to receive it. I guess it would theoretically be possible to use
pulseaudio's jack sink to talk to pipewire, but pipewire has the full pulseaudio interface for
pulseaudio applications.
Post by Wol
The big difference between a sound stack and a block stack is that a
block stack is asynchronous and latency is (relatively) unimportant. In
a sound stack some applications *demand* synchronicity, and latency is
everything. Jack is extremely latency sensitive, pulseaudio buffers and
doesn't care, and pipewire is intended to satisfy both.
So the intent was clearly to install pipewire underneath a working
pulseaudio, and just move applications across as and when.
This was never an intent, pipewire was intended as an pulseaudio implementation by itself. So
it doesn't need (and likely is incompatible running together with) pulseaudio in order to
support pulseaudio clients. But it does need to be configured as such.
Post by Wol
Cheers,
Wol
Regards,

Daniel
Michael
2022-10-02 09:50:01 UTC
Permalink
Post by Daniel Sonck
Post by Wol
Post by Michael
Anyway, I ventured into pipewire because I wanted to see if Skype would
work without pulseaudio and in this system it won't. After I manually
installed pipewire Skype won't access the microphone. 🙁
I've got some vague feeling that pipewire is designed to happily sit
under pulseaudio. The design aim was to replace both Jack and pulseaudio
but it basically just presents a sound device to the layers above, so
just like you can stack block devices for disk access, you can stack
jack, pulseaudio and pipewire for sound.
Well, it is actually designed as a drop-in replacement and won't present
audio devices in the sense pulseaudio wants to receive it. I guess it would
theoretically be possible to use pulseaudio's jack sink to talk to
pipewire, but pipewire has the full pulseaudio interface for pulseaudio
applications.
At the moment only some applications support PipeWire's native API, but most
support PulseAudio's API. When you come across an application like Skype
which expects PulseAudio, the solution is to enable USE="sound-server
pipewire-alsa" for PipeWire and in addition to PipeWire also install media-
libs/libpulse. No other PulseAudio packages are needed.

Thereafter an application requiring PulseAudio uses PipeWire, the latter
emulating PulseAudio's server by using PulseAudio's API via libpulse.

I applied the above and now the microphone in Skype works again. I assume the
same applies to other PulseAudio friendly applications, which won't play
nicely with PipeWire only. I suppose at some point PulseAudio will be
completely replaced by PipeWire and applications will update their code
accordingly.
Nikos Chantziaras
2022-10-02 11:50:01 UTC
Permalink
Post by Michael
I applied the above and now the microphone in Skype works again. I assume the
same applies to other PulseAudio friendly applications, which won't play
nicely with PipeWire only. I suppose at some point PulseAudio will be
completely replaced by PipeWire and applications will update their code
accordingly.
Pipewire recommends using the pulseaudio API anyway, at least for now:

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-audio-api-do-you-recommend-to-use

Which makes sense. Pipewire is supposed to be a drop-in replacement for
both pulseaudio and jack. And both of those aren't dead. It makes sense
for applications to try and work on any system, regardless of whether
pipewire is used or not.
Håkon Alstadheim
2022-10-03 21:50:01 UTC
Permalink
Post by Michael
Post by Daniel Sonck
Post by Wol
Post by Michael
Anyway, I ventured into pipewire because I wanted to see if Skype would
work without pulseaudio and in this system it won't. After I manually
installed pipewire Skype won't access the microphone. 🙁
I've got some vague feeling that pipewire is designed to happily sit
under pulseaudio. The design aim was to replace both Jack and pulseaudio
but it basically just presents a sound device to the layers above, so
just like you can stack block devices for disk access, you can stack
jack, pulseaudio and pipewire for sound.
Well, it is actually designed as a drop-in replacement and won't present
audio devices in the sense pulseaudio wants to receive it. I guess it would
theoretically be possible to use pulseaudio's jack sink to talk to
pipewire, but pipewire has the full pulseaudio interface for pulseaudio
applications.
At the moment only some applications support PipeWire's native API, but most
support PulseAudio's API. When you come across an application like Skype
which expects PulseAudio, the solution is to enable USE="sound-server
pipewire-alsa" for PipeWire and in addition to PipeWire also install media-
libs/libpulse. No other PulseAudio packages are needed.
To get that, I seem to need media-sound/pulseaudio (meta package) with 
USE="-daemon"
Post by Michael
Thereafter an application requiring PulseAudio uses PipeWire, the latter
emulating PulseAudio's server by using PulseAudio's API via libpulse.
I applied the above and now the microphone in Skype works again. I assume the
same applies to other PulseAudio friendly applications, which won't play
nicely with PipeWire only. I suppose at some point PulseAudio will be
completely replaced by PipeWire and applications will update their code
accordingly.
Michael
2022-10-03 22:20:01 UTC
Permalink
Post by HÃ¥kon Alstadheim
Post by Michael
Post by Daniel Sonck
Post by Wol
Post by Michael
Anyway, I ventured into pipewire because I wanted to see if Skype would
work without pulseaudio and in this system it won't. After I manually
installed pipewire Skype won't access the microphone. 🙁
I've got some vague feeling that pipewire is designed to happily sit
under pulseaudio. The design aim was to replace both Jack and pulseaudio
but it basically just presents a sound device to the layers above, so
just like you can stack block devices for disk access, you can stack
jack, pulseaudio and pipewire for sound.
Well, it is actually designed as a drop-in replacement and won't present
audio devices in the sense pulseaudio wants to receive it. I guess it would
theoretically be possible to use pulseaudio's jack sink to talk to
pipewire, but pipewire has the full pulseaudio interface for pulseaudio
applications.
At the moment only some applications support PipeWire's native API, but
most support PulseAudio's API. When you come across an application like
Skype which expects PulseAudio, the solution is to enable
USE="sound-server pipewire-alsa" for PipeWire and in addition to PipeWire
also install media- libs/libpulse. No other PulseAudio packages are
needed.
To get that, I seem to need media-sound/pulseaudio (meta package) with
USE="-daemon"
This USE flag setting would be required if you use pulseaudio (I don't have it
installed) and need to avoid it fighting with pipewire over control
of audio devices.

At the present moment, because the migration to pipewire is work-in-progress,
there are a number of options available to cover all use cases, depending on
your system configuration and init system:

https://www.gentoo.org/support/news-items/2022-07-29-pipewire-sound-server.html
Nikos Chantziaras
2022-10-02 11:00:01 UTC
Permalink
Post by Michael
Anyway, I ventured into pipewire because I wanted to see if Skype would work
without pulseaudio and in this system it won't. After I manually installed
pipewire Skype won't access the microphone. :-(
Maybe Skype uses ALSA? It's best to enable the "pipewire-alsa" USE flag
on pipewire and disable the "pulseaudio" flag on alsa-plugins:

media-video/pipewire: pipewire-alsa
media-plugins/alsa-plugins: -pulseaudio

This replaces pulseaudio's ALSA plugin with pipewire's. Skype might work
with this.
Loading...