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
--
[email protected] mailing list
