[vdr] Re: LiveAC3 and PW

[Stephan Schreiber <stephan@sschreiber.de>]

Thank you for the link to ac3play!
It is indeed much better than ac3dec, especially when it comes to 
synchronicity.
Sadly, it doesn't help very much, as my former success is not reproduceable 
anymore.
It worked shortly (with a buffer of 16k), but no more.
Unfortunately I can't test Pro7, as I have DVB-C.
I have now only Premiere Direkt 1 (former Cinedom DL) for testing, which 
tends to get expensive after a while...
(The magazine says the next AC3 broadcast on Premiere 1 will be on sunday)
However, my recordings play very well in 5.1, only LiveAC3 doesn't work 
reliably.....
At the time I'm writing this, it's again working on Premiere Direkt 1. This 
time with 12k buffer and ac3play. And it is not lip-synchronous. Strange......
I started vdr with -a ac3play (no parameters)
I'll investigate and keep you up to date.
Please drop me a PM if you have any hints on how to debug this issue.

Thanks,
Stephan


At 18:06 02.05.2002 +0200, you wrote:
>On Thu, May 02, 2002 at 05:29:14PM +0200, Stephan Schreiber wrote:
> > Hi,
> >
> > I had to even increase the size to 16k to make it work.
> > Strange: where does that different bahaviour of my machine come from?
> > For the first time, LiveAC3 works for me now! :-)))))
> >
> > Thanks,
> > Stephan
>
>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).
>
>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).
>
>
>         Werner
>
>
> > >===== dvbapi.h 1.6 vs edited =====
> > >--- 1.6/dvbapi.h        Mon Apr 22 12:34:02 2002
> > >+++ edited/dvbapi.h     Sun Apr 28 15:28:52 2002
> > >@@ -461,7 +461,7 @@
> > >    sigset_t oldset;
> > >    bool active;
> > >    bool busy;
> > >-  uint8_t buffer[6144];
> > >+  uint8_t buffer[12*1024];
> > >    int fd_dolby;
> > >    virtual void StripAudioPackets(unsigned char *b, int Length, unsigned
> > > char
> > >Except = 0x00);
> > >    virtual bool SetDpid1(int Dpid, dmxOutput_t Output);