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



Rockbox mail archive

Subject: Re: Suggested mpeg playing API

Re: Suggested mpeg playing API

From: Philipp Pertermann <Philipp.Pertermann_at_web.de>
Date: Mon, 13 May 2002 13:43:19 +0200

Dave Chapman wrote:

> int start_playback(char* fname, int start_time)
>
> which creates the mpeg thread and starts playing the named file at the
> specified start position (in milliseconds)


I don't think it's a good idea to introduce time here. That means that
all of a sudden we have to analyze mp3 files, find layer III frames and
information about data rates. How else can we determine which part of
the file shall be played. Considering VBR encoded material time
information would become either rough guessing anyway or (even worse)
unbearable expensive as we strictly speaking had to analyze _all_ the
file. And finally we don't really need time information here. The system
doesn't need time info for playback but a file position, it's a mere
user information. In the end we'll have to calculate a file position
from the time information anyway. I think time <-> fileposition
conversion should be a job for the ui.

Maybe we can even use the MAS for that job. Browsing the datasheet of
the MAS 3587F (JBR) diagonally I saw something that looked like it was
possible to obtain all the mp3 frame header info and more (framecounter)
from the MAS. So maybe we can delegate the analysis of mp3 frames to the
MAS. But to be honest: I don't have much hope because we're not only
interested in the info of the frame that currently is being played.


> resume_playback(void) - resume playback after a pause
> kill_playback(void) - kill the mpeg playing thread
> new_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.


What do you mean by 'fail'? For example the method new_track inherently
can fail. How will it behave if some moron calls it with a start_time
that is after the end of the file? Well, we could punish the moron by
making his jukebox write "I must not call methods with invalid
arguments!\n" until the hd is full... ;)

> They should also block the UI thread
> until they have finished - I think this will simplify the overall
> implementation without any noticable delay to the user.


That could only be achieved if we had simple means to do a time <-> file
position conversion. But as mentioned that can become incredibly
complicated / expensive.

 
> 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.


Sounds like a good idea to me.


> 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


For this kind of information we probably don't need our own shared data
structure since the MAS offers these infos straight away.

> 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.
>
> Any comments?

Yes: Very good discussion basis! Thank you!

But I'd like to introduce another topic: acustical UI. Imagine we want
the thing to beep when a button is pressed. I don't talk about mixing
the beep and music here - that's far byond the capabilities of the JB.
But we probably could establish a mechanism that inserts a single mp3
frame into the stream being played. This beepFrame could be hardcoded. I
don't know enough about mp3 yet but somehow I assume that it is possible
to change the pitch of the beepFrame by changing one single parameter.
Unfortunately inserting a frame into the currend stream means analyzing
the mp3 stream. But here we only have to detect a frame sync which is
fairly easy since that doesn't mean anything else but waiting for "1111
1111 1111" to occur. Maybe the MAS can help here -> investigation needed.

Phil
Received on 2002-05-13

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy