Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: LiveAC3 and PW



On Fri, May 03, 2002 at 12:51:06AM +0200, Andreas Schultz wrote:
> > Strange ... on Pro7 the frames read from are less or equal than 2048
> > bytes (the real payload its self is about 1728 bytes). Sometimes it
> > happens that the LiveAC3 thread will started reading the end of
> > such a frame and therefore the thrad should have buffer for 2*2048 bytes
> > ... and now it may happen that the LiveAC3 thread `sees' the beginning of
> > the next frame at the end of the current frame ... therefore 3*2048 should
> > be enough.  Maybe PW provides AC3 in groups of 2048
> > bytes frames and not reading them may cause an buffer overflow in
> > the DVB driver which leads to an reset of this buffer (and at least
> > to drop outs).
> 
> PW sends PES frames that are much larger (about 7k or so), the included AC3 
> frames are normal 1536bytes per frame.

Hmmm  ... IMHO the buffer of LiveAC3 should 3 times larger than that.
Nevertheless this may lead to a sound buffer underrun because for
a bit rate of 512 kbps and 1536 sound samples it takes a long time
(1536 sound samples aka 1536 bytes at 48kHz are a delay of 32ms).

... Maybe I should extend the ringbuffer used in my ac3play clone to
an FIFO buffer, which can take more than the pipe max buffer of
the kernel (4096 bytes) for having a delay by simply sliding the readed
data through a bigger FIFO buffer.

Or I finish the alsa part I'm currently doing for VDR to avoid the pipe.

> 
> > You may test the ac3play 0.5.2f which I've developed for LiveAC3
> > as a replacment for the original ac3play 0.5.0, my former ac3play 0.5.1f
> > and ac3dec.  You found this at
> >
> >      http://www.alsa-project.org/~iwai/ac3play-0.5.2f.tar.bz2
> >      http://www.alsa-project.org/~iwai/ac3play-0.5.2f-0.i686.rpm
> >
> > this ac3play should be lip synchrony.  This ac3play version has a
> > special LOW sound chip buffer state handling for reading from
> > pipes (as VDR provides): Read as fast as possible, scan and put the fetched
> > AC3 into the sound chip buffer and then wait for next input (instead of
> > waiting of getting more input to fully refill the input buffer).
> 
> strange, when i use LiveAC3 with a52dec to output through a SBLive on Pro7, 
> audio is a bit to early compared to the DVB output. I already thought about 
> introducing a small delay in LiveAC3 to get it syncronized.

Cool ... maybe the SBLive is much faster than the onboard CMI8738
of my motherboard. Or ac3dec doesn't use the hardware buffer of the
SBLive, my ac3play clone uses a hardware buffer of 10*1536 bytes (or
better audio samples) which are 10 AC3 frames ... during LiveAc3 this
buffer is filled with 2 ... 5 AC3 frames (before/after reading from pipe).


         Werner



Home | Main Index | Thread Index