From: CombThins <bmnews_at_blueyonder.co.uk>
Date: Wed, 6 Aug 2003 22:16:00 +0100

"Daniel Stenberg" wrote:
>
> I guess you would need to seek to get the playlist name first, then seek
in
> that playlist to get the actual mp3 name...
>
> It'll make finding the next song slightly slower, but I guess it would
work.
>

Yes that's exactly it. The various entries in the in-memory playlist form a
tree with the Music file enties at the leaves, and the one "root" playlist
whose name we keep permanently in memory in the playlist structure (as at
present). It's built to be easy to navigate from the leaves up (I imagine
my trees upside-down), so we can use a recursive function to start at a
music file entry, and look back up the tree. While we unwind the recursion,
at each stage we have a playlist name to open at each level and a seek
index, so we can open a playlist and lookup the name the next playlist in
the chain. When we've fully unwound the recursion we've got the music file
name. The cost is an additional file open and seek for each level of
playlist nesting.

For a simple flat playlist there is negligible additional overhead when
playing (just AND with a mask, and check for zero). I think the additional
overhead on loading will also be negligible for a flat playlist, since the
loading routine scans looking for the end of each line - it just has to also
check to see if the line ends in .M3U, in which case the nesting part of the
code kicks in.

I think I will soon try a quick experiment moding the playlist code to do
some additional dummy file open and seek operations, just to get a feel for
whether they are likely to affect track loading time much.

Since recursion is the obvious way to do both loading and playing from this
playlist, I suspect that the real limitation on the nesting depth that is
practical might be the stack size when playing. We obviously don't want to
increase any stack sizes if it can be avoided. I think we don't need too
big a stack frame in the "playing" recursion, because we only need one
additional filename in memory at a time, so it needn't be on the stack.
It's during loading that we will need to keep a MAX_PATH sized string at
each level of recursion. However, at initial playlist load time we've got
the whole mpeg buffer, as used for present playlist load, so we can probably
put stuff there instead of in the stack frame. Dynamically loading
playlists might be more challenging :-)

Anyway, I'm not imagining that people will need really deep playlist nesting
- four or five deep will probably be quite adequate.

Does anyone have any information on how much of the stack is currently used,
or any advice as to how to find out? (FYI, I've got player only, and as it
is new I would rather not go down the serial port hardware mod route right
now). I will need to look at the code a bit more to see how the threads and
stacks work. At the moment I don't even know whether loading playlists and
playing them are on the same stack - I presume not, but I haven't looked
into it at all.

Cheers,

Barry
Received on 2003-08-06