Re: JACK rtprio=60, PipeWire rtprio=88: Why?
I think the main reason is that I was not aware of this policy and so we chose some random numbers. The parameters are configurable at build time and I can add these limits. Wim On Wed, Feb 14, 2024 at 7:30 PM Runiq via devel < devel@lists.fedoraproject.org> wrote: > Hey, > > I intend to pull the rtirq package [1] back into this decade and > realized there's a discrepancy between the priorities of JACK and > PipeWire realtime threads. > > JACK's is at 60, per the decision made in Fedora 17 [2]: > > ``` > $ ps -p 109009 -Lo tid,class,pri,rtprio,command > > TID CLS PRI RTPRIO COMMAND > 109009 TS 19 - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2 > 109023 TS 19 - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2 > 109024 TS 19 - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2 > 109025 FF 60 20 jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2 > 109026 TS 19 - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2 > ``` > > Accordingly, the jackuser group rtprio limit is set to 70: > > ``` > # /etc/security/limits.d/95-jack.conf > @jackuser - rtprio 70 > @jackuser - memlock 4194304 > > @pulse-rt - rtprio 20 > @pulse-rt - nice -20 > ``` > > On the other hand, PipeWire's realtime thread runs with prio 88: > > ``` > $ ps -p 4453 -Lo tid,class,pri,rtprio,command > TID CLS PRI RTPRIO COMMAND > 4453 TS 30 - /usr/bin/pipewire > 4460 FF 128 88 /usr/bin/pipewire > ``` > > And the group gets an rtprio limit of 95: > > ``` > # /etc/security/limits.d/25-pw-rlimits.conf > @pipewire - rtprio 95 > @pipewire - nice-19 > @pipewire - memlock 4194304 > ``` > > Is there a reason for this discrepancy? Apart from the already mentioned > email acknowledging the policy change in Fedora 17 [2], I couldn't find > anything else about that. Since both Pipewire and JACK fill similar > roles, I would have expected them to both have similar rtprio values. > > I've also posted this to Ask Fedora [3]. > > Best regards, > Patrice > > [1] https://src.fedoraproject.org/rpms/rtirq > [2] > https://cm-mail.stanford.edu/pipermail/planetccrma/2012-May/018018.html > [3] https://discussion.fedoraproject.org/t/105188 > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Tue, Feb 8, 2022 at 2:17 AM Neal Gompa wrote: > On Mon, Feb 7, 2022 at 8:12 PM Kevin Kofler via devel > wrote: > > > > Miro Hrončok wrote: > > > gstreamer1 orphan, uraeus, wtaymans1 > weeks > > > ago > > > gstreamer1-plugins-baseorphan, uraeus, wtaymans1 > weeks > > > ago > > > gstreamer1-plugins-goodorphan, uraeus, wtaymans1 > weeks > > > ago > > > > How did the gstreamer1 stack end up orphaned? Pretty much the entire > desktop > > world, across all desktop environments, depends on it! > > > > Wim Taymans, who actually maintains it, hasn't actually been set as > the primary maintainer. He needs to pick them up and become the > official main maintainer. > > Done. Wim > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pipewire memory usage
I can get it as high as that too but then it stays there and doesn't really grow anymore so it does not seem like it's leaking. Maybe it's the way things are done, there is a lot of ldopen and memfd/mmap. Wim On Mon, Dec 13, 2021 at 11:42 PM Dominique Martinet wrote: > Wim Taymans wrote on Mon, Dec 13, 2021 at 09:22:42AM +0100: > > There was a leak in 0.3.40 that could explain this, see > > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1840 > > > > Upcoming 0.3.41 will have this fixed. At least I can't reproduce this > > anymore with the test you posted below. > > Thanks for testing! > > I've also taken the time of rebuilding pipewire from source (current > master, just on top of 0.3.41) but unfortunately it doesn't look like it > solves the issue here, so it must be something specific in my > environment. > > fresh start: > myuser 335184 1.0 0.0 56384 11596 ?S /opt/pipewire/bin/pipewire > myuser 335197 2.7 0.0 36000 11480 ?S /usr/bin/pipewire-media-session > myuser 335208 0.5 0.0 31312 6428 ?S /opt/pipewire/bin/pipewire-pulse > > after running 100 mpv like last time: > myuser 335184 5.3 0.3 174836 63360 ?S /opt/pipewire/bin/pipewire > myuser 335197 1.6 0.0 36708 12336 ?S /usr/bin/pipewire-media-session > myuser 335208 9.2 2.1 666020 341196 ? S /opt/pipewire/bin/pipewire-pulse > > > > `pactl stat` is happy though: > Currently in use: 89 blocks containing 3.4 MiB bytes total. > Allocated during whole lifetime: 89 blocks containing 3.4 MiB bytes total. > Sample cache size: 0 B > > I've run out of free time this morning but since it's not a known issue > I'll debug this a bit more after getting home tonight and report an > issue proper. > Since it's easy to reproduce here I'm sure I'll find the cause in no > time... > > -- > Domnique > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: pipewire memory usage
There was a leak in 0.3.40 that could explain this, see
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1840
Upcoming 0.3.41 will have this fixed. At least I can't reproduce this
anymore with the test you posted below.
Wim
On Sun, Dec 12, 2021 at 12:49 PM Dominique Martinet
wrote:
> Fabio Valentini wrote on Sun, Dec 12, 2021 at 12:25:11PM +0100:
> > > on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR,
> > > but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR.
> > > 56M is okeyish, but 347M seems a lot. I think firefox is going
> > > through pipewire-pulse, so that interface might be getting more use
> > > than native pipewire. But what are the expected values for this?
> >
> > That certainly seems high to me. On my system I see values like
> > - pipewire: resident memory ~18M, shared memory ~8M
> > - pipewire-pulse: redident memory ~19M, shared memory ~6M
> > even while playing audio from firefox, for example.
> >
> > Where did you get those RSS values?
> > I checked in gnome-system-monitor and with ps -aux, and both reported
> > the same values for resident memory (RSS).
>
> To add another datapoint I also have always seen pretty high RSS usage
> from pipewire-pulse:
>
> $ ps aux|grep pipewire
> myuser 14645 0.5 0.4 198772 79100 ?Ssl Dec07 38:08
> /usr/bin/pipewire
> myuser 14646 0.6 3.4 713516 555756 ? SLsl Dec07 45:29
> /usr/bin/pipewire-pulse
> myuser 14652 0.0 0.0 38112 12228 ?Sl Dec07 0:04
> /usr/bin/pipewire-media-session
>
> (so 555MB RSS)
>
>
> I've also noticed that the background cpu% usage seems to increase, so
> I'd say the memory is still reachable somewhere and there must be some
> list getting big and skimmed through from time to time; restarting the
> pipewire processes when I start seeing them climb too high in htop makes
> them behave again...
>
>
> ... Okay, so there's an obvious leak when pulse clients connect and
> leave on pipewire-0.3.40-1.fc34.x86_64, about 3MB per client (!).
>
>
> I've just pkill pipewire to restart it:
> asmadeus 293661 0.5 0.0 31612 7276 ?S /usr/bin/pipewire-pulse
> asmadeus 293675 1.5 0.0 56092 11488 ?S /usr/bin/pipewire
> asmadeus 293678 5.0 0.0 37528 12364 ?S /usr/bin/pipewire-media-session
>
> then ran mpv in a tight loop, 100 times:
> for i in {1..100}; do mpv somefile.opus -length 1 & done; wait
> (pulseaudio output)
>
> and rss climbed to 313MB:
> asmadeus 293661 2.6 1.9 689228 313832 ? S /usr/bin/pipewire-pulse
> asmadeus 293675 1.8 0.4 188392 76844 ?S /usr/bin/pipewire
> asmadeus 293678 0.5 0.0 38168 12672 ?S /usr/bin/pipewire-media-session
>
> another 100 times brings it up to 652'672.
>
> I had noticed that firefox likes to create new output streams and closes
> them everytime there's a video, even if sound is muted, so I'd think
> that on some sites it would behave quite similarly to that.
>
>
> I've uploaded pw-dump after this if that's any help:
> https://gaia.codewreck.org/local/tmp/pw-dump
>
> But it should be easy to reproduce, I don't think I have anything
> too specific sound-wise here...
>
>
> Happy to open an issue upstream if there isn't one yet, I haven't had a
> look. Trying to reproduce on master would likely be first.
> Please let me know if you take over or I'll look into it further over
> the next few days...
> --
> Dominique Martinet | Asmadeus
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)
Also, I forgot to change the status to ReadyForWrangler so it has been in limbo for a while. But meanwhile, we've been busy moving the parts into f35 for testing. Next step is to check all of the stuff we added to the old session manager and make sure we don't cause regressions. I'll update the wiki with more info on how to test. Wim On Tue, Jul 20, 2021 at 6:10 PM Ben Cotton wrote: > For the record, this proposal isn't late. I just forgot what day it > was yesterday. *Today* is the deadline. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PA module support in PipeWire
On Tue, Feb 23, 2021 at 3:13 PM Neal Gompa wrote: > On Tue, Feb 23, 2021 at 8:16 AM Kevin Kofler via devel > wrote: > > > > Lóránt Perger wrote: > > > I suppose I should have looked a bit more into this before opening this > > > thread, but oh well, no use crying over spilled milk. I looked into > how PW > > > replicates PA's module loading... and turns out it doesn't ( > > > > https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/module.c#L146 > > > ). It simply uses an strcmp to check for a single module, which it then > > > replicates. > > > > I also see that the device manager extension is not supported: > > > https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/extension.c#L44 > > so configuring output and input devices in the Phonon KCM (in KDE/Plasma > > System Settings) is not going to work with PipeWire. > > > > What are you talking about? I seem to be able to select devices and > such. The only thing I don't seem to be able to do is do "advanced > audio settings" which is grayed out and says it requires the > PulseAudio gsettings module. If there's additional functionality > missing, please file an issue at > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues. > > > There is already an issue for this and some discussion about that is missing: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/771 Wim > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
Hi, > In particular I'm worried alsa programs will stop working. There is a pipewire-alsa package to support alsa programs > Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's > pulseaudio implementation? It is but then you go through an extra layer of emulation, it's better to remove the pulseaudio one and use the pipewire one if you remove the pulseaudio daemon. > (I see there's also an alsa-plugins-jack, I guess that might work but I > don't have it installed right now; This should also work but again using an extra layer of emulation. > or some new alsa-plugins-pipewire > should be pulled in at least to keep things working one way or another) Yes, it should somehow be pulled in, how should that be done? A Suggests: for pipewire-pulse maybe? Wim On Tue, Dec 15, 2020 at 8:09 AM Dominique Martinet wrote: > Gary Buhrmaster wrote on Mon, Dec 14, 2020: > > On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab > > wrote: > > > > > # dnf swap pulseaudio pipewire-pulseaudio --allowerasing > > > > I needed to add --enablerepo=updates-testing > > With updates-testing enabled here, it's much better than last month (no > more gdm being removed), but there still are a few pulseaudio direct > dependencies: > # dnf swap pulseaudio pipewire-pulseaudio --allowerasing > Last metadata expiration check: 0:10:19 ago on Tue 15 Dec 2020 07:52:26 > CET. > Dependencies resolved. > > == > Package ArchVersion Repository > Size > > == > Installing: > pipewire-pulseaudio x86_64 0.3.17-3.fc33 updates-testing > 14 k > Upgrading: > pipewire x86_64 0.3.17-3.fc33 updates-testing > 118 k > pipewire-gstreamer x86_64 0.3.17-3.fc33 updates-testing > 52 k > pipewire-libsx86_64 0.3.17-3.fc33 updates-testing > 922 k > Removing: > pulseaudio x86_64 14.0-2.fc33 @updates-testing > 4.0 M > Removing dependent packages: > alsa-plugins-pulseaudio x86_64 1.2.2-3.fc33@fedora > 121 k > pulseaudio-module-bluetooth x86_64 14.0-2.fc33 @updates-testing > 231 k > pulseaudio-module-x11x86_64 14.0-2.fc33 @updates-testing > 78 k > xfce4-pulseaudio-plugin x86_64 0.4.3-3.fc33@fedora > 447 k > > > In particular I'm worried alsa programs will stop working. > Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's > pulseaudio implementation? > (I see there's also an alsa-plugins-jack, I guess that might work but I > don't have it installed right now; or some new alsa-plugins-pipewire > should be pulled in at least to keep things working one way or another) > > -- > Dominique > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
So, the current sentiment is: * provide an easy way to test in f33, either copr or with regular packages. - rawhide is a not a good place to get good testing anyway * encourage people to test. Provide instructions on how to do this and how to leave feedback. * Carry this over to f34, probably with just the packages/easier switch. * propose permanent switch for f35 - it gets at least full cycle of testing (f34 + part of f33) * re-evaluate situation for f35 beta freeze to make a default switch. Although a bit slower than expected, I guess more testing is good. It sounds like an acceptable plan to me. I'm not sure how it works, if spinoffs can/want to make an earlier switch? Wim ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
Hi all, First of all, thanks for the comments, keep them coming. We have seen these concerns many times before with big infrastructure changes like pulseaudio or wayland or systemd. I think they are necessary to keep our feet on the ground and not get carried away by our pipe dreams (pun intended). As the author of PipeWire and creator of this Change proposal, I will try to address some of the concerns I see here in the comments: > It needs more testing... This change request is about enabling PipeWire audio by default *for testing* in a testing environment. I'm proposing this because I think it is ready for *testing*. I hear some claims that it is too early to test; as the main developer, I disagree. It's not too early to test. People have been running PipeWire as the main audio backend for some time now, and so can you. The goal when enabling this by default is to have a nicely integrated solution that people can try, test and revert. This will give us more testers and feedback and bring us closer to the final goal. > but I can't even enable it to test! packages don't install and have conflicts! We're working on getting the dependencies right on other packages so that we can actually swap implementation. Should we have waited until this works better? perhaps. We ask for some patience until this is fixed, I expect this to be testable next week. Stay tuned for an update. > This is going to be so buggy, why do this to us The feedback from early testers give me confidence that it will not be all doom. There will be bugs, they will get fixed and you'll have to retest. It is how to move forward. By the end of the testing and the beta freeze we end up with a nice list of bugs and must-have features that people found (or not) and we roll back (or not). > why bother, this will fail and we'll have to roll back anyway I have no problem whatsoever with rolling back after an honest round of testing. This proposal will be resubmitted for the next release and we try again. But, this would be all pointless without taking the risk to actually test the new things first. > it's still in active development A project like this takes time to develop and will hopefully be in active development for many more years. There are so many ideas remaining... Development of the video parts started in early 2017, more than 3 years ago and ended up in fedora 27 as a dependency for screencasting. Development and testing of the redesigned audio core started in june 2018 and ended up in Fedora 32. You could already test the audio on f32 and some people did. The core audio parts and API/ABI has been stable since february 2020. Since then we've been working on the use cases, management of devices and streams and tools. We've had a crew of early testers and incredible feedback. I believe It's ready for more testing. > but the pulseaudio replacement server is only 5 weeks old! It is and it works very nicely indeed, I want you to try it. What's more impressive is that it does not take a lot of complicated code to implement this on top of PipeWire. > It's not ready, it needs to mature more, it's too early This may be true but it's too early to make that decision without giving it a round of testing first, IMHO. There are things that are not implemented yet but I think those are not important enough to block general testing. Some thing might simply not be implemented either (like ESD compatibility) and will cause regressions. I want to know what's important for people, what are must-haves. > there is not enough time to test Perhaps not and then we need to roll back and test more in the next rawhide. It should not stop us from starting to test now, when the developers think it's ready for testing. I don't know how to measure when 'enough testing' has been done. It ultimately depends on how confident people feel after using it for a while. > I've tried it and it doesn't work You have not tried what we propose for rawhide and f34 because there is no easy way to install this yet, please stay tuned. We're going to be fixing the dependencies and upgrading to the latest versions to make this easy. Also please tell us what is wrong and please try again after a fix landed. Much of the instability with browsers and music players got fixed after the pulseaudio replacement server was implemented. > but I don't want to test all this This is ok, I can understand that you don't want to deal with possible audio problems. You will have to install pulseaudio again and opt out. You will have to hope that other people do sufficient testing. It is a bit strange when you are running rawhide, but hey. > but this and that is broken, it's all pointless, why bother, you'll never get > this fixed in time Maybe so. Please let us know what's broken. It might be an easy fix and we can retest an updated version. Or not, and then it's a blocker and we roll back. But you have to let us know. So my
libvpx 1.3.0 ABI break
Hi all, libvpx-1.3.0 unexpectedly broke ABI without updating the .so name. See more info here https://bugzilla.redhat.com/show_bug.cgi?id=1068664 I'm rebuilding the gstreamer 0.10 and 1.0 packages now but there are more packages depending on libvpx. Wim ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
