diff options
-rw-r--r-- | firmware/test/wavey/README.playlists | 84 |
1 files changed, 84 insertions, 0 deletions
diff --git a/firmware/test/wavey/README.playlists b/firmware/test/wavey/README.playlists new file mode 100644 index 0000000000..fa28fd47a0 --- /dev/null +++ b/firmware/test/wavey/README.playlists | |||
@@ -0,0 +1,84 @@ | |||
1 | |||
2 | Playlists on the Rockbox | ||
3 | |||
4 | 1. Demand-loading of Playlist Filenames from Disk | ||
5 | |||
6 | A playlist is simply a list of track names. These lists can either be | ||
7 | created dynamically by the user, or they can be predefined and placed | ||
8 | into a text file with an .m3u extension. | ||
9 | |||
10 | The 2048 KB of RAM is the reason we need to get this right. If an average | ||
11 | track name (i.e. \music\cure\disintegration\01-pictures_of_you.mp3) | ||
12 | is assumed to be 50 characters long, then: | ||
13 | |||
14 | A playlist of 15 tracks is 15 * 50 ~= 750 bytes | ||
15 | A playlist of 100 tracks is 100 * 50 ~= 5 kilobytes | ||
16 | A playlist of 3500 tracks is 3500 * 50 ~= 175 kilobytes | ||
17 | A playlist of 10000 tracks is 10000 * 50 ~= 1/4 megabyte | ||
18 | |||
19 | From these figures, it can be seen that for large playlists, storing | ||
20 | the entire list of track names in memory significantly reduces the | ||
21 | capacity available to the audio data buffer, which in turn has a negative | ||
22 | impact on the performance of the system. | ||
23 | |||
24 | One method of reducing the total memory consumption of a playlist is | ||
25 | to delay bringing the actual filenames into memory until needed. Instead, | ||
26 | the playlist text file can be scanned, and an in-memory array constructed | ||
27 | with one element for each track present in the text file. Progressing | ||
28 | through the playlist entails getting the appropriate entry from the array, | ||
29 | and using that to perform a lookup of the corresponding filename entry | ||
30 | from the playlist text file. | ||
31 | |||
32 | With this method, and given that an integer on the Rockbox's CPU is 4 bytes: | ||
33 | |||
34 | A playlist of 15 tracks is 15 * 4 ~= 60 bytes | ||
35 | A playlist of 100 tracks is 100 * 4 ~= 400 bytes | ||
36 | A playlist of 3500 tracks is 3500 * 4 ~= 13 kilobytes | ||
37 | A playlist of 10000 tracks is 10000 * 4 ~= 39 kilobytes | ||
38 | |||
39 | It is clear that these are substantial savings, albeit at the cost of | ||
40 | increased complexity and disk i/o. Prefetch strategies could improve | ||
41 | performance compared to demand-loading a single entry. | ||
42 | |||
43 | 2. Implementation Options | ||
44 | |||
45 | Keeping the track names in a file on disk is easy enough for a predefined | ||
46 | m3u playlist, but for dynamically created playlists, where the user | ||
47 | browses the filesystem and adds tracks or entire directory hierarchies | ||
48 | at will, we will need to store the playlist track names in a dedicated | ||
49 | file. This will be called the Anonymous Playlist, the location of which | ||
50 | can be set by the user, but will default to \anonymous.m3u or somesuch. | ||
51 | The current contents of the Anonymous Playlist can be named and saved at | ||
52 | any time. | ||
53 | |||
54 | The data structure to support playlists would therefore be: | ||
55 | |||
56 | typedef struct | ||
57 | { | ||
58 | char filename[256] ; /* path name of m3u playlist on disk */ | ||
59 | int *indices; /* array of indices into the playlist */ | ||
60 | int index; /* index of current track within playlist */ | ||
61 | } playlist_info_t; | ||
62 | |||
63 | So far, so good: we read from an existing m3u file, or we create an | ||
64 | anonymous one. But what do we do if we start with an existing m3u file, | ||
65 | and then the user wants to dynamically add tracks to it? A few options | ||
66 | exist: | ||
67 | |||
68 | a) we disallow playlist modification of existing m3u files, offering | ||
69 | instead to replace the current playlist with the new one. | ||
70 | |||
71 | b) we give the user the option of appending the new tracks to the | ||
72 | existing m3u file. | ||
73 | |||
74 | c) we copy the contents of the existing m3u playlist to the anonymous one, | ||
75 | and then append the new tracks to that. If the m3u playlist is large, | ||
76 | this could be wasteful and potentially time-consuming. However, choosing | ||
77 | this option would provide the facility to insert or append entire | ||
78 | existing m3u playlists 'into' one another, a feature missng from the | ||
79 | commercial firmware. | ||
80 | |||
81 | |||
82 | |||
83 | |||
84 | |||