From: Nielsen Linus (ext) <"Nielsen>
Date: Mon, 13 May 2002 14:08:05 +0200

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

I and Björn had exactly this discussion over lunch, and I am of
the same opinion as yours. However, we do need _some_ kind of seek
possibility, and milliseconds is as good as any unit.

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

Why should the UI coder need to worry about how an MP3 file is encoded? I
definitely think that is the job of the MP3 driver.

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

Correct. The MAS can only analyze the frames while playing. If we want to
find a certain position in the file, we have to do it ourselves.

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.

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

Good point. So we need some good return codes from at least some of the
functions.

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

True. But it will definitely complicate the application code.

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

> But we probably could establish a mechanism that inserts a single mp3
> frame into the stream being played. This beepFrame could be
> hardcoded.

Brilliant idea. But it is quite tricky to implement. Very tricky, but it can
be done.

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

Do we need that?

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

Too bad it isn't an even byte sequence. Digging through the MP3 stream
looking for a 12-bit sequence isn't exactly painless...

> Maybe the MAS can help here -> investigation needed.

I don't think the MAS can help us, since it doesn't tell us the byte
position where it found the sync. Just that is found it somewhere in its
internal buffers.

/Linus
Received on 2002-05-13