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

    From Nikos Chantziaras@21:1/5 to Michael on Sun Oct 2 13:50:01 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?H=c3=a5kon_Alstadheim?=@21:1/5 to All on Mon Oct 3 23:50:01 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Mon Oct 3 23:16:18 2022
    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


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmM7XzIACgkQseqq9sKV Zxmq/xAAirLZr22y9XXWr8Dvhe27bCX7P3w2iCe1jl3ZSX9u4fgdTHGSB+U0B88O 4vOCBwKFcnWSbDtEkwg1xHs4b3uB5bIL/aXhGzsAZCLQNCLahEnHqeBk+V0/XPze px32MBKNS+2maCgXJBpdxZKWdVKxa4E7WnDaKywTtpPxgwXg8KbW5QDHRibh7e36 9HW4lzxER6LwmMvWK4MOnPJcEdvan6+DUrZAHmQd3sEpuCWt83bGspP63M6yjd4T +uX3qcfD7bqwdzyWnXAg4jKcS9dc2y+Q+as5cnoOhOgcd0ekrCICoqdHjnun83rQ Wr/bWq2nOqMR5KCCMeZipOCTY65e3/0f8uU9Q9SPDtcSUr60V2aT2Nm8vHzYhCYA ACH1GWDTL7Cc9RRW802FGxxAj00QxcJFrQBDMTwt/ZIPD3ecpwhkYfxP37jfjJe8 EYJxIoOGOUmEO7mfdQ2HK+nNUWMRFxARj5cPNAJiWTrai6+vTjAFGNUC6o30qy99 cmD7qiScJh7VngUO9FMGTtN3hl4oaJcEGqbeM7vbA/LyPDEs0e7gUtraLfjSj9Z+ edbABqhd3dT2hnRZw1ATVZ/OLF2QlZPvjn3Q0z6rhmVYwJ+mb3oUBbsbSXZTuhaA kt4foNfbzAG0VMLyk1GHO/NC5dXKg0LO2ttgCKSnUczP48pJxxM=
    =ZQ18
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)