[linux-dvb] Question about Frontend performance (TDA10046 +
Chun Chung Lo
cclo at astri.org
Fri Aug 18 02:49:10 CEST 2006
Thanks to your reply.
The reason I use such old source code for SAA7130/4 is I cannot find any
newer SAA7130/4 driver for LINUX kernel 2.4.
After I checked the changelog from the CVS server of linuxtv.org, I
found that SAA7130/4 driver is first ported to LINUX kernel 2.6, and I
cannot found any clue the driver will backport to LINUX kernel 2.4 ....
But I have tired my driver, since the TS is captured when application
request, the performance is quite bad, so I consider to reference to
LINUX kernel 2.6, to create a kernel thread to do such capture, but I
found that it is difficult for me ...
Anyway, thanks for your help
Lo Chun Chung
From: Hartmut Hackmann [mailto:hartmut.hackmann at t-online.de]
Sent: Friday, 18 August, 2006 5:42 AM
To: Chun Chung Lo
Cc: linux-dvb at linuxtv.org
Subject: Re: [linux-dvb] Question about Frontend performance (TDA10046 +
Chun Chung Lo wrote:
> Thanks for your quick reply.
> As the STB is operating under linux kernel 2.4 (powerpc), so my driver
> is composed by several versions of DVB-T codes:
> For SAA7130/4 driver, I used the source codes from
From a quick glance, this code looks very old. You should be more lucky
when you search the linuxtv.org download archive for the last version
that compiles with kernel 2.4. Does anybody know by heart which one this
> For the driver of TDA10046 + TD1316, I used the codes from linux
> kernel 18.104.22.168.
This is ok.
> I know the SAA7130/4 driver is old, but the main problem is I do not
> know how to back port the video-buf-dvb.c (SAA7130/4 DMA buffer
> handling functions)from linux kernel 2.6 to linux kernel 2.4 (mainly
> due to the "kthread_run()", "kthread_create()" stuff) as I am a newbie
> on driver porting.
Indeed, this might be difficult.
But if you stick to the old version, you really should compare the code
with the recent version. You need to port several bug fixes, especially
the ts buffer handling bug and most probably the fixes in the I2c
> As the TS capture of the SAA7130/4 driver is not done by kernel
> thread, it consumes lots of resources and the performance is not so
> good during I capture TS.
> Are there any suggestion to me?
> Thanks for your kindly help.
> Best regards,
> Lo Chun Chung
> -----Original Message-----
> From: Hartmut Hackmann [mailto:hartmut.hackmann at t-online.de]
> Sent: Thursday, 17 August, 2006 5:50 AM
> To: Chun Chung Lo
> Cc: linux-dvb at linuxtv.org
> Subject: Re: [linux-dvb] Question about Frontend performance (TDA10046
> Chun Chung Lo wrote:
>>I am now working on a DVB-T STB projects. SAA7130HL + TDA10046A +
>>TD1316 is used.
>>Previously I have made some tests on our STB. The TDA10046 + TD1316
>>status are monitored during all the tests performed, by using the
>>'tzap' utilities (bundled in linuxtv-dvb-app-1.1.1)
>>Different degrees of corrupted TS is captured (a TS-to-PES software is
>>used to runtime convert the catpured TS to a normal mpeg2 movie).
>>There are different fields can be monitored by using 'tzap', such as
>>Signal Strength, SNR, BER, UNC, etc ... And I would like to know the
>>1. All tests has a zero UNC, but a little BER is recorded (about 120
>>out of 128K). Will this is the main reason of the corrupted TS?
> I can't tell right now how these values are scaled. UNC stands for
> uncorrected blocks while BER stands for the raw bit error rate.
>>2. When BER > 0, is this means there exists some corrupted TS packets?
>>If no, what does BER > 0 means (under this circumstance)?
> It depends on the DVB configuration, but to my experience in Germany,
> you are fine as long as BER is less than ~4500 (and UNC is 0)
>>3. When UNC or BER (or both) > 0, will this means the discontinuity of
>>the TS stream?
>>4. Or the corruption of the captured TS is due to insufficient
>>processing speed of the driver? (DMA? Buffers processing?)
> There was a bug in the transport stream capture (saa7134-ts.c) i fixed
> 11 months ago. If your driver is older, you need to update it.
> Processor load is low if you just capture the stream. But a problem
> might be that IDE DMA is not working properly on your system. This
> might cause high latencies in the kernel and thus data loss.
>>5. Will the TS stream BW (or other settings) affect the capture
>>performance? (I do not know but I have tried Test A and B several
>>times and the result are quite coherent, as stated above).
> If you use wrong parameters for the channel decoder, it will not lock
> in most cases. But what about the code for the TD1316? Where does this
> come from? do you have a TD3116A or do you use some seperate IF
>>Please help and thank you for your attention.
>>Lo Chun Chung
> Hope this helps
> This message (including any attachments) is for the named
> addressee(s)'s use only. It may contain sensitive, confidential,
> private proprietary or legally privileged information intended for a
> specific individual and purpose, and is protected by law. If you are
> not the intended recipient, please immediately delete it and all
> copies of it from your system, destroy any hard copies of it and
> notify the sender. Any use, disclosure, copying, or distribution of
> this message and/or any attachments is strictly prohibited.
This message (including any attachments) is for the named addressee(s)'s use only. It may contain
sensitive, confidential, private proprietary or legally privileged information intended for a
specific individual and purpose, and is protected by law. If you are not the intended recipient,
please immediately delete it and all copies of it from your system, destroy any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any
attachments is strictly prohibited.
More information about the linux-dvb