Version: 2.0.96 (using KDE 4.2.2) OS: Linux Installed from: Debian testing/unstable Packages Amarok goes into endless CPU usage loop after resuming from hibernation. It still plays music, but it uses up any free CPU time. I stop Amarok and start it again to get back to regular behavior. This is with Linux Kernel 2.6.29.2 with TuxOnIce 3.0.1 on an IBM ThinkPad T23 with 1133 MHz Pentium 3 CPU. martin@deepdance:~> amarok --version Qt: 4.5.1 KDE: 4.2.2 (KDE 4.2.2) Amarok: 2.0.96 (Debian 2.0.96-1) This didn't happen with Amarok from debian package 1.4.10-3+b1. I restart alsa-utils on resume: deepdance:/etc/hibernate> grep -i alsa-utils * common.conf:RestartServices alsa-utils anacron And unload USB sound module: deepdance:/etc/hibernate> grep -i snd-usb-audio * common.conf:UnloadModules snd-usb-audio deepdance:~> lsusb | grep M-Audio Bus 001 Device 002: ID 0763:2007 Midiman M-Audio Sonica Theater Otherwise the sound card did not work after resuming. I never tested whether that is still true with the current kernel. Anyway, this always used to work with Amarok 1.4.10. This issue might be a phonon problem. I will attach some information I gathered, mainly via strace, in a few moments.
Created attachment 33811 [details] cpuinfo Its running with 1133 MHz instead of the usual about 732 MHz during the bug happens.
Created attachment 33812 [details] strace statistic without threads strace -cp
Created attachment 33813 [details] strace statistic with threads strace -fcp
Created attachment 33814 [details] strace without threads strace -ttip. A lot of action happens during just one second.
Created attachment 33815 [details] strace with threads strace -fttip. Amarok threads are really quite busy it seems to me.
Created attachment 33816 [details] simple cpu usage monitoring for amarok every 5 seconds top -bd5 on Amarok process.
Created attachment 33817 [details] simple cpu usage monitoring for amarok every second top -bd1
I would assume that this is a Phonon issue (or an issue with its backend). Could you try to change your Phonon backend for testing purposes?
Sure. I will set it from xine which is set currently to gstreamer. Will likely take till the next snapshot cycle whether I know for sure.
Well no. With gstreamer-backend Amarok 2.0.96 doesn't work at all. It skips the first about ten tracks when I press play and then doesn't play anything. gstreamer backend does work in KDE. I hear test sound and startup / shutdown sound of KDE. martin@deepdance:~> apt-show-versions | egrep "(amarok|xine|gstreamer|phonon)" amarok/experimental uptodate 2.0.96-1 amarok-common/experimental upgradeable from 2.0.96-1 to 2.0.96-2 amarok-dbg/experimental uptodate 2.0.96-1 gstreamer0.10-alsa/squeeze uptodate 0.10.22-5 gstreamer0.10-ffmpeg/squeeze uptodate 0.10.7-1 gstreamer0.10-fluendo-mp3/lenny uptodate 0.10.7.debian-1 gstreamer0.10-plugins-bad/squeeze uptodate 0.10.10.3-1 gstreamer0.10-plugins-base/squeeze uptodate 0.10.22-5 gstreamer0.10-plugins-good/squeeze uptodate 0.10.14-2 gstreamer0.10-plugins-ugly/squeeze uptodate 0.10.11-1 gstreamer0.10-x/squeeze uptodate 0.10.22-5 libgstreamer-plugins-base0.10-0/squeeze uptodate 0.10.22-5 libgstreamer0.10-0/squeeze uptodate 0.10.22-3 libphonon4/squeeze uptodate 4:4.3.1-1 libxine1/squeeze uptodate 1.1.16.2-1+b1 libxine1-bin/squeeze uptodate 1.1.16.2-1+b1 libxine1-console/squeeze uptodate 1.1.16.2-1+b1 libxine1-ffmpeg/squeeze uptodate 1.1.16.2-1+b1 libxine1-misc-plugins/squeeze uptodate 1.1.16.2-1+b1 libxine1-plugins/squeeze uptodate 1.1.16.2-1 libxine1-x/squeeze uptodate 1.1.16.2-1+b1 libxinerama1/lenny uptodate 2:1.0.3-2 phonon/squeeze uptodate 4:4.3.1-1 phonon-backend-gstreamer/squeeze uptodate 4:4.3.1-1 phonon-backend-xine/squeeze uptodate 4:4.3.1-1 xine-ui/squeeze uptodate 0.99.5+cvs20070914-2.1 There is a new Amarok package coming. "amarok-common" is already available, but "amarok" build apparently did not finish yet. I will try the new package version once its available completely.
Bug happens also with updated amarok 2.0.96-2 debian package. But by accident I found a way to circumvent it. I usually press "Stop" before hibernating and then "Play" after resuming. This was the case that produced the high CPU load I described. The high CPU load even appeared after resuming before pressing on "Play", when Amarok was basically doing nothing but to wait for user input. Now when I do not press "Stop" before hibernating Amarok continues playing after resuming as if nothing had happened. And to my astonishment with the usual CPU load of around 10% at 732 MHz of an Mobile Pentium 3 CPU. Thus when I omit my usual work-around for hibernation the bug does not happen. I have no clue what to make of this.
As I said, it's very unlikely that Amarok itself is to blame for this, so I'm uncomfortable with keeping the report open as it is - we won't make any progress this way. We need to find someone who can test this with a different Phonon backend. This would probably be a step in the right direction.
As written phonon gstreamer backend did not work at all for me. I tried again, this time neither the phonon settings window called within Amarok nor the systemsettings one even remembered me setting gstreamer 0.10 engine. When I just selected it the apply button would not be unghosted thus I cannot apply the change. Thus I also changed the audio output. Then the apply button is unghosted. Amarok needed a restart to respect the change. It then really used the internal sound card instead of the USB one. But according to the Amarok phonon settings window sound engine was still xine although I did set gstreamer. I also was not able to set gstreamer engine via systemsettings. Everytime I left closed systemsettings and re-opened it again it showed me xine as engine. Changing back to the USB soundcard proved even more difficult. I was not able to do this from the Amarok phonon settings, even when restarting Amarok it still played on the internal sound card. Only changing it via systemsettings and restarting Amarok helped. How are these related? Does Amarok has its own phonon settings or does it use/change the global onces? It seems I should do about two or three bug reports against phonon first - and then we let this bug block on those. The phonon setting dialog behaves in a quite broken way here at the moment - it doesn't let me change some settings without a work-around, it discards settings I made or it remembers them, but doesn't apply them. In other words it behaves absolutely unpredictable. Any hints in which config file phonon writes the settings? I found a phonondevicesrc but it only contained a list of the detected sound devices. Any hint on where to find out which engine is really actually used? At best this would be some shell command as I do not know how much to give for the information that the settings dialog displays to me. Then I would try to get Amarok running with gstreamer engine first and file bug reports along the way until that backs and then we can come back to this bug report. Or maybe just reassign the bug to phonon and the what happens?
Debian will probably get 4.2.4 KDE packages in about a week or two. I don't know whether this includes new phonon packages. If so I could also restest with these once they are available. Currently I use: martin@deepdance:~> apt-show-versions | egrep "(amarok|phonon|xine|gstreamer)" amarok/experimental uptodate 2.0.96-2 amarok-common/experimental uptodate 2.0.96-2 amarok-dbg/experimental uptodate 2.0.96-2 amarok-utils/experimental uptodate 2.0.96-2 gstreamer0.10-alsa/squeeze uptodate 0.10.23-2 gstreamer0.10-ffmpeg/squeeze uptodate 0.10.7-1 gstreamer0.10-fluendo-mp3/lenny uptodate 0.10.7.debian-1 gstreamer0.10-plugins-bad/squeeze uptodate 0.10.10.3-1 gstreamer0.10-plugins-base/squeeze uptodate 0.10.23-2 gstreamer0.10-plugins-good/squeeze uptodate 0.10.14-2 gstreamer0.10-plugins-ugly/squeeze uptodate 0.10.11-1 gstreamer0.10-x/squeeze uptodate 0.10.23-2 libgstreamer-plugins-base0.10-0/squeeze uptodate 0.10.23-2 libgstreamer0.10-0/squeeze uptodate 0.10.23-1 libphonon4/squeeze uptodate 4:4.3.1-1 libxine1/squeeze uptodate 1.1.16.2-1+b1 libxine1-bin/squeeze uptodate 1.1.16.2-1+b1 libxine1-console/squeeze uptodate 1.1.16.2-1+b1 libxine1-ffmpeg/squeeze uptodate 1.1.16.2-1+b1 libxine1-misc-plugins/squeeze uptodate 1.1.16.2-1+b1 libxine1-plugins/squeeze uptodate 1.1.16.2-1 libxine1-x/squeeze uptodate 1.1.16.2-1+b1 libxinerama1/lenny uptodate 2:1.0.3-2 phonon/squeeze uptodate 4:4.3.1-1 phonon-backend-gstreamer/squeeze uptodate 4:4.3.1-1 phonon-backend-xine/squeeze uptodate 4:4.3.1-1 xine-ui/squeeze uptodate 0.99.5+cvs20070914-2.1
I upgraded to phonon 4.5.2 two days ago. Still no luck. High CPU usage after resuming from hibernation still present. Still can't test with gstreamer. I can select it now in systemsettings and it works there and with login and logout sounds. I see it selected when I call phonon settings from Amarok as well. But Amarok won't play with gstreamer. It skips one song after another until it says that it stopped due to too many errors in the playlist. Xine plugin works. As this problem only happens when I stop playback before hibernating I will just ignore it for now and retest with newer versions. I can write a bug report about gstreamer not working with Amarok here tough. deepdance:~> apt-show-versions | egrep "(phonon|amarok|xine|gstreamer)" amarok/experimental uptodate 2.1.1-1 amarok-common/experimental uptodate 2.1.1-1 amarok-dbg/experimental uptodate 2.1.1-1 amarok-utils/experimental uptodate 2.1.1-1 gstreamer0.10-alsa/squeeze uptodate 0.10.23-2 gstreamer0.10-ffmpeg/squeeze uptodate 0.10.7-1 gstreamer0.10-fluendo-mp3/lenny uptodate 0.10.7.debian-1 gstreamer0.10-plugins-bad/squeeze uptodate 0.10.12-1 gstreamer0.10-plugins-base/squeeze uptodate 0.10.23-2 gstreamer0.10-plugins-good/squeeze uptodate 0.10.15-2 gstreamer0.10-plugins-ugly/squeeze uptodate 0.10.11-1 gstreamer0.10-x/squeeze uptodate 0.10.23-2 libgstreamer-plugins-base0.10-0/squeeze uptodate 0.10.23-2 libgstreamer0.10-0/squeeze uptodate 0.10.23-1 libphonon4/sid uptodate 4:4.5.2-1 libxine1/squeeze uptodate 1.1.16.2-1+b1 libxine1-bin/squeeze uptodate 1.1.16.2-1+b1 libxine1-console/squeeze uptodate 1.1.16.2-1+b1 libxine1-ffmpeg/squeeze uptodate 1.1.16.2-1+b1 libxine1-misc-plugins/squeeze uptodate 1.1.16.2-1+b1 libxine1-plugins/squeeze uptodate 1.1.16.2-1 libxine1-x/squeeze uptodate 1.1.16.2-1+b1 libxinerama1/lenny uptodate 2:1.0.3-2 phonon/sid uptodate 4:4.5.2-1 phonon-backend-gstreamer/sid uptodate 4:4.3.1-2 phonon-backend-xine/sid uptodate 4:4.3.1-2 xine-ui/squeeze uptodate 0.99.5+cvs20070914-2.1
Do you think you can run amarok in callgrind, before hibernating and whatnot? Should give us an idea about what is spending CPU time. run: callgrind -v --dump-every-bb=10000000 amarokapp in an empty directory, and then kill it afterwards. Then if you could just tar up that directory and add it to the bug here.
Any Updates? Resuming very often and never had such problems.
Closing for lack of feedback. Feel free to reopen if you can reproduce this with the upcoming Amarok 2.2.1
Waited for Amarok 2.2.2 to try again. Still happening. Since some time even when Amarok is playing before going into suspend. Before it only happened when music playback was stopped or paused. Amarok uses up all CPU it can get, often also knotify4 uses up all CPU it can get, but sometimes only knotify4 uses up all CPU it can get. martin@deepdance:~> apt-show-versions | egrep "(kdelibs|libqt4-core|phonon|amarok|xine|gstreamer)" amarok/sid uptodate 2.2.2-1 amarok-common/sid uptodate 2.2.2-1 amarok-dbg/sid uptodate 2.2.2-1 amarok-utils/sid uptodate 2.2.2-1 gstreamer0.10-alsa/squeeze uptodate 0.10.25-7 gstreamer0.10-ffmpeg/squeeze uptodate 0.10.9-3 gstreamer0.10-fluendo-mp3/squeeze uptodate 0.10.7.debian-1 gstreamer0.10-plugins-bad/squeeze uptodate 0.10.17-1 gstreamer0.10-plugins-base/squeeze uptodate 0.10.25-7 gstreamer0.10-plugins-good/squeeze uptodate 0.10.17-1 gstreamer0.10-plugins-ugly/squeeze uptodate 0.10.13-2 gstreamer0.10-x/squeeze uptodate 0.10.25-7 kdelibs-bin/squeeze uptodate 4:4.3.4-1 kdelibs-data/squeeze upgradeable from 4:3.5.10.dfsg.1-2.1 to 4:3.5.10.dfsg.1-3 kdelibs4c2a/squeeze upgradeable from 4:3.5.10.dfsg.1-2.1 to 4:3.5.10.dfsg.1-3 kdelibs5/squeeze uptodate 4:4.3.4-1 kdelibs5-data/squeeze uptodate 4:4.3.4-1 libgstreamer-plugins-base0.10-0/squeeze uptodate 0.10.25-7 libgstreamer0.10-0/squeeze uptodate 0.10.25-4+b1 libphonon4/squeeze uptodate 4:4.5.3-4 libxine1/squeeze uptodate 1.1.17-1 libxine1-bin/squeeze uptodate 1.1.17-1 libxine1-console/squeeze uptodate 1.1.17-1 libxine1-ffmpeg/squeeze uptodate 1.1.17-1 libxine1-misc-plugins/squeeze uptodate 1.1.17-1 libxine1-plugins/squeeze uptodate 1.1.17-1 libxine1-x/squeeze uptodate 1.1.17-1 libxinerama1/squeeze uptodate 2:1.0.3-2 phonon/squeeze uptodate 4:4.5.3-4 phonon-backend-gstreamer/squeeze uptodate 4:4.3.1-5 phonon-backend-xine/squeeze uptodate 4:4.3.1-5 xine-ui/squeeze uptodate 0.99.5+cvs20070914-2.1 Current kernel is: martin@deepdance:~> cat /proc/version Linux version 2.6.32.3-tp23-toi-3.0.99.45 (martin@deepdance) (gcc version 4.3.4 (Debian 4.3.4-6) ) #4 PREEMPT Mon Jan 11 21:17:11 CET 2010 Martin Sandsmark, how much data would callgrind write? I am worrying about martin@deepdance:~> df -hT | egrep "(/$|/home)" /dev/sda5 xfs 9,4G 7,1G 2,3G 77% / /dev/sda8 xfs 28G 25G 2,8G 90% /home My ThinkPad T23 only has a 60GB harddisk. I am planing to migrate to Ext4 and then I likely will delete the OpenSUSE partition on it. Then I should have 12 GB free. Hmmm, I wouldn't need to wait till migration of Ext4 with deleting the OpenSUSE partition that has 9,4 GB space. Hmmm, lets see, maybe this weekend.
Are you using the Gstreamer or the Xine backend?
The Xine backend currently as AFAIK its the recommended one. And the gstreamer backend didn't work anyway (see previous comment #10 and comment #15). Up to now. So I switched to the gstreamer backend which appears to be working. Let's see whether that makes a difference. I do not seem to have the command callgrind available: shambhala:~> dpkg -S callgrind valgrind: /usr/bin/callgrind_control valgrind: /usr/bin/callgrind_annotate valgrind: /usr/share/man/man1/callgrind_control.1.gz valgrind: /usr/share/man/man1/callgrind_annotate.1.gz valgrind: /usr/include/valgrind/callgrind.h valgrind: /usr/lib/valgrind/callgrind-x86-linux shambhala:~> /usr/lib/valgrind/callgrind-x86-linux valgrind: You cannot run '/usr/lib/valgrind/callgrind-x86-linux' directly. valgrind: You should use $prefix/bin/valgrind. Well so I should use valgrind? It does not seem that I can attach valgrind to a running process. As the problem doesn´t happen always and it might not happen if I restart Amarok with valgrind before hibernating it seems it might make sense to run it with valgrind over a longer period of time in order to get anything. I wonder about the amount of data it saves out. Well for now I test with gstreamer and see whether that works better. At least gstreamer backend does work now which is an improvement in itself. ;)
I reassign this to Phonon, as it is not Amarok related anyway. Could be related to bug 171677
Okay, problem does not occur with gstreamer phonon backend. But since gstreamer backend has quite some other issues - like not recognizing that sound is available again after resume, stopping playback somewhere in between and not being able to pause playback - I switched back to Xine. But since then it worked okay - even with Xine I didn't have this issue anymore. I will try this setup for some more time. If its gone for good, this bug report can be closed. Another user of TuxOnIce, François Valenduc, has this problem too: http://lists.tuxonice.net/pipermail/tuxonice-users/2010-February/000181.html I will redirect him to this bug report to add any details he possibly encountered.
Is this still valid with KDE SC 4.4.2? It uses a newer Phonon version.
I just upgraded to KDE 4.4.2 from Debian Experimental this week on my Amarok machine. It still happens with phonon Xine backend and the following packages martin@deepdance:~> apt-show-versions | egrep "(kdelibs5/|libqt4-gui|phonon|amarok|libxine1/|gstreamer)" amarok/squeeze uptodate 2.3.0-1 amarok-common/squeeze uptodate 2.3.0-1 amarok-dbg/squeeze uptodate 2.3.0-1 amarok-utils/squeeze uptodate 2.3.0-1 gstreamer0.10-alsa/squeeze uptodate 0.10.28-1 gstreamer0.10-ffmpeg/squeeze uptodate 0.10.10-1 gstreamer0.10-fluendo-mp3/squeeze uptodate 0.10.12.debian-2 gstreamer0.10-plugins-bad/squeeze uptodate 0.10.17-1 gstreamer0.10-plugins-base/squeeze uptodate 0.10.28-1 gstreamer0.10-plugins-good/squeeze uptodate 0.10.21-1 gstreamer0.10-plugins-ugly/squeeze uptodate 0.10.14-1 gstreamer0.10-x/squeeze uptodate 0.10.28-1 kdelibs5/experimental uptodate 4:4.4.2-1 libgstreamer-plugins-base0.10-0/squeeze uptodate 0.10.28-1 libgstreamer0.10-0/squeeze uptodate 0.10.28-1 libphonon4/experimental uptodate 4:4.6.0really4.4.0-1 libqt4-gui/experimental uptodate 4:4.6.2-3 libxine1/squeeze uptodate 1.1.18.1-1+b1 phonon/experimental uptodate 4:4.6.0really4.4.0-1 phonon-backend-gstreamer/experimental uptodate 4:4.6.0really4.4.0-1 phonon-backend-xine/experimental uptodate 4:4.6.0really4.4.0-1 on my ThinkPad T23 with martin@deepdance:~> lsusb | grep Sonica Bus 001 Device 002: ID 0763:2007 Midiman M-Audio Sonica Theater on martin@deepdance:~> cat /proc/version Linux version 2.6.33.1-tp23-toi-3.1-04962-g60dd176 (martin@deepdance) (gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) ) #4 PREEMPT Thu Apr 1 10:35:20 CEST 2010 Using gstreamer backend was no alternative at the last attempt I tried, cause it had lots of other problems like skipping tracks. The endless cpu usage loop reliably happens when Amarok doesn't play anything, I hibernate via TuxOnIce - which driver-wise shouldn't make any difference to in-kernel or userspace hibernation - and resume. After resuming either just Amarok or Amarok and knotify4 use up all remaining CPU time. But it also happens from time to time just while playing. Usually I only recognize this when the ThinkPad fan is working more often than it normally does. So at times my ThinkPad is running at maximum CPU time for quite a while. After resuming I usually fire up a top to check the situation. I think I will switch to gstreamer once again, maybe it got better in the latest Phonon. But I think this bug should be fixed nonetheless. I can provide more information if I am told how to. That callgrind stuff didn't work out for me, see my comments above.
Hmmm, seems that gstreamer backend is working perfectly now. I am pleased. Still I believe Xine backend should be fixed. ;)
No, the gstreamer phonon backend didn't work as good as I hoped. Actually I do not remember the exact problems, but as far as I remember it sometimes started skipping one track after another, after resuming or on certain songs that worked with the xine engine. And there was another problem. Back to the Xine engine I still have that excessive CPU usage problem and I now think its not hibernation related. Cause today I started Amarok after resuming, cause I quitted it before hibernation as it again used up 100% CPU. So that Amarok session was not spanning a snapshot cycle. Still it started using 100% CPU again. This is really highly frustrating for me. I already think about a script that kills of Amarok if it uses to much CPU and restarts it automatically. Often I do not recognize immediately that the CPU ventilator for the Pentium 3 Mobile in my ThinkPad T23 is on almost all of the time. The thing happens often enough here that it would be quite easy to provide additional information. Still I do not know how. The valgrind related hints did not work out for me as I posted above. Actually I already thought on replacing Amarok with something else that doesn't use Phonon. For me as an user it does not matter whether its Amarok or Phonon. I just want Amarok using *reasonable* amounts of CPU time consistently. Still I prefer helping with getting this resolved, so if you have any hints, please share them with me. I also removed unloading of the USB audio module as the current kernel does not seem to require that hack anymore. The kernel I am using: martin@deepdance:~> cat /proc/version Linux version 2.6.33.1-tp23-toi-3.1-04962-g60dd176 (martin@deepdance) (gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) ) #4 PREEMPT Thu Apr 1 10:35:20 CEST 2010 (Except for TuxOnIce patch its a mainline kernel.) I am currently using: martin@deepdance:~> apt-show-versions | egrep "(kdelibs5/|libqt4-gui|phonon|amarok|libxine1/|gstreamer)" amarok/squeeze uptodate 2.3.0-2 amarok-common/squeeze uptodate 2.3.0-2 amarok-dbg/squeeze uptodate 2.3.0-2 amarok-utils/squeeze uptodate 2.3.0-2 gstreamer0.10-alsa/squeeze uptodate 0.10.29-1 gstreamer0.10-ffmpeg/squeeze uptodate 0.10.10-1 gstreamer0.10-fluendo-mp3/squeeze uptodate 0.10.12.debian-2 gstreamer0.10-plugins-bad/squeeze uptodate 0.10.18-2+b1 gstreamer0.10-plugins-base/squeeze uptodate 0.10.29-1 gstreamer0.10-plugins-good/squeeze uptodate 0.10.22-1 gstreamer0.10-plugins-ugly/squeeze uptodate 0.10.14-1 gstreamer0.10-x/squeeze uptodate 0.10.29-1 kdelibs5/squeeze uptodate 4:4.4.3-2 libgstreamer-plugins-base0.10-0/squeeze uptodate 0.10.29-1 libgstreamer0.10-0/squeeze uptodate 0.10.29-1 libphonon4/squeeze uptodate 4:4.6.0really4.4.1-2 libqt4-gui/squeeze uptodate 4:4.6.2-4 libsmokephonon3/squeeze uptodate 4:4.4.3-2 libxine1/squeeze uptodate 1.1.18.1-1+b2 phonon/squeeze uptodate 4:4.6.0really4.4.1-2 phonon-backend-gstreamer/squeeze uptodate 4:4.6.0really4.4.1-2 phonon-backend-xine/squeeze uptodate 4:4.6.0really4.4.1-2
The xine backend will be deprecated soon as it is currently unmaintained. Please use vlc or gstreamer instead.