Hallo, > 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 [EMAIL PROTECTED] should notice that (therefore a cross > posting is needed IMHO:). For readers of [EMAIL PROTECTED]: 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 > > > -- Attached file included as plaintext by Listar -- > -- Desc: dvb-20030326-driver.dif
I tried the patch but unfortunatly it did not change the AC3/DD dropout situation :( Configuration : VDR 1.1.26 ALSA 0.9.2 Bitstreamout 0.44d DVB 1.0.0-pre2 DVB CVS 200326 with included patch from this mail. Hardware : CMI8738 Soundcard (Nightingale 4.1 with external SPDIF out) 1 DVB-s rev. 1.3 1 WinTV Nova-s model 541 Intel i815 Maniboard Greetings Christian -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
