From: Matthew P. OReilly <moreilly_at_moreilly.com>
Date: Sun, 16 Mar 2003 10:06:21 -0500

Ok, that makes sense, but I can't help but question the underlying
assumption that we have to have an array for all entries which is loaded at
playlist start.

Since the disk must be read each time a mp3 begins anyway, why not take a
little extra time to read portions of the playlist as necessary? In my way
of thinking, it would be perfectly reasonable to only load, say, 20 entries
from the playlist into the array at any given time, making sure that the
currently playing song is between entries 5 and 15 and loading more playlist
info when it is not. This satisfies the Forward and Back requirements for
at least 5 songs, greatly reduces the amount of memory which must be
allocated for the array, and (AFAICT) still allows the resume function to
work.

The only thing we would have to have extra would be the information about
the name of the master playlist(s) and the respective entry number in each
one so Rockbox would know where to return when a playlist finished.

Forgive my ignorance; there may be a very good reason to load the entire
playlist into memory at once. But I figured I'd ask just in case.

Thanks!
Matt

-----Original Message-----
From: owner-rockbox_at_cool.haxx.se [mailto:owner-rockbox_at_cool.haxx.se]On
Behalf Of Daniel Stenberg
Sent: Sunday, March 16, 2003 7:16 AM
To: Rockbox
Subject: RE: playlists: directories randomly, linear within directories


On Sun, 16 Mar 2003, Matthew P. OReilly wrote:

> Perhaps I missed this before, non-coder that I am <grin>, but is there a
> technical reason why it would be difficult/impossible to have recursive
> playlists? AFAICT, we have (or are working on) all the necessary
> functionality to do this sort of thing - .cfg files loaded with playlists
> (to switch between shuffle and non-shuffle mode), playlists loading other
> playlists (am I correct in that assumption?), etc. All I can see we need
> is the ability to store the information about the parent playlist somehow,
> which could be something of a logistical nightmare (unless you set the
> maximum nesting to 3 levels or something) but not terribly difficult.
>
> Am I missing something here? What portions of this are not possible
> currently?

This is all terribly technical, but allow me to attempt to explain why this
is tricky:

Today, when a playlist is loaded into memory, it is just scanned through and
we store the index of the file name in the actual file on disk. Thus, a 1000
song playlist becomes 1000 indexes in memory. When a song is to be played
from the list, we know the original playlist file and we seek our way (to
the
index we know) to figure out the name of the song to play.

In come recursive playlists. They don't fit this scheme at all. Let's assume
that one of the songs in the playlist is a playlist (a sublist), then we
must
scan that playlist instead and make indexes for that and somehow store and
remember internally that these index entries are for a different playlist.

One way we could approach this:

Assuming that a file path name is 256 bytes maximum, we can safely assume
that no playlist (thus seek index) is ever bigger than 2560000 for a
10000-entry playlist. And to play it safe for 8MB-modders, let's assume we
want to support 40000 entries, no seek index is ever bigger than 10240000.
To
hold such a number 24 bits is enough.

This gives us 8 free bits on every array entry that will never be used for
seek-info, but can instead be used for playlist info. Given that these won't
be needed for anything else, we could use these as a 'playlist identifier'
and for each new 'recursive' playlist, we store the name of that playlist in
an array (which then would require a whopping 64K if 256 entries could each
have their own unique 256-bytes file path).

Let's say we can spare 4K for the recursive playlist path info, then we'd
support at least 16 playlists. And that would only use 4 bits in the array.

Of course, loading of a playlist like this will be slower, and the sub-lists
will be loaded and examined at the time of the master list load.

A few benefits of this approach:

* The resume algorithm would still work perfectly
* BACK and FORWARD would still work as today

A few drawbacks:

* Having a directory name in the playlist and use that as a sub-list will
  not be easily done.
* The limit of 16 sub-lists will be odd and hard for people to understand
  and deal with.
* Makes the playlistg code more complicated, when this "inline" stuff
perhaps
  just as well could be made by an external program that generates one
single
  playlist instead...

I've probably forgot lots of tiny details.

--
 Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/

Received on 2003-03-16