Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: MPEG playing API - version 0.1
From: Dave Chapman (dave_at_dchapman.com)
Date: 2002-05-13


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



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa