|
Rockbox mail archiveSubject: MPEG playing API - version 0.1MPEG playing API - version 0.1
From: Dave Chapman <dave_at_dchapman.com>
Date: Mon, 13 May 2002 10:03:39 +0100 After some discussions on IRC, here is an amended "MPEG API". Dave. MPEG playing API - version 0.1 ------------------------------ Methodology ----------- I think the most important thing is to abstract the method of choosing tracks away from the actual playing of them. This will allow the implementation of different play modes without affecting the mpeg playing code. The actual mpeg playing will take back in the background, but the implementation of this is not affected by the API. Functions called by the "mpeg thread" ------------------------------------- char* peek_next_track(int n) Return filename of track, where n is the track number - 0=current track, 1=next track, etc. Return NULL if there is no track with that number. Purpose: When the mpeg thread has finished reading (i.e. copying from disk to memory, NOT playing) the current track, it needs to be able to start buffering the next track (in order to prevent skips between tracks). Therefore, there needs to be a function: char* next_track(void) This is called when the mpeg thread has finished playing track 0. Functions provided by the mpeg thread ------------------------------------- pause_playback(void) - temporarily pause the playback The following functions should only be called when the playback is paused: resume_playback(void) - resume playback after a pause change_track(char* fname, int start_time) - start playing a completely new track seek_absolute(int n) - seek to an absolute position (in milliseconds) seek_relative(int n) - seek to a relative position (in milliseconds) in the current track None of these functions should fail. They should also block the UI thread until they have finished. Comments -------- All other possible functions are simply combinations of the above. e.g. "skip to previous track" is simply a call to "new_track". If skipping by N seconds takes the user to a different track, the UI thread must either refuse to skip, or call the new_track command with the appropriate offset. Maybe the above functions can be implemented by having a simple type of message queue that the mpeg thread polls at appropriate intervals. The implementation of the above functions in the ui thread would just modify a shared data structure (with proper locking). The mpeg thread would poll this data structure to see if it contained a message and act accordingly. There will also be a need for the User Interface thread to update the display with the status of the current track (track details, time elapsed, time left etc). Therefore, the mpeg thread should maintain a shared data structure that contains the current status (i.e. current position in seconds) of the current track I have tried to make this as simple as possible, yet also keeping it as flexible and abstract as possible. It also puts most of the work (e.g. reading and manipulating playlists) in the UI thread - where I think it belongs Received on 2002-05-13 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |