#685 I found the cause of high CPU usage.

[Anonymous]

Originally created by: pcman...@gmail.com

It's a known problem that qmmp had higher CPU resource usage than other similar players.
After some hacking, I found two of the possible causes.
The bugs are in several files:
1. volumecontrol.cpp:
The QTimer signals fire too frequently. Signals/slots are heavier than ordinary function calls. Besides, you do it every 150 ms. This too-frequent polling of volume makes the program very busy. I'd suggest that you re-design this part and avoid polling if possible.
If you try to add a "return;" before "m_timer = new QTimer(this);" in the contructor of VolumeControl, you can see the CPU usage lowered partially.

2. qsuianalyzer.cpp:
The same problem, a QTimer which is trigerred too frequently. The timer even runs unconditionally when the songs are not being played.

3. qmmp-plugin-pack/src/UI/qsui/mainwindow.cpp:
After commenting out these lines, CPU usage got lowered.
#if 0
    connect(m_volumeAction, SIGNAL(triggered(bool)), m_core, SLOT(setMuted(bool)));
    connect(m_volumeSlider, SIGNAL(valueChanged(int)), m_core, SLOT(setVolume(int)));
    connect(m_core, SIGNAL(volumeChanged(int)), m_volumeSlider, SLOT(setValue(int)));
    connect(m_core, SIGNAL(volumeChanged(int)), SLOT(updateVolumeIcon()));
    connect(m_core, SIGNAL(mutedChanged(bool)), SLOT(updateVolumeIcon()));
    connect(m_core, SIGNAL(mutedChanged(bool)), m_volumeAction, SLOT(setChecked(bool)));

    m_volumeSlider->setValue(m_core->volume());
    updateVolumeIcon();
    //visualization
    m_analyzer = new QSUiAnalyzer(this);
    m_ui.analyzerDockWidget->setWidget(m_analyzer);
    Visual::add(m_analyzer);
    //filesystem browser
    m_ui.fileSystemDockWidget->setWidget(new FileSystemBrowser(this));
    //cover
    m_ui.coverDockWidget->setWidget(new CoverWidget(this));
    //playlists
    m_ui.playlistsDockWidget->setWidget(new PlayListBrowser(m_pl_manager, this));
#endif

I guess the slots are called too frequently since the volume events and the analyzer all suffered from QTimer problems.

I don't have a patch for these problems at the moment, but I tried to comment out different parts of qmmp to see if the CPU usage is lowered. Then I spotted these potential causes.
Hope that this helps fix the issue. Qmmp will be perfect if the bug is fixed.
Thank you.

[Anonymous]

Originally posted by: pcman...@gmail.com

Forgot to provide more information.
I use Ubuntu 14.04.
Besides, I'm using pulse audio, but alsa plugin is in use.
I guess this will affect the result.
If you need some more info, I'll do my best to see if I can help.
Thank you very much.

[Anonymous]

Originally posted by: pcman...@gmail.com

In addition, I'm not using soft volume. So in theory, it's OutputALSA that's working, which in turns is redirected to pulse audio.
To monitor the change of volume, it might be better to utilize  snd_mixer_poll_descriptors() to get some fd. Then the changes of the alsa mixer can be monitored via poll() system call and this event-driven design will be more efficient than continuous polling using a timer.

[Anonymous]

Originally posted by: pcman...@gmail.com

Also, it might be related to a known bug in Qt4.
https://bugreports.qt-project.org/browse/QTBUG-7618
This seems to be related to glib integration, too.
Qt on ubuntu is compiled with glib integration turned on.

They seems to fix it for Qt 5 only.
https://codereview.qt-project.org/#change,29063

For Qt4, there is no fix at the moment.
So I'd say in Qt4 it's better to avoid these timers if possible.

[Anonymous]

Originally posted by: pcman...@gmail.com

Some more tests:
1. The main cause of the higher CPU usage is the frequent repaint of analyzer. When playing the music, frequent update is inevitable so it's normal, but when the player is not playing anything, the analyzer is still repainted.  This can caused about 1-2% cpu usage on my system even when qmmp is not playing any music. The timer and repainting should be disabled when idle. This part needs some optimization.
2. The timer with 150ms interval in VolumeControl only contributes to a small (but still significant) fraction of cpu usage. When qmmp is idle, this generates 0.5% cpu usage on my system. Setting useSoftVolume to true can eliminate the cpu usage since frequent query of a variable is much cheaper than polling the status of a real audio device.
I'll try to see if I can provide any patch.

[Anonymous]

Originally posted by: pcman...@gmail.com

OK, I made a patch for the cpu usage caused by polling the mixer every 150ms.
The patch made the Volume class derive from QObject and adds a changed() signal for change notification.
A new virtual function Volume::hasChangeNotify() is added. The changed() signal is only supported when the backend returns true in hasChangeNotify().
Then, I implemented change notification for OutputAlsa with QSocketNotifier.
I haven't touch oss and oss4 backends, but they can be changed to support change notification later if needed.
The final result is, when change notification is available, VolumeControl uses it and avoid the QTimer with 150 ms interval completely.
Please review and see if the patch can be applied.
Thanks!

[Anonymous]

Originally posted by: pcman...@gmail.com

Yet another patch to decrease CPU usage when qmmp is idle.
The analyzer widget is being repainted in 25 fps even when qmmp is idle, which results the cpu usage.
This fixes the high cpu usage of simple UI when qmmp is not playing music.

[Anonymous]

Originally posted by: pcman...@gmail.com

The previous patch for analyzer is incorrect. Here is the new one.

[Anonymous]

Originally posted by: pcman...@gmail.com

A slightly improved version.

[Anonymous]

Originally posted by: trialuser02

Thank you for your patches :) I'll try to add them little later. I know about problem with glib event loop. I'm using QT_NO_GLIB environment variable to disable it. Unfortunately, cpu usage is not only one side effect of the glib events. Sometimes QTimer suddenly stops emitting timeout() signal. But, without glib event loop Qt has problem with standard gtk dialogs. So, you should use qmmp file dialog in this case.

Status: Accepted

[Anonymous]

Originally posted by: pcman...@gmail.com

Since we're using LXDE-Qt, there is no gtk+ file dialog. :-)
The glib mainloop indeed is weird sometimes. Is the bug you encountered related to Qt bug 32895?
https://bugreports.qt-project.org/browse/QTBUG-32859
The glib integration seems to be problematic. Maybe it will be improved in Qt 5?