[gentoo-user] Pipewire not a dependency?

[gentoo-user] Pipewire not a dependency?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

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?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Pipewire not a dependency?

[Nikos Chantziaras]

On 28/09/2022 13:57, Michael wrote:
> 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.

Re: [gentoo-user] Re: Pipewire not a dependency?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

On Thursday, 29 September 2022 15:11:02 BST Nikos Chantziaras wrote:
> On 28/09/2022 13:57, Michael wrote:
> > 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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Pipewire not a dependency?

[Peter Humphrey]

On Saturday, 1 October 2022 15:08:40 BST Michael wrote:
> On Thursday, 29 September 2022 15:11:02 BST Nikos Chantziaras wrote:
> > On 28/09/2022 13:57, Michael wrote:
> > > 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.

Re: [gentoo-user] Re: Pipewire not a dependency?

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On Sat, Oct 1, 2022 at 7:51 AM Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> On Saturday, 1 October 2022 15:08:40 BST Michael wrote:
> > On Thursday, 29 September 2022 15:11:02 BST Nikos Chantziaras wrote:
> > > On 28/09/2022 13:57, Michael wrote:
> > > > 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.
>

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

[-- Attachment #2: Type: text/html, Size: 1961 bytes --]

Re: [gentoo-user] Re: Pipewire not a dependency?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

On Saturday, 1 October 2022 15:57:03 BST Mark Knecht wrote:
> On Sat, Oct 1, 2022 at 7:51 AM Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> > On Saturday, 1 October 2022 15:08:40 BST Michael wrote:
> > > On Thursday, 29 September 2022 15:11:02 BST Nikos Chantziaras wrote:
> > > > On 28/09/2022 13:57, Michael wrote:
> > > > > 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.
> 
> 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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Pipewire not a dependency?

[Wol]

On 01/10/2022 17:56, Michael wrote:
> 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

Re: [gentoo-user] Re: Pipewire not a dependency?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Saturday, 1 October 2022 18:11:19 BST Wol wrote:
> On 01/10/2022 17:56, Michael wrote:
> > 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.  :-/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Pipewire not a dependency?

[Daniel Sonck]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On zaterdag 1 oktober 2022 19:11:19 CEST Wol wrote:
> On 01/10/2022 17:56, Michael wrote:
> > 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.
> 
> 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.
> 
> Cheers,
> Wol

Regards,

Daniel

[-- Attachment #2: Type: text/html, Size: 3956 bytes --]

[gentoo-user] Re: [SOLVED] Pipewire not a dependency?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Saturday, 1 October 2022 19:32:11 BST Daniel Sonck wrote:
> On zaterdag 1 oktober 2022 19:11:19 CEST Wol wrote:
> > On 01/10/2022 17:56, Michael wrote:
> > > 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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Pipewire not a dependency?

[Nikos Chantziaras]

On 01/10/2022 19:56, Michael wrote:
> 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.

[gentoo-user] Re: [SOLVED] Pipewire not a dependency?

[Nikos Chantziaras]

On 02/10/2022 12:47, Michael wrote:
> 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.

Re: [gentoo-user] Re: [SOLVED] Pipewire not a dependency?

[Håkon Alstadheim]

Den 02.10.2022 11:47, skrev Michael:
> On Saturday, 1 October 2022 19:32:11 BST Daniel Sonck wrote:
>> On zaterdag 1 oktober 2022 19:11:19 CEST Wol wrote:
>>> On 01/10/2022 17:56, Michael wrote:
>>>> 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"
>
> 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.

Re: [gentoo-user] Re: [SOLVED] Pipewire not a dependency?

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

On Monday, 3 October 2022 22:48:09 BST Håkon Alstadheim wrote:
> Den 02.10.2022 11:47, skrev Michael:
> > On Saturday, 1 October 2022 19:32:11 BST Daniel Sonck wrote:
> >> On zaterdag 1 oktober 2022 19:11:19 CEST Wol wrote:
> >>> On 01/10/2022 17:56, Michael wrote:
> >>>> 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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]