| 1 |
On Wednesday 03 January 2007 15:17, Nelson, David (ED, PAR&D) wrote: |
| 2 |
|
| 3 |
> I moved to amarok, I might give audacious a shot. |
| 4 |
> |
| 5 |
> What about noatun for a smallish player? Not sure on it's RAM usage. |
| 6 |
> Also look at Quod Libet or Banshee which are meant to be similar in |
| 7 |
> features to amarok but lighter in terms of resource usage (or so I |
| 8 |
> hear). |
| 9 |
> |
| 10 |
> David |
| 11 |
|
| 12 |
David, this reply isn't directed at you. You just happen to be the most |
| 13 |
recent post and a convenient reply point. |
| 14 |
|
| 15 |
Throughout this thread many people have commented on audacious being a |
| 16 |
resource hog of monumental proportions. Every single one of them is |
| 17 |
wrong and this myth really needs to be debunked. Here's why: |
| 18 |
|
| 19 |
Look at the libs it links against: |
| 20 |
nazgul ~ # ldd `which audacious` |
| 21 |
linux-gate.so.1 => (0xffffe000) |
| 22 |
libaudacious.so.4 => /usr/lib/libaudacious.so.4 (0x440bf000) |
| 23 |
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x43c9d000) |
| 24 |
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x4401d000) |
| 25 |
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x47ad0000) |
| 26 |
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 |
| 27 |
(0x47a3e000) |
| 28 |
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 |
| 29 |
(0x4409c000) |
| 30 |
libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7ed8000) |
| 31 |
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x480d5000) |
| 32 |
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x47b29000) |
| 33 |
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x47a00000) |
| 34 |
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x47a39000) |
| 35 |
libdl.so.2 => /lib/libdl.so.2 (0x4f44f000) |
| 36 |
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x47970000) |
| 37 |
libglade-2.0.so.0 => /usr/lib/libglade-2.0.so.0 (0x440a6000) |
| 38 |
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4b9db000) |
| 39 |
libz.so.1 => /lib/libz.so.1 (0x4f560000) |
| 40 |
libm.so.6 => /lib/tls/libm.so.6 (0x4f429000) |
| 41 |
libstdc++.so.6 |
| 42 |
=> /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6 (0x4f583000) |
| 43 |
libgcc_s.so.1 |
| 44 |
=> /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1 (0x4f6ef000) |
| 45 |
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4f455000) |
| 46 |
libc.so.6 => /lib/tls/libc.so.6 (0x4f306000) |
| 47 |
libX11.so.6 => /usr/lib/libX11.so.6 (0x4b8be000) |
| 48 |
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4baee000) |
| 49 |
libXext.so.6 => /usr/lib/libXext.so.6 (0x4b9aa000) |
| 50 |
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x4bb19000) |
| 51 |
libXi.so.6 => /usr/lib/libXi.so.6 (0x4bb3a000) |
| 52 |
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x4bb35000) |
| 53 |
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x4bb23000) |
| 54 |
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x4bb2e000) |
| 55 |
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 |
| 56 |
(0x47aeb000) |
| 57 |
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4f682000) |
| 58 |
libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 |
| 59 |
(0xb7e61000) |
| 60 |
libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb7e5a000) |
| 61 |
libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb7e4c000) |
| 62 |
libglitz.so.1 => /usr/lib/libglitz.so.1 (0x48191000) |
| 63 |
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7e29000) |
| 64 |
librt.so.1 => /lib/tls/librt.so.1 (0x4f8a8000) |
| 65 |
/lib/ld-linux.so.2 (0x4f2e8000) |
| 66 |
libXau.so.6 => /usr/lib/libXau.so.6 (0x4b9a5000) |
| 67 |
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x4f559000) |
| 68 |
|
| 69 |
It's those libs that are using the memory, not audacious. Those are |
| 70 |
shared libs, meaning many other apps on the system use them and the |
| 71 |
total memory they consume is used by all apps that use the libs. And, |
| 72 |
every one of those libs (apart from libaudacious) can reasonably be |
| 73 |
expected to be in use already on any desktop machine running X |
| 74 |
|
| 75 |
Here's 'free' before and after I started audacious in another session: |
| 76 |
|
| 77 |
nazgul ~ # free |
| 78 |
total used free shared buffers |
| 79 |
cached |
| 80 |
Mem: 2076984 1844696 232288 0 246056 |
| 81 |
1220848 |
| 82 |
-/+ buffers/cache: 377792 1699192 |
| 83 |
Swap: 0 0 0 |
| 84 |
nazgul ~ # free |
| 85 |
total used free shared buffers |
| 86 |
cached |
| 87 |
Mem: 2076984 1851528 225456 0 246060 |
| 88 |
1222324 |
| 89 |
-/+ buffers/cache: 383144 1693840 |
| 90 |
Swap: 0 0 0 |
| 91 |
|
| 92 |
So starting audacious consumed an extra 6M of memory - that's nowhere |
| 93 |
near the 240M other posters are incorrectly stating it uses. |
| 94 |
|
| 95 |
Top shows me this for audacious while playing a song: |
| 96 |
|
| 97 |
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND |
| 98 |
9077 alan 15 0 62112 16m 11m R 0.3 0.8 0:01.00 audacious |
| 99 |
|
| 100 |
It's using 62M of VIRTUAL memory, shared with every other app that uses |
| 101 |
the same libs. |
| 102 |
It uses 16M of resident memory (i.e. stuff in RAM), which is the 6M it |
| 103 |
used at start up, plus 10M for the song that's playing. It's a 5.5M mp3 |
| 104 |
which needs to be decompressed so any music player will use that much. |
| 105 |
Finally audacious is using 11M of shared memory, probably via /dev/shm - |
| 106 |
but that is backed by swap anyway and can be swapped out easily. |
| 107 |
|
| 108 |
So, anyone that says audacious is a resource hog is plain flat out wrong |
| 109 |
and does not know how the Linux virtual memory system works. It is |
| 110 |
complex and almost impossible to know what is going on at any instant |
| 111 |
in time, but that's no excuse for people being wrong by a factor of |
| 112 |
500% |
| 113 |
|
| 114 |
alan |
| 115 |
-- |
| 116 |
gentoo-user@g.o mailing list |
Archives