diff options
author | Daniel Stenberg <daniel@haxx.se> | 2004-01-08 15:46:17 +0000 |
---|---|---|
committer | Daniel Stenberg <daniel@haxx.se> | 2004-01-08 15:46:17 +0000 |
commit | 8463a2bbd3f64ad47f5d30ca9a1957c170f48ec1 (patch) | |
tree | 6ead4078a20990b62179a28eb4003d792bf93535 /firmware/test/wavey/README.playlists | |
parent | 5c7d66890c5ba05402c85d47dd87f6abfd4df7d9 (diff) | |
download | rockbox-8463a2bbd3f64ad47f5d30ca9a1957c170f48ec1.tar.gz rockbox-8463a2bbd3f64ad47f5d30ca9a1957c170f48ec1.zip |
ancient experimental test code not used for 2+ years, removed
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@4212 a1c6a512-1295-4272-9138-f99709370657
Diffstat (limited to 'firmware/test/wavey/README.playlists')
-rw-r--r-- | firmware/test/wavey/README.playlists | 84 |
1 files changed, 0 insertions, 84 deletions
diff --git a/firmware/test/wavey/README.playlists b/firmware/test/wavey/README.playlists deleted file mode 100644 index fa28fd47a0..0000000000 --- a/firmware/test/wavey/README.playlists +++ /dev/null | |||
@@ -1,84 +0,0 @@ | |||
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 | |||