[linux-dvb] Re: EPG scan cause high load and AC3 drop outs - maybenot solved yet ?

[Jeremy Hall <jhall@maoz.com>]

Have you tried using the module parameter that makes the sections be 
processed by the host rather than the AV7110? That made happy days for me, 
although for some reason some sections give CRC failures when in soft mode 
and when using the AV7110 they did not.  I haven't filed a report because 
I'm not sure what is causing it.

_J

In the new year, Dr. Werner Fink wrote:
> On Thu, Mar 27, 2003 at 08:58:52AM +0100, Christian Jacobsen wrote:
> > 
> > While using VDR 1.1.26 I Yesterday saw a kdvb-fe process using 29% CPU Time
> > again (Pentium3 933).
> > 
> > I used "top" so it is only snapshots of what really happens. Did not watch
> > it that long - but Sometimes it uses less that 1% and sometimes it uses 29%.
> > Is there a better tool for watching such things ?
> > As far as i remember the exact name of the process was kdvb-fe1:0 (or
> > kdvb-fe-1:0)
> > IIRC this is the process that switches channels ? Does it do other things to
> > ?
> > 
> > Could it be involved in the "AC3-processing" - so that the high IRQ load
> > also causes this high load on kdvb-fe ?
> > 
> > Is 1:0 somehow related to the card it is running on ?
> 
> see driver/dvb_frontend.c at dvb_frontend_thread() ...
> 
> [...]
>         snprintf (current->comm, sizeof (current->comm), "kdvb-fe-%i:%i",
>                   fe->frontend.i2c->adapter->num, fe->frontend.i2c->id);
> [...]
> 
> ... IMHO the first is the card used on the i2c bus (1 == the second), the
> second number is the i2c bus its self. What I2C is for see
> /usr/src/linux/Documentation/Configure.help , search for CONFIG_I2C, and
> /usr/src/linux/Documentation/i2c/summary .
> 
> I2C is a slow dog but is used for programming/reading registers of the
> DVB cards. IMHO there are also missed some
> request_mem_region()/release_mem_region() within av7110/saa7146_core.c 
> also a better wait mechanism as mdelay().  Maybe the patch attached
> will help to for this.
> 
> The thread dvb_frontend_thread() calls dvb_frontend_recover() which is used
> for compensating LNB drift.  IMHO this should not happen (nevertheless it
> could be the first reason of the high load!!).
> Beside this, this is what I've found by searching for lost_sync_count:
> 
> /**
>  *  if 2 tuners are located side by side you can get interferences when
>  *  they try to tune to the same frequency, so both lose sync.
>  *  We will slightly mistune in this case. The AFC of the demodulator
>  *  should make it still possible to receive the requested transponder 
>  *  on both tuners...
>  */
> 
> ... and this could also explain why users of two or more DVB cards (full
> featured or not) are `able' to see the phenomena you've described during
> EPG scans.
> 
> IMHO the ml linux-dvb@linuxtv.org should notice that (therefore a cross
> posting is needed IMHO:). For readers of linux-dvb@linuxtv.org: the
> drop outs are happen during live view of Pro7 which means that the TS
> stream has longer timeouts beginning with some bit failures which are
> found by a CRC check of a VDR plugin forwarding the AC3 data stream
> to the S/P-DIF of a sound card.
> 
> 
>         Werner
Content-Description: dvb-20030326-driver.dif

[Attachment, skipping...]



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.