Rockbox mail archiveSubject: RE: Suggested mpeg playing API
RE: Suggested mpeg playing API
From: Nielsen Linus (ext) <"Nielsen>
Date: Mon, 13 May 2002 14:51:58 +0200
> This issue was worrying me slightly has well. If you do the
> above, then that may cause the time display to become inaccurate.
I didn't think of that. You are correct.
> Since drafting the API, I have realised that there are two
> kinds of seek:
> 1) The user requesting a seek +/- N seconds
> 2) Resuming playback of a track at the place it was last stopped.
> So, I would like to suggest that the new_track() function
> takes a byte offset as a parameter, as well as a time offset.
> If one of them is "null" (whatever that will be) then the
> mpeg thread is responsible for calculating the other.
OK. In case 1) above, the seek is relative to a supposedly correct time, so
it would only have to analyze N seconds of MP3 data.
In case 2), we will hopefully have the information stored in the struct
described below, so no MP3 analysis is needed at all.
> This structure needs to store both the current time (for
> display to the user) and the current file position (for
> saving to disk to allow a proper resume).
Actually, the MPEG thread would really want both of these.
> I think we only need 1 second accuracy - i.e. this gets
> updated once a second by the mpeg thread.
Received on 2002-05-13