Rockbox.org home
dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re[2]: cvs: firmware mpeg.c,1.206,1.207

Re[2]: cvs: firmware mpeg.c,1.206,1.207

From: Uwe Freese <mail_at_uwe-freese.de>
Date: Mon, 3 Mar 2003 18:09:31 +0100

Hello Daniel,

Daniel Stenberg wrote on Monday, March 3, 2003, 3:11:21 PM:

> amount_to_read = MIN(mp3buflen - mp3buf_write, amount_to_read);
> +#if MEM == 8
> + amount_to_read = MIN(0x100000, amount_to_read);
> +#endif
> Could you explain why the old code did not work?

As I understand it, 1,7 MB (with a 2 MB AJB) is read in one piece when
filling the buffer the first time. With an 8 MB AJB, it is 7,7 MB. That
means that bitswapping (or something else) is started too late (after
reading these 7,7 MB) and data that's not bitswapped (?) is fed into the

The one additinal line is the remaining line after I deleted all changes
of my previously working mpeg.c.

I didn't write that mpeg.c and don't know how it exactly works! Sorry,
but I thought it's better to have at least a working version (for 8MB)
in CVS. (no changes when compiling as 2 MB version)

>> Your change replaces the
>> dynamic buffer space calculation with a static 0x100000 read. Why? This
>> should not be necessary.

Dynamic? It only limits one read to 1 MB somehow. I thought that it was
no problem. And the result was that it works. The best I can do at this

DS> As I was saying already before, the 8MB version may need different
DS> thresholds. It should *not* require different code... AFAICT.

This could be true, but I already tested around with the values in
mpeg.h and didn't find working ones (and this is also trying around
blindly since I don't know how the buffering works exactly).

So someone has to guess what values could work and then I can test them.
I see no alternative..

Bye, Uwe.
Received on 2003-03-03
