[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Increasing mpeglib delivery buffer size
From:       Martin Vogt <mvogt () rhrk ! uni-kl ! de>
Date:       2000-08-27 19:17:03
[Download RAW message or body]

On Sun, Aug 27, 2000 at 08:39:30PM +0200, Stefan Westerfeld wrote:
>    Hi!
> 
> Currently, the structure while decoding mp3's is like this
> 
>   mpeglib   [ delivery buffer ]  aRts  [ soundcard hardware buffer ]  hardware
>  (threaded)     32768 bytes             (fragsize*fragcount) bytes
> 
> As far as I understood it, both of these buffers are non-blocking, which
> means:
> 
>  * if the hardware buffer is not full enough, the hardware starts playing
>    silence, which you hear as dropout
>  * if the delivery buffer is not full enough, aRts inserts silence, which
>    you hear as dropout
>

We cant make the deliverybuffer any bigger, reason:

audio+video sync.

The /dev/dsp has a size of 64KB and the deliverybuffer of 32KB.
If you increases it anymore the sync in video becomes
worse.
Its simply not possible to set it higher as it currently is.
sorry.

But we can try to make the buffer blocking.
Simply remove in decoderBaseObjec-Impl.cpp this line:


    if (outputStream->getBufferFillgrade() > 8192) {
      lenough=true;
    }

This test if we have enough data, but I think that this
makes smooth mixing of streams worse, because it blocks
on startup as well.
(kjukebox does not like this)

Maybe we can find something like:

- insert zeros until the buffer is filled _once_ with 8192 byte
- then use always the blocking mode.
(can be done with a variable in decoderBaseObject_imp.cpp/h)

 
> The buffer sizes in a normal (comfortable) aRts session in milliseconds are:
> 
>  * hardware buffer 5*8192 / (44100*4) = 230 ms
>  * delivery buffer 32768  / (44100*4) = 186 ms
> 
> Currently, I am not sure if increasing the delivery buffer might help to
> avoid real life dropouts. I tried increasing it to 128kb, and played with
> the modified version a bit. Well, you still can make it dropout (like:
> creating N processes that each allocate 1 mb and do some calculations on
> it - with sufficient large values of N, this always works ;).
> 
> I am not sure if the results have improved, and I am also not sure if my
> patch is correct, and if the mpeglib <-> aRts interaction is structured in
> a way that this ought to help. Well, I attached it, maybe someone can come
> up with good reasons/tests why we should or shouldn't apply it.
>

Because of the audio video sync, we cannot do it.
On low encoded stream (11Khz mono) the video still is
not smooth because the buffer is already 96 KB.
(Remember that mtv uses a buffer of 8192*byte* to have good video sync
to have 96KB and still have good sync is absolutely the limit!)

regards,

Martin

 
>    Cu... Stefan
> -- 
>   -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
>      KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

> ? mpeglib/lib/output/artsOutputStream.cpp.my
> Index: mpeglib/lib/splay/mpegsound.h
> ===================================================================
> RCS file: /home/kde/kdemultimedia/mpeglib/lib/splay/mpegsound.h,v
> retrieving revision 1.2
> diff -b -u -p -u -r1.2 mpegsound.h
> --- mpeglib/lib/splay/mpegsound.h	2000/07/17 15:40:07	1.2
> +++ mpeglib/lib/splay/mpegsound.h	2000/08/27 18:17:07
> @@ -75,7 +75,7 @@ extern "C" {
>  #define MAXSCALE           (SHRT_MAX)
>  #define MINSCALE           (SHRT_MIN)
>  #define RAWDATASIZE        (2*2*2*32*SSLIMIT)
> -#define DELIVERBUFFERSIZE  32768
> +#define DELIVERBUFFERSIZE  4*32768
>  
>  #define LS 0
>  #define RS 1

_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]