[linux-dvb] TDA10046H very slow to tune

Hartmut Hackmann hartmut.hackmann at t-online.de
Wed Aug 16 23:22:49 CEST 2006

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


More information about the linux-dvb mailing list