xfmedia 0.3.0 released

[Brian J. Tarricone]

groundhog3000 wrote:

> Here is the issue,
>
>> the gui part:
>> olivleh1 at kartoffel olivleh1> ps auxww | grep mpla
>> olivleh1 36123 18.3  1.8 20928 11648  p1  S+    4:55PM   0:00.97 
>> gmplayer
>> (mplayer)
>>
>>
>> the video part:
>> olivleh1 36128  1.8  3.1 29224 20212  p1  S+    4:55PM   0:00.17 
>> gmplayer
>> (mplayer)
>>
>> but i'm playing an mpg with xfmedia.
>> Playing an mp3 to compare teapots with teapots:
>>
>> audio part:
>> olivleh1 36136  0.0  2.3 29256 15084  p1  S+    4:57PM   0:00.08 
>> gmplayer
>> (mplayer)
>>
>> Makes 26 MB (gui+audio)
>>
>> And I don't see how the "fully capable" feature should result in a 
>> bigger
>> memory usage. If I don't play an divx or whatever, just an mp3, then
>> nothing has to be in my memory except mp3+gui.
>>
> Beep-Media-Player uses almost no system resources at all.
> Mplayer uses a bit more, but not much.
> It _appears_ as if xfmedia loads all the xine libs before they are 
> needed,
> which leads to a large memory footprint.  Could be a modularization 
> problem ...
> but since I haven't seen the code, I don't know.

um... and what would you suggest it do?  not load them at all?  libxine 
has one initialisation interface, and it's all-or-nothing.  note that 
you're reading values from 'top', which can be misleading.  for example, 
right now i have this:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
24793 brian     15   0  162m 6532  20m S  0.0  2.6   0:15.33 xfmedia

the important number is the RES value (and the SHR value), as that's the 
RAM that is actually active.  the reason VIRT is so large is because, as 
you state, xine loads all of it's various 
input/output/demux/decoder/post plugin libraries on startup.  but only a 
very small number of them are acutally in-RAM at any time (in xfmedia's 
case, four, or five if you're using an audio vis).  note that i also 
have a playlist with 4817 items in it.  each entry involves Gtk widget 
structures for rows in the playlist, as well as the strings that make up 
the title, #, and length field.  it may not seem like much per entry, 
but it all adds up.

in a sense, i can understand why some of you so strongly disagree with 
my use of the term "lightweight", and i may decide that i agree with you 
enough to stop using it, or better describe it as a "lightweight UI" or 
somesuch.  the fact of the matter is, i'm offering a fully-functional 
solution that you can (when it's more mature) use to replace both 
xmms/bmp and xine/mplayer if you so desire.  if you're going to make a 
comparison based on that, load up gmplayer and xmms/bmp at the same 
time, and add up the memory usage of both.

i'll work to reduce memory usage where possible, but there's only so 
much i can do.  i want to get it working, usable, and feature-complete 
first.  doing heavy optimising at this point would be foolish and a 
waste of time, and anyone who believes otherwise has no clue about 
software development.

xine _is_ a bit heavy on memory at times.  i chose it because, frankly, 
i think it's the best desktop-neutral media framework we have out there 
(feel free to disagree with me, but i don't feel like getting into an 
argument about this, so don't bother starting one).  gstreamer has a 
nice architecture, but it's somewhat unwieldy in its current state.  my 
past attempts to juse _use_ it have been met with failure.  just as 
importantly, i'm not familiar with it, and i've been using xine and 
following their -dev mailing list for a long time now.  mplayer's 
architecture makes it completely unsuitable for use in another project 
(to say nothing of philosophical and personal differences i have with 
the mplayer devs that make me just flat-out not want to use it).  are 
there other frameworks out there?  maybe, but i didn't take the time to 
find them.  i had an itch, and i _wanted_ to use xine, and so xfmedia 
was born.  if you don't like it, don't use it.  no skin off my back.

sorry for the rant, i'll go back to hacking now...

    -brian