| Summary: | Volume sliders freeze with wireplumber | ||
|---|---|---|---|
| Product: | [Plasma] plasma-pa | Reporter: | iodreamify |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | aleixpol, isma.af, jessica, sdar, selpix, sitter, untrustservices |
| Priority: | NOR | ||
| Version: | master | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | video | ||
I have exactly the same issue on plasma 6.1.4. (On my old plasma machine 5.27.10 works fine) Can confirm, can be reproduced with "plasmawindowed org.kde.plasma.volume" Yeah I am not sure we can do anything here. Looks like a wireplumber/pipewire regression compared to pulseaudio. We simply forward the GUI events (depending on size, some 500 events if you move the bar from start to finish) and what appears to happen it that the daemon cannot keep up with the amount of changes and so the actual update of the volume is severely delayed (which makes it look like the slider is stuck - it's really just waiting for the daemon to report the new volume). For good measure I've tried to cancel operations as new volumes get set, but that doesn't help either. So, we don't really have any way to deal with this on the client side I think. Please file a bug upstream. (In reply to Harald Sitter from comment #3) > Yeah I am not sure we can do anything here. Looks like a > wireplumber/pipewire regression compared to pulseaudio. We simply forward > the GUI events (depending on size, some 500 events if you move the bar from > start to finish) and what appears to happen it that the daemon cannot keep > up with the amount of changes and so the actual update of the volume is > severely delayed (which makes it look like the slider is stuck - it's really > just waiting for the daemon to report the new volume). > > For good measure I've tried to cancel operations as new volumes get set, but > that doesn't help either. So, we don't really have any way to deal with this > on the client side I think. Please file a bug upstream. filed upstream: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/724 |
Created attachment 168634 [details] video SUMMARY My volume sliders freeze up if i'm too quickly dragging them to change volume. This only happens if i drag them with the mouse, not while changing volume via keyboard or via the scrollwheel. I've noticed wireplumber cpu usage goes to 100% on one core. if i downgrade wireplumber to 4.17 it gets better but still a bit janky. Happens on both x11 and Wayland. I am unsure if this is a kde bug since an earlier version of wireplumber works better but this issue does not happen on xfce4 at all. STEPS TO REPRODUCE 1. have wireplumber ver 5.1 running 2. change system volume via any slider, either in the sound applet or in systemsettings OBSERVED RESULT Slider freezes for a while EXPECTED RESULT Slider is smooth SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-arch1-1 (64-bit) Graphics Platform: Wayland