Playlists on the Rockbox

1. Demand-loading of Playlist Filenames from Disk

A playlist is simply a list of track names. These lists can either be 
created dynamically by the user, or they can be predefined and placed
into a text file with an .m3u extension.

The 2048 KB of RAM is the reason we need to get this right. If an average
track name (i.e. \music\cure\disintegration\01-pictures_of_you.mp3) 
is assumed to be 50 characters long, then:

A playlist of    15 tracks is    15 * 50 ~= 750 bytes
A playlist of   100 tracks is   100 * 50 ~=   5 kilobytes
A playlist of  3500 tracks is  3500 * 50 ~= 175 kilobytes
A playlist of 10000 tracks is 10000 * 50 ~= 1/4 megabyte

From these figures, it can be seen that for large playlists, storing 
the entire list of track names in memory significantly reduces the 
capacity available to the audio data buffer, which in turn has a negative
impact on the performance of the system.

One method of reducing the total memory consumption of a playlist is 
to delay bringing the actual filenames into memory until needed. Instead,
the playlist text file can be scanned, and an in-memory array constructed 
with one element for each track present in the text file. Progressing 
through the playlist entails getting the appropriate entry from the array,
and using that to perform a lookup of the corresponding filename entry 
from the playlist text file.

With this method, and given that an integer on the Rockbox's CPU is 4 bytes:

A playlist of    15 tracks is    15 * 4 ~=  60 bytes
A playlist of   100 tracks is   100 * 4 ~= 400 bytes
A playlist of  3500 tracks is  3500 * 4 ~=  13 kilobytes
A playlist of 10000 tracks is 10000 * 4 ~=  39 kilobytes

It is clear that these are substantial savings, albeit at the cost of 
increased complexity and disk i/o. Prefetch strategies could improve 
performance compared to demand-loading a single entry.

2. Implementation Options

Keeping the track names in a file on disk is easy enough for a predefined
m3u playlist, but for dynamically created playlists, where the user 
browses the filesystem and adds tracks or entire directory hierarchies
at will, we will need to store the playlist track names in a dedicated
file. This will be called the Anonymous Playlist, the location of which
can be set by the user, but will default to \anonymous.m3u or somesuch. 
The current contents of the Anonymous Playlist can be named and saved at
any time. 

The data structure to support playlists would therefore be:

typedef struct 
{
    char filename[256] ; /* path name of m3u playlist on disk       */
    int *indices;        /* array of indices into the playlist      */
    int  index;          /* index of current track within playlist  */
} playlist_info_t;

So far, so good: we read from an existing m3u file, or we create an 
anonymous one. But what do we do if we start with an existing m3u file, 
and then the user wants to dynamically add tracks to it? A few options 
exist:

a) we disallow playlist modification of existing m3u files, offering
   instead to replace the current playlist with the new one.

b) we give the user the option of appending the new tracks to the 
   existing m3u file. 

c) we copy the contents of the existing m3u playlist to the anonymous one, 
   and then append the new tracks to that. If the m3u playlist is large,
   this could be wasteful and potentially time-consuming. However, choosing
   this option would provide the facility to insert or append entire 
   existing m3u playlists 'into' one another, a feature missng from the 
   commercial firmware.