Rockbox mail archiveSubject: Re: Suggested mpeg playing API
Re: Suggested mpeg playing API
From: Dave Chapman <dave_at_dchapman.com>
Date: Mon, 13 May 2002 13:51:37 +0100
On Monday 13 May 2002 13:08, Linus wrote:
> However, the seek function does not have to be accurate. We want to use it
> for skipping back and forth while playing, so a millisecond here and there
> doesn't matter that much. The seek function can analyze the next two or
> three frames and assume that the rest of the frames are of the same length.
This issue was worrying me slightly has well. If you do the above, then that
may cause the time display to become inaccurate.
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.
We should always try to give the mpeg thread both.
I think it is important to remember that most of the time, the jukebox will
just be playing consecutive tracks from start to end - i.e. starting at byte
offset 0, time offset 0.
> > > 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.
> Yes we do. The information from the MAS is only valid at certain times. So
> the MPEG thread needs to read it from the MAS and keep the info in a
> separate place.
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).
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