Rockbox mail archive
Subject: RE: Suggested mpeg playing API
From: Nielsen Linus (ext) (Linus.Nielsen_at_elema.siemens.se)
> 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.
Page was last modified "Jan 10 2012" The Rockbox Crew