|
Rockbox mail archiveSubject: Re: Nested playlists anyone?Re: Nested playlists anyone?
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 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |