[linux-dvb] Re: Transponder switching taking considerably longer

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Klaus Schmidinger wrote:
> 
> Johannes Stezenbach wrote:
> >
> > Klaus Schmidinger wrote:
> > >
> > > Switching transponders works very fast with this, but right after a
> > > channel switch (even between channels on the same transponder) there
> > > are glitches in audio and video :-(
> >
> > Hm, I don't see why. Can anyone confirm this?
> 
> The problem is the introduction of the dvb_frontend_internal_ioctl(&fe->frontend, FE_RESET, NULL)
> call in dvb_frontend_thread() in case of (fe->lost_sync_count < 10).
> I added a printk() to see how often this is triggered and I have this rather often,
> sometimes even after the chanel has been switched to for quite a while.
> Apparently this is what causes the glitches, because if I remove this call,
> all is fine again (although the tuning between transponders is slow again).
> 
> Are you sure this change does what you intend it to do?

Some more info: I went back to the 2003-07-25 DVB driver (with the udelay(800) calls
in frontends/alps_bsrv2.c as suggested yesterday) and found that the
'if (fe->lost_sync_count < 10)' condition is met a lot less often there than
it is in the current CVS version. In fact in the current CVS version the
fe->lost_sync_count is incremented so often that it sometimes even runs into
the 'dvb_frontend_recover (fe);' line (that's when I comment out the call to
dvb_frontend_internal_ioctl(&fe->frontend, FE_RESET, NULL) to avoid the artefacts),
which causes glitches in the middle of watching a channel or recording from it
(I believe we did have a problem in that area a while ago, that's why I suggested
the patch that went into rev 1.20 of dvb_frontend.c).

Klaus


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