Re: [gentoo-user] Re: Pipewire not a dependency?
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
Re: [gentoo-user] Re: Pipewire not a dependency?
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. :-/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Pipewire not a dependency?
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?
On Saturday, 1 October 2022 15:57:03 BST Mark Knecht wrote: > On Sat, Oct 1, 2022 at 7:51 AM Peter Humphrey 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. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Pipewire not a dependency?
On Sat, Oct 1, 2022 at 7:51 AM Peter Humphrey 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
Re: [gentoo-user] Re: Pipewire not a dependency?
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?
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. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: problem with emerge depclean after world update
On 2022-09-30, John Covici wrote: > Hi. So, when I tried to do my emerge depclean after my world update, > which went through with no problems, I get the following message: > > Calculating dependencies... done! > * Dependencies could not be completely resolved due to > * the following required packages not being installed: >* > * >=app-text/poppler-0.16.0:0/123=[cairo] pulled in by: > * app-misc/tracker-miners-3.4.0 > > But I have: > > ebuild R] app-text/poppler-22.09.0:0/124::gentoo USE="cairo cxx > introspection jpeg jpeg2k lcms png qt5 tiff utils -boost -cjk -curl > -debug -doc -nss -verify-sig" > and > ebuild R] app-misc/tracker-miners-3.4.0:3::gentoo USE="exif gif > gstreamer iso jpeg networkmanager pdf playlist rss (seccomp) tiff > upower xml -cue -ffmpeg -gsf -iptc -raw -test -xmp -xps" > > So, what have I done wrong this time -- or is it some kind of bug > somewhere? > > Thanks in advance for any suggestions. When was tracker-miners-3.4.0 last built? It RDEPENDS on [1]: ">=app-text/poppler-0.16.0:=[cairo]" So if tracker-miners was built with poppler:0/123, and if I'm understanding "man 5 ebuild" correctly, it will require a 0/123-slotted version of poppler to be installed. Given that tracker-miners accepts any later version, rebuilding it will hopefully be enough. [1] https://gitweb.gentoo.org/repo/gentoo.git/tree/app-misc/tracker-miners/tracker-miners-3.4.0.ebuild#n47 -- Nuno Silva
Re: [gentoo-user] problem with emerge depclean after world update
On Fri, 30 Sep 2022 21:27:16 +0100, Wol wrote: > Does that mean an update typically cleans a replaced package > automagically? I thought that usually they got left behind and that was > why you needed depclean - to remove all the old versions? > > Certainly that's what I remember of depclean of old - the list of stuff > being cleaned was mostly old versions of what was installed. That is when updates to slotted packages are installed, wait until the next llvm/clang update. Old versions of a package in the same slot, or slot 0 for unslotted packages, are replaced with the new one, but new slots cause the behaviour you have seen. -- Neil Bothwick Why is there an expiration date on sour cream? pgpR7BgnJ98AO.pgp Description: OpenPGP digital signature
