[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gap-dev-discuss] Cynthiune : MP3 bundle and long delays
From: |
Philippe Roussel |
Subject: |
Re: [Gap-dev-discuss] Cynthiune : MP3 bundle and long delays |
Date: |
Mon, 21 May 2012 20:39:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
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