[linux-dvb] TDA10046H very slow to tune

Adam Charrett ajmcharrett at hotmail.com
Wed Aug 16 15:42:28 CEST 2006


If your worried about the wake up delay  for the frontend you could try 
using the piece of software I've written to get round this very problem.

Its not quite as simple as typing xine dvb://<Channel Name> but its not far 
off.
Have a look at http://dvbstreamer.sourceforge.net, if you use dvbstreamer to 
send the channel to udp port 1234 you can then simply type xine 
udp://localhost:1234 , and then select the channel you want to watch in 
dvbstreamer (you don't even need to close xine to change channels).

It keeps the tuner open all the time and constantly monitors the PSI/SI for 
the current multiplex so it always up to date, and only retunes when the 
selected service is not on the current multiplex.

Cheers

Adam

>From: Barry Scott <barry.scott at onelan.co.uk>
>To: Hartmut Hackmann <hartmut.hackmann at t-online.de>
>CC: linux-dvb at linuxtv.org
>Subject: Re: [linux-dvb] TDA10046H very slow to tune
>Date: Wed, 16 Aug 2006 13:47:12 +0100
>
>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?
>>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.
>>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?
>
>How can the driver be changed to avoid the sleep and reload
>of the fireware? I need to find a fix for this problem.
>>If the lock always takes longer, this might be due to poor signal quality.
>Signal quality is good.
>>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?
>
>Barry
>
>
>_______________________________________________
>linux-dvb mailing list
>linux-dvb at linuxtv.org
>http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb





More information about the linux-dvb mailing list