Performance issue on KDE Plasma

[fusetim]

ytermusic is a great software and I enjoy using it. However, both my laptop and my desktop run on Linux (Arch Linux and NixOS) and I notice some performance issue.

More specifically, on my laptop, it seems that running the app makes the rest of the DE (KDE Plasma) really slow when I change volume and/or tracks. For instance, the way the volume slider interacts is very unreactive (it takes likes 1 or 2 seconds to actually de/increase the volume by 5%, a thing that you can "spam" usually).

Also, on desktop, this time running the app seems to make more laggy the switch between windows.

I know this bug report is really lacking details, and I hope maybe adding more info, but for now, these are the only info I can give. Nonetheless, if I had to make an educated guess, I would say it is related to the way you use the DBUS API, and would suggest a very high number of calls to the DBUS API, such important it starts to make lag the DE (the Audio apps, or more).

[ccgauche]

@fusetim Thanks for your feedback. I'll try installing my old laptop with Arch KDE so I can experience your issue.
I don't think this is related to DBus even through I'll have to try. Anyways it refreshes at most every second.
One issue that leads YTermusic to feel unresponsive is the bottleneck on the message passing queue that is read every 200ms and often waits for execution time on low core count processors. Or when very high CPU usage is observed.
I plan on rewriting some parts of YTermusic to be less concurrent and reduce the needs for message passing and task spawning in really high contention parts.
While I'm fixing that I can add a DBus setting in the config to you can disable it and tell me if it improves something.

One thought I just had at the end of this answer (I don't remember if my DBus calls are blocking or async maybe this blocks the main YTermusic thread).

[ccgauche]

@fusetim I added a test fix that makes calls to dbus lazy so we don't update if nothing changes + I added a config field in player called dbus that you can set to false to disable Dbus completely.

[fusetim]

Currently compiling it, can you just confirm that the config file should be ~/.config/ytermusic/config.toml ? It seems that it is a recent addition and I cannot find it there currently.

Also an another option is that it is an ALSA issue. I will also try to add a video démonstrating the issue.

[ccgauche]

Currently compiling it, can you just confirm that the config file should be ~/.config/ytermusic/config.toml ? It seems that it is a recent addition and I cannot find it there currently.

Also an another option is that it is an ALSA issue. I will also try to add a video démonstrating the issue.

I use the system default config folder.
I use a custom version of rodio as my audio backend. I never heard people talking about rodio performance issues.

A video would definitely be a plus. The config file will be autogenerated and named config.applied.toml with all default params. You can just rename it config.toml and modify dbus to false.

[fusetim]

Okay so the issue persists with or without dbus=false. Btw, I had to first create an empty config file otherwise the config.applied.toml does not show up.

[fusetim]

Here a video of the issue (note, the link will expire in 24h) : https://streamable.com/893jjh https://tempclip.com/fRMw7TIfTTokPxS/watch

[ccgauche]

Okay so the issue persists with or without dbus=false. Btw, I had to first create an empty config file otherwise the config.applied.toml does not show up.

Yep that's because of the unwrap_or_default()
That's really strange. Never had such a problem. Maybe it's caused by ALSA but I don't really know if I can prove that or even fix that.

[fusetim]

Okay so the issue persists with or without dbus=false. Btw, I had to first create an empty config file otherwise the config.applied.toml does not show up.

Yep that's because of the unwrap_or_default() That's really strange. Never had such a problem. Maybe it's caused by ALSA but I don't really know if I can prove that or even fix that.

Okay, well in the first place, I did not really expect a fix, but at least the issue is reported.

[ccgauche]

@fusetim An option to find if it comes from ALSA or at least something like rodio or CPAL would be to try using another music player based on the same stack to see if it has the same effect.

[Rustmilian]

@fusetim QQ, are you using pipewire or pulseaudio? I have an Arch KDE install and on Alpha & now on beta I haven't any such issues. Can you provide more detail on you're audio stack configuration? Also, are you using konsole? Thanks.
I'm currently trying to reproduce you're issues but can't seem too.