[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
time.


Hartmut



More information about the linux-dvb mailing list