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
From: Nielsen Linus (ext) (Linus.Nielsen_at_elema.siemens.se)
Date: 2002-05-13


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

A agree.

/Linus



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