Re: [Gap-dev-discuss] Cynthiune : MP3 bundle and long delays

[Sebastian Reitenbach]

On Sunday, May 20, 2012 20:45 CEST, Philippe Roussel <address@hidden> wrote: 
 
> Hi,
> 
> I got the MP3 bundle to seek very fast but I would like you guys to try
> to understand the code because I'm missing something.
> 
> To suppress the long delay while seeking through a mp3, the following is
> enough :
> 
> Index: Bundles/MP3/MP3.h
> ===================================================================
> RCS file: /sources/gap/gap/user-apps/Cynthiune/Bundles/MP3/MP3.h,v
> retrieving revision 1.2
> diff -u -r1.2 MP3.h
> --- Bundles/MP3/MP3.h 30 Apr 2012 14:40:29 -0000      1.2
> +++ Bundles/MP3/MP3.h 20 May 2012 18:35:06 -0000
> @@ -25,7 +25,7 @@
> 
>  @protocol Format;
> 
> -#define IBUFFER_SIZE 5 * 8192
> +#define IBUFFER_SIZE 8192
> 
>  typedef mad_fixed_t MadFixed;
> 
> 
> If this doesn't add too much overhead on small cpus I think this should
> be applied.

I tested it on my i386, which has a 

cpu0: Intel(R) Pentium(R) M processor 1.40GHz ("GenuineIntel" 686-class) 1.41 
GHz

And it definitely fixes the long hangs while seeking, and also at the beginning
of playing each MP3, it was stuttering, and also waiting for about 5 seconds, 
before
I could hear anything. Now it starts nearly instantly, and without the annoying
stuttering.

Haven't tested on the macppc yet, there I had the same problems, and I guess
they will also be gone. Riccardo, do you have something slower around 
where you could test the patch?

> 
> BUT, I'd would to love to understand the code in MP3.m
> -readNextChunk:withSize so please explain it to me if you can.
> 
> In short, from what I understand, when the decoding buffer is empty, we
> fread data from the file, IBUFFER_SIZE - iRemain bytes at a time. It
> appears that most of the time IBUFFER_SIZE - iRemain = 1 so we're
> reading char by char.... For each char read we call decodeInputBuffer()
> which won't return BufferHasNoError before the buffer is big enough so
> we loop a lot of time before returning a decoded buffer, thus the delay.
> 
> I'm quite sure this whole code is wrong and way too complicated but I
> could be wrong. Someone should probably read the libmad documentation
> and start from scratch.
> 
> Anyway, if you have an explanation for this code, I'm all ears :o)

Had no time yet, to look at the code, hope to be able to do it some time 
this week. Otherwise, it seems to work well so far. So we could postpone
improvements after the release.

cheers,
Sebastian

> 
> Thanks,
> Philippe
> 
> 
>