On Wednesday 03 January 2007 15:17, Nelson, David (ED, PAR&D) wrote: > I moved to amarok, I might give audacious a shot. > > What about noatun for a smallish player? Not sure on it's RAM usage. > Also look at Quod Libet or Banshee which are meant to be similar in > features to amarok but lighter in terms of resource usage (or so I > hear). > > David
David, this reply isn't directed at you. You just happen to be the most recent post and a convenient reply point. Throughout this thread many people have commented on audacious being a resource hog of monumental proportions. Every single one of them is wrong and this myth really needs to be debunked. Here's why: Look at the libs it links against: nazgul ~ # ldd `which audacious` linux-gate.so.1 => (0xffffe000) libaudacious.so.4 => /usr/lib/libaudacious.so.4 (0x440bf000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x43c9d000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x4401d000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x47ad0000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x47a3e000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x4409c000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7ed8000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x480d5000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x47b29000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x47a00000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x47a39000) libdl.so.2 => /lib/libdl.so.2 (0x4f44f000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x47970000) libglade-2.0.so.0 => /usr/lib/libglade-2.0.so.0 (0x440a6000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4b9db000) libz.so.1 => /lib/libz.so.1 (0x4f560000) libm.so.6 => /lib/tls/libm.so.6 (0x4f429000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6 (0x4f583000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1 (0x4f6ef000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4f455000) libc.so.6 => /lib/tls/libc.so.6 (0x4f306000) libX11.so.6 => /usr/lib/libX11.so.6 (0x4b8be000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4baee000) libXext.so.6 => /usr/lib/libXext.so.6 (0x4b9aa000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x4bb19000) libXi.so.6 => /usr/lib/libXi.so.6 (0x4bb3a000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x4bb35000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x4bb23000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x4bb2e000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x47aeb000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4f682000) libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb7e61000) libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb7e5a000) libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb7e4c000) libglitz.so.1 => /usr/lib/libglitz.so.1 (0x48191000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7e29000) librt.so.1 => /lib/tls/librt.so.1 (0x4f8a8000) /lib/ld-linux.so.2 (0x4f2e8000) libXau.so.6 => /usr/lib/libXau.so.6 (0x4b9a5000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x4f559000) It's those libs that are using the memory, not audacious. Those are shared libs, meaning many other apps on the system use them and the total memory they consume is used by all apps that use the libs. And, every one of those libs (apart from libaudacious) can reasonably be expected to be in use already on any desktop machine running X Here's 'free' before and after I started audacious in another session: nazgul ~ # free total used free shared buffers cached Mem: 2076984 1844696 232288 0 246056 1220848 -/+ buffers/cache: 377792 1699192 Swap: 0 0 0 nazgul ~ # free total used free shared buffers cached Mem: 2076984 1851528 225456 0 246060 1222324 -/+ buffers/cache: 383144 1693840 Swap: 0 0 0 So starting audacious consumed an extra 6M of memory - that's nowhere near the 240M other posters are incorrectly stating it uses. Top shows me this for audacious while playing a song: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9077 alan 15 0 62112 16m 11m R 0.3 0.8 0:01.00 audacious It's using 62M of VIRTUAL memory, shared with every other app that uses the same libs. It uses 16M of resident memory (i.e. stuff in RAM), which is the 6M it used at start up, plus 10M for the song that's playing. It's a 5.5M mp3 which needs to be decompressed so any music player will use that much. Finally audacious is using 11M of shared memory, probably via /dev/shm - but that is backed by swap anyway and can be swapped out easily. So, anyone that says audacious is a resource hog is plain flat out wrong and does not know how the Linux virtual memory system works. It is complex and almost impossible to know what is going on at any instant in time, but that's no excuse for people being wrong by a factor of 500% alan -- gentoo-user@gentoo.org mailing list