[vdr] Re: DVD frozen every 2 seconds

["Dr. Werner Fink" <werner@suse.de>]

On Tue, Apr 09, 2002 at 09:38:35PM +0200, Andreas Schultz wrote:
> On Tuesday 09 April 2002 18:28, Christoph Rieder wrote:
> > Maxime GUILBOT wrote:
> > > Maxime GUILBOT
> > >
> > > Hi, everybody,
> > > First, thank you Klaus for your great work.
> > > Actually, I'm writing a message to this list because I have a problem
> > > while reading DVD,
> > > the image (and sound) is frozen every 2 seconds that make the DVD
> > > unusable. I'm using a pentium 133, 48 Mo RAM, AC3 out over DVB (works
> > > well with JVC), LiveAC3, the last vdr-1.0.0 AIO, dvd libs for
> > > dvdinstall.tar (with DVDCSS_METHOD=key).
> >
> > I had the same problem. The conclusion was that AC3 conversion takes to
> > much cpu for my good old P133. So probably VDR tries to decode AC3
> > instead of forwarding it to your external decoder/amplifier?
> 
> can't check right now, but with AC3=1, vdr should not try to decode AC3.
> But it certainly sound, as if the problem is related to the LiveAC3 patch.
> I'll check it later.

Hmm ... the LiveAC3 part does not decode but there are two threads and
one pipe process running at high priority (the dmx reading thread, the
aFile thread writing onto a pipe and behind this pipe the ac3dec or
ac3play process) ... maybe an P133 isn't powerfull enough for that.

Maybe it helps to comment out the lines:

  // We increase priority to decrease delays
  struct sched_param param;
  param.sched_priority = sched_get_priority_max(SCHED_RR);
  if (pthread_setschedparam(pthread_self(), SCHED_RR, &param) < 0)
     esyslog(LOG_ERR, "LiveAC3 thread can not set scheduling priority: %s", strerror(errno));
  if (nice(-20) < 0)
     esyslog(LOG_ERR, "LiveAC3 thread can not set process priority: %s", strerror(errno));

in dvbapi.c  ... but this may cause bad AC3 sound.
The higher priority isn't used in the most cases (average load at home after
a few minutes is around 0.06-0.02% on a Celeron 1000) nevertheless, if the
reading thread is ready for reading he should do that as fast as posssible
to avoid buffer overflow during higher system load.

BTW: You should use a glibc which is optimized for i486 or higher (default
for the most distributions today) because with i386 there is not thread
safe process handling given.


        Werner