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

[Philippe Roussel]

Hi,

Le 21/05/2012 19:23, Sebastian Reitenbach a écrit :
>  
> 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.

Great, thanks for testing.

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

Definitely, as you say it works quite well. It's just that I don't like
fixing without understanding :o)

Philippe