| Summary: | Audio volume applet experiences GUI introduced thread blocking when sliding volume slider with a high polling rate mouse | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Li Jiajun <wlmqljj> |
| Component: | Audio Volume widget | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | droidgoo, isma.af, john.kizer, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| URL: | https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/724 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
A GIF showing the issue of GUI Animation rendering thread blocking issue of PA applet.
OSD of volume control is delayed and irratic using the keyboard media volume control |
||
experienced similar delays / misbehavior controlling the volume using the media volume knob on my razer huntsman V2 keyboard where the OSD would lag and often go the opposite direction from the hardware inputs... but with enough GUI attention, it would settle down and behave normally as if it were distracted or not getting the focus it needed to work properly until it was forced to (if that makes sense). this started after upgrading from kubuntu 22.04 to 24.04 and the accompanying transition from pulse audio to pipewire. also noteworthy is that using the mouse wheel while hovering over the volume icon in the system tray is reliable and responsive so it likely has something to do with specifics of the input device not getting the attention of the plasma shell quick enough (random speculation). Created attachment 181577 [details]
OSD of volume control is delayed and irratic using the keyboard media volume control
Hi - looking into other related reports, this appears to be the same underlying issue as another report, and looks to be an upstream issue with the wireplumber component that handles the underlying volume-setting: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/724 Thanks! *** This bug has been marked as a duplicate of bug 485711 *** |
Created attachment 181568 [details] A GIF showing the issue of GUI Animation rendering thread blocking issue of PA applet. SUMMARY I noticed that when I use a gaming mouse with a high polling rate (1000Hz) to drag the volume slider of the Plasma PulseAudio Applet, there is a significant delay due to GUI rendering thread blocking. STEPS TO REPRODUCE 1. Use a gaming mouse with a 1000Hz report rate. 2. Drag the volume slider of the PulseAudio Applet back and forth. OBSERVED RESULT There is noticeable delay and lag in volume adjustment, slider movement, and OSD animation. See the attached image for reference. EXPECTED RESULT When using a high-report-rate input device, the computing does not need to be so precise. Reducing the computational burden of animations or preferably handling related logic asynchronously would be ideal. SOFTWARE/OS VERSIONS Windows: Not relevant macOS: Not relevant (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: Manjaro / Plasma 6.3.5 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 ADDITIONAL INFORMATION See the attached Gif image for reference.