Hi, Barry
Barry Scott wrote:
Hartmut Hackmann wrote:
Hi, Barry
Barry Scott wrote:
I'm noticing that the KWORLD DVB-T 220 with the
TDA10046H tuner is very slow to tune 2 to 5 seconds.
Cards like the AverMedia 771 tune in less then a second.
Is this a problem with the driver or the chip?
Barry
This is not normal, do you use a recent version of driver and firmware?
I'm using a snapshot pf HG from 27-Apr-2006.
Will latest code help with this problem?
This is recent enough.
The tuning takes about 0.5 seconds. With good signals, the TDA10046
locks within a second. You need to add the time for the DVB application
to fill its buffers and to find an I-frame. This is longer but the same
for all cards.
I'm working with xine and its input_dvb.c code. Its debug messages
show the progress of the locking. I'm reporting the time it take the driver
to report via its status ioctl that its locked. I'm not counting the
time it
takes to then receive enough DVB-T packets to play on the screen.
Ok, but strange...
But: the first lock in a session (open dvb device) always takes longer
becase the chips need to recover from sleep mode, check and download the
firmware and determine some parameters. This is partly intention, partly
chip behaviour.
This could be the problem. In xine it will open the dvb device and tune it,
which will always hit the this problem. How can I confirm that its the
wake up from sleep and firmware reloading that is the delay?
You can see this in the kernel log. Each time it returns from sleep mode,
it will check the firmware version and report this in the kernel log.
How can the driver be changed to avoid the sleep and reload
of the fireware? I need to find a fix for this problem.
Its hard to belive that this is the problem. When i worked with xine, i saw
the initialization messages only once at startup, not when i switched
channels. I haven't checked this in the recent version, but older versions
of the dvb code kept the frontend alive for about a second.
There is a sleep function in saa1734-dvb.c and in tda1004x.c and an
approriate init function. But you play with this at your own risk, it took me
a lot of time to get this reliable.
If the lock always takes longer, this might be due to poor signal
quality.
Signal quality is good.
Hm, what does tzap tell you?
I remember a long discussion with a guy who used a bad antenna cable...
Updating the firmware might help.
There also is one special issue with the TDA8275a silicon tuner: Due to
its pinciple, it is sensitive to strong transmitters on another channel.
Classic tuner "cans" handle this better.
How close does the frequency of the other channel have to be for this
to be an issue?
This is the problem with this chip: anywhere. The tuner only has a filter
for the whole band AFTER the first gain stage. So even a CB transmitter is
a problem.
But again: which firmware revision is on your card? You should ensure that you
have version 2.9. if you need fastest possible locking time.
A hint: are you aware that DVB is not as restrictive with the GOP length as the
DVD standard? For me it sounds dangerous to rely an a short and stable lock in
time.
Hartmut
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
