|
Rockbox mail archiveSubject: Re: Suggested mpeg playing APIRe: 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 |