search

digimezzo / dopamine

The audio player that keeps it simple
https://digimezzo.github.io/site/
GNU General Public License v3.0
1.56k stars 111 forks source link

Verify CPU usage after playing mutliple songs #158

Open digimezzo opened 3 years ago

digimezzo commented 3 years ago

Reported by @g-yui:

I think something's leaking, since CPU usage increases per each song played, got from 0.34% CPU usage to almost 4% through my testing. To recreate you can just boot up Dopamine and just start clicking on the next song for a bit, memory doesn't seem to leak thus far though, always returning to 275-ish MB for Private Bytes and 170-ish MB for Private WS (this latter one being the one you can see in the Windows Task Manager as RAM usage).

ghost commented 3 years ago

The cause of the high cpu usage seems to be related to "CrRendererMain", it's on a thread that gets called by -type=renderer, I think it may have something to do with said renderer still calculating for GUI components (Name, thumbnail, etc) of already played songs, this high cpu usage happens even when the app is minimized. The renderer does not affect audio playback itself in any way, as it is to be expected, this is made obvious by simply suspending the thread, it does however make it so that the song that would play just won't until the thread is resumed, upon doing so the next song will start playing, but the CPU usage of the renderer will stay as it was before suspending it. By spamming the next song button I managed to make it use about 9% of my CPU while minimized and around 11% when shown, from 0.4% to 9% , that's quite a big leak... For context, the CPU print of audio playback itself is just 0.3% CPU usage at max, using less than that most of the time.

On further testing, there's small hints to a small memory leak present at times as well, of about 1MB per song played, but the program does clean itself after a bit , this happens every time I've tested it, returning to a rather stable ram usage, so no full-on memory leaks for now!

AKmatiAK commented 2 years ago

I also noticed increasing CPU usage, after playing some songs it becomes so high that music is intermittent.

Ilya0S commented 1 year ago

Came to comment on this (coming from Windows, version 2.0.9). I haven't checked CPU load, but use time when stuttering and other sound irregularities start as a relative metric. Using Ryzen 7 1800X CPU.

What I've also noticed is that the more tags info there is, the bigger load gets. For example, if I play only songs with pretty big album arts (2500x2500+), double digit number of songs would be enough to get player to start stuttering (usually 1h and something, without much song skipping), while with somewhat normal album arts (closer to 1000x1000) it would be closer to 100 needed (5 hours or so). Editing lyrics, especially timestamping them, seems to make it faster, sometimes I have to reboot the player every half an hour. Considering that songs themselves are somewhat close in size to each other, I think it might be tags cache, and covers specifically as the largest part, plus lyrics.

I'm not very experienced in programming, but a workaround could be to dump song's cover and lyrics cache immediately after finishing playing that song. Considering stuttering could start while playing the same album with the same cover and no lyrics, I think it saves cache for every song's cover individually, which would mean it shouldn't cause problems if you dump it. Lyrics aren't shared anyway, so the same thing. Do note that it wouldn't fix the problem, only slow its build-up. Well, even if this workaround is dumb or impossible to implement, I hope at least my conclusions would be helpful somehow.

p-yukusai commented 1 year ago

Leakage is often about not dumping all that is unused, I believe, as you said, that the song's cache for both the tags and the audio are not being deleted after usage, as the load doesn't get smaller after changing songs and changing between two songs does not make any changes in the load, outside those related to the GUI updates.