[linux-dvb] RE: linux-dvb Digest, Vol 13, Issue 45

sajjan.jyothi at wipro.com sajjan.jyothi at wipro.com
Wed Feb 15 13:52:02 CET 2006


Hi,
   Please help me to begin programming of donau family from thoshiba.
-Sajjan

-----Original Message-----
From: linux-dvb-bounces at linuxtv.org
[mailto:linux-dvb-bounces at linuxtv.org] On Behalf Of
linux-dvb-request at linuxtv.org
Sent: Wednesday, February 15, 2006 6:20 PM
To: linux-dvb at linuxtv.org
Subject: linux-dvb Digest, Vol 13, Issue 45

Send linux-dvb mailing list submissions to
	linux-dvb at linuxtv.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
or, via email, send a message with subject or body 'help' to
	linux-dvb-request at linuxtv.org

You can reach the person managing the list at
	linux-dvb-owner at linuxtv.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of linux-dvb digest..."


Today's Topics:

   1. Re: [PATCH] Kworld-ATSC110 (maillist)
   2. pidPMT (toni martinez)
   3. Re: pidPMT (Marcel Siegert)
   4. Re: DVB-T devices supporting hierarchical mode?
      (Johannes Stezenbach)
   5. Re: SAA7146 DMA buffer overflow (Johannes Stezenbach)
   6. Re: DVB-T devices supporting hierarchical mode?
      (Robert Schlabbach)
   7. Re: DVB-T devices supporting hierarchical mode? (Manu Abraham)
   8. Re: SAA7146 DMA buffer overflow (Johannes Stezenbach)
   9. Re: SAA7146 DMA buffer overflow (Manu Abraham)
  10. Re: SAA7146 DMA buffer overflow (Oliver Endriss)
  11. Re: DVB-H, time slicing, MPE-FEC and multicast...
      (Johannes Stezenbach)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Feb 2006 03:08:10 -0800
From: maillist <maillist at boilerbots.com>
Subject: [linux-dvb] Re: [PATCH] Kworld-ATSC110
To: Michael Krufky <mkrufky at m1k.net>
Cc: Andrew Burri <andrew.burri at gmail.com>,	Dwaine Garden
	<DwaineGarden at rogers.com>,	Linux and Kernel Video
	<video4linux-list at redhat.com>,	David Freeman
<lists at davidfreeman.net>,
	LinuxDVB Mailing List <linux-dvb at linuxtv.org>
Message-ID: <43F30B9A.6090809 at boilerbots.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

# HG changeset patch
# User cmeyers at ford.site
# Node ID c433d5da9fe9095c4fb4861106d82b1c33ec44e3
# Parent  55f98daf92cfa71671b9bd6b4168a6fe99a8f438
Verified Kworld-ATSC110

I corrected the composite input and verified the S-video. I also
verified the audio mux.

Currently I am only able to receive ATSC HD content, not sure why QAM is
not working.

No radio functionality, probably something in the tuv1236D driver.

diff -r 55f98daf92cf -r c433d5da9fe9
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c    Wed Feb 15
02:19:47 2006 -0500
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c    Wed Feb 15
02:56:12 2006 -0800
@@ -2743,29 +2743,22 @@ struct saa7134_board saa7134_boards[] =
         .radio_type     = UNSET,
         .tuner_addr     = ADDR_UNSET,
         .radio_addr     = ADDR_UNSET,
-        .tda9887_conf   = TDA9887_PRESENT,
         .mpeg           = SAA7134_MPEG_DVB,
         .inputs         = {{
             .name = name_tv,
             .vmux = 1,
             .amux = TV,
             .tv   = 1,
-#if 0
-            /* these inputs are untested */
-        },{
-            .name = name_comp1,   /* not yet verified */
-            .vmux = 4, /* a later patch by
-                    * Curt Meyers <cmeyers at boilerbots.com>
-                    * uses .vmux = 3,
-                    */
-            .amux = LINE2,
-        },{
-            .name = name_svideo,  /* not yet verified */
-            .vmux = 8,
-            .amux = LINE2,
-#endif
-        }},
-#if 0
+        },{
+            .name = name_comp1,
+            .vmux = 3,
+            .amux = LINE2,
+        },{
+            .name = name_svideo,
+            .vmux = 8,
+            .amux = LINE2,
+        }},
+#if 0   // The TUV1236D supports FM radio but don't know how to
activate it.
         .radio = {
             .name = name_radio,
             .amux = LINE1,





------------------------------

Message: 2
Date: Wed, 15 Feb 2006 12:16:26 +0100
From: toni martinez <kinbonsin at gmail.com>
Subject: [linux-dvb] pidPMT
To: linux-dvb at linuxtv.org
Message-ID:
	<9c84df780602150316w324ea0d9i48fd3115e7b991ec at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

How can I obtain the pidPMT from a TS in real time?

thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.linuxtv.org/pipermail/linux-dvb/attachments/20060215/5dbbce89
/attachment-0001.htm

------------------------------

Message: 3
Date: Wed, 15 Feb 2006 12:31:36 +0100
From: Marcel Siegert <mws at linuxtv.org>
Subject: Re: [linux-dvb] pidPMT
To: linux-dvb at linuxtv.org
Message-ID: <200602151231.36713.mws at linuxtv.org>
Content-Type: text/plain;  charset="iso-8859-1"

On Wednesday 15 February 2006 12:16, toni martinez wrote:
> Hello,
>
> How can I obtain the pidPMT from a TS in real time?

hi,

filter on pid 0x0000 (pat)
table id 0x00 (pat)

after receiption of this table, iterate on the programm assosiation
part, look for a matching pmt pid entry for your programm number.

that pid given, is the one you're looking for.

regards
mws



------------------------------

Message: 4
Date: Wed, 15 Feb 2006 12:56:12 +0100
From: Johannes Stezenbach <js at linuxtv.org>
Subject: Re: [linux-dvb] DVB-T devices supporting hierarchical mode?
To: linux-dvb at linuxtv.org
Message-ID: <20060215115612.GC5510 at linuxtv.org>
Content-Type: text/plain; charset=us-ascii

On Wed, Feb 15, 2006, Patrick Boettcher wrote:
> On Tue, 14 Feb 2006, Mauro Borghi wrote:
> >Do you know about LinuxDVB-supported devices which are known to
> >support hierarchical modulation?
> >Is it meant to be sufficient setting HIERARCHY_2 in the struct passed

> >to the frontend device when tuning, in order to select the LOW
> >priority stream?
>
> Although it was most likely never tested with most of the
> demod-drivers in linux-dvb it should be possible with all of them.
>
> >From the tests I did with a Twinhan 7045 USB2 clone (from digicom),
> >the device seems to always lock on the HIGH priority stream, no
> >matter what params are passed!
>
> The Twinhan box has a MT352 inside and the controlling is done inside
> the
> FX2 USB firmware. As hierarchical transmission has significant
> drawbacks when used and no one (not even Twinhan :) ) expected that to

> be used anywhere, they don't have it implemented. Ie. there is no way
> to give this information to the firmware.

It seems to me that a parameter is missing in the Linux DVB API to
select between the high/low priority stream. If I understand it
correctly the hierarchy mode just modifies the modulation scheme, and
you still need a seperate knob to select which TS (high or low) the
frontend should output. Can someone confirm this?

I so, an easy way to fix without breaking API binary compatibility would
be:

typedef enum fe_hierarchy {
        HIERARCHY_NONE,
        HIERARCHY_1,
        HIERARCHY_2,
        HIERARCHY_4,
        HIERARCHY_AUTO
        HIERARCHY_1_LP = HIERARCHY_1 | 0x100,
        HIERARCHY_2_LP,
        HIERARCHY_4_LP,
        HIERARCHY_AUTO_LP
} fe_hierarchy_t;

And of course frontend drivers would need to be fixed to handle this.


Johannes



------------------------------

Message: 5
Date: Wed, 15 Feb 2006 13:00:04 +0100
From: Johannes Stezenbach <js at linuxtv.org>
Subject: Re: [linux-dvb] SAA7146 DMA buffer overflow
To: linux-dvb at linuxtv.org
Message-ID: <20060215120004.GD5510 at linuxtv.org>
Content-Type: text/plain; charset=us-ascii

On Wed, Feb 15, 2006, Sigmund Augdal Helberg wrote:
> On Tue, 2006-02-14 at 21:55 +0100, Ingo Schneider wrote:
> > Also, there is a special handling for BUDGET_FS_ACTIVY which has a
> > different buffer "layout" - why is this ?
> ACTIVY is a fujitsu siemens set top box. I guess it has one of these
> devices embedded. Being a small device running embedded linux this
> could need special buffer handling.

Siemens also sold PCI cards named ACTIVY. IIRC the hardware is slightly
different and the buffer layout is required to avoid certain saa7146 hw
bugs.

Johannes



------------------------------

Message: 6
Date: Wed, 15 Feb 2006 13:12:26 +0100
From: "Robert Schlabbach" <robert_s at gmx.net>
Subject: Re: [linux-dvb] DVB-T devices supporting hierarchical mode?
To: <linux-dvb at linuxtv.org>
Message-ID: <7319E50A02BD477D8FC0CD03E2AC5CA0 at powerstation>
Content-Type: text/plain;	charset="iso-8859-1"

From: "Patrick Boettcher" <patrick.boettcher at desy.de>
> Very interesting. I would have never thought that they will use
> hierarchical transmission in the real world, but anyway.

FWIW, channel 51 in Berlin, Germany is currently being used for
hierarchial test transmissions. See http://www.garv.de for a press
release and technical background.

Regards,
--
Robert Schlabbach
e-mail: robert_s at gmx.net
Berlin, Germany




------------------------------

Message: 7
Date: Wed, 15 Feb 2006 16:00:55 +0400
From: Manu Abraham <abraham.manu at gmail.com>
Subject: Re: [linux-dvb] DVB-T devices supporting hierarchical mode?
To: Johannes Stezenbach <js at linuxtv.org>,  linux-dvb at linuxtv.org
Message-ID: <43F317F7.3000005 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Johannes Stezenbach wrote:
> On Wed, Feb 15, 2006, Patrick Boettcher wrote:
>  
>> On Tue, 14 Feb 2006, Mauro Borghi wrote:
>>    
>>> Do you know about LinuxDVB-supported devices which are known to
>>> support hierarchical modulation?
>>> Is it meant to be sufficient setting HIERARCHY_2 in the struct
>>> passed to the frontend device when tuning, in order to select the
>>> LOW priority stream?
>>>      
>> Although it was most likely never tested with most of the
>> demod-drivers in linux-dvb it should be possible with all of them.
>>
>> >From the tests I did with a Twinhan 7045 USB2 clone (from digicom),
>> >the
>>    
>>> device seems to always lock on the HIGH priority stream, no matter
>>> what params are passed!
>>>      
>> The Twinhan box has a MT352 inside and the controlling is done inside

>> the
>> FX2 USB firmware. As hierarchical transmission has significant
>> drawbacks when used and no one (not even Twinhan :) ) expected that
>> to be used anywhere, they don't have it implemented. Ie. there is no
>> way to give this information to the firmware.
>>    
>
> It seems to me that a parameter is missing in the Linux DVB API to
> select between the high/low priority stream. If I understand it
> correctly the hierarchy mode just modifies the modulation scheme, and
> you still need a seperate knob to select which TS (high or low) the
> frontend should output. Can someone confirm this?
>  

Yes..
> I so, an easy way to fix without breaking API binary compatibility
> would be:
>
> typedef enum fe_hierarchy {
>         HIERARCHY_NONE,
>         HIERARCHY_1,
>         HIERARCHY_2,
>         HIERARCHY_4,
>         HIERARCHY_AUTO
>         HIERARCHY_1_LP = HIERARCHY_1 | 0x100,
>         HIERARCHY_2_LP,
>         HIERARCHY_4_LP,
>         HIERARCHY_AUTO_LP
> } fe_hierarchy_t;
>
> And of course frontend drivers would need to be fixed to handle this.
>  

Yeah, it looks good.


Manu





------------------------------

Message: 8
Date: Wed, 15 Feb 2006 13:21:55 +0100
From: Johannes Stezenbach <js at linuxtv.org>
Subject: Re: [linux-dvb] SAA7146 DMA buffer overflow
To: linux-dvb at linuxtv.org
Message-ID: <20060215122155.GE5510 at linuxtv.org>
Content-Type: text/plain; charset=us-ascii

On Tue, Feb 14, 2006, Ingo Schneider wrote:
> I hava a problem that I loose TS packets due to overruns of the SAA
> 7146 DMA buffer when the system is under I/O load (e.g. backup).
>
> I modified the budget-core.c to give warning when the buffer is nearly

> full to verify that this is really the cause (see code below).
> The simplest thing would be to increase the buffer size. The current
> size = 1024 TS packets, about 192k.

Processing is done from the irq handler (well, actually from a tasklet
triggered by irq). For a 30Mbit/s stream this buffer holds ~50ms worth
of TS packets which are then pushed into a larger ringbuffer where it
waits to be picked up by read() from the demux/dvr device. If the DMA
buffer overflows you have an irq/tasklet latency problem.

If your irqs/tasklets are delayed more than 50ms you need to find out
why. First check hdparm settings if you have ATA disk.
Second consider trying -rt kernel.

If you just try to increase the buffer size the vpeirq might create
similar latency problems for other drivers ;-/ IIRC the saa7146 has some
hw bugs which restrict DMA settings.

One thing you could try is to call vpeirq() directly from irq handler
(i.e. replace the tasklet_schedule() call).


HTH,
Johannes



------------------------------

Message: 9
Date: Wed, 15 Feb 2006 16:15:13 +0400
From: Manu Abraham <abraham.manu at gmail.com>
Subject: Re: [linux-dvb] SAA7146 DMA buffer overflow
To: Johannes Stezenbach <js at linuxtv.org>,  linux-dvb at linuxtv.org
Message-ID: <43F31B51.6030402 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Johannes Stezenbach wrote:
>
> Processing is done from the irq handler (well, actually from a tasklet

> triggered by irq). For a 30Mbit/s stream this buffer holds ~50ms worth

> of TS packets which are then pushed into a larger ringbuffer where it
> waits to be picked up by read() from the demux/dvr device. If the DMA
> buffer overflows you have an irq/tasklet latency problem.
>  

We came to some similar conclusions on this on the 878 based cards in
this regard, Sigmund Augdal has some interesting info in this regard, i
believe on this aspect.


Manu




------------------------------

Message: 10
Date: Wed, 15 Feb 2006 13:29:27 +0100
From: Oliver Endriss <o.endriss at gmx.de>
Subject: Re: [linux-dvb] SAA7146 DMA buffer overflow
To: linux-dvb at linuxtv.org
Message-ID: <200602151329.28092 at orion.escape-edv.de>
Content-Type: text/plain;  charset="us-ascii"

Ingo Schneider wrote:
> I hava a problem that I loose TS packets due to overruns of the SAA
> 7146 DMA buffer when the system is under I/O load (e.g. backup).
>
> I modified the budget-core.c to give warning when the buffer is nearly

> full to verify that this is really the cause (see code below).
> The simplest thing would be to increase the buffer size. The current
> size = 1024 TS packets, about 192k.
>
> I would tend to increase this buffer to about 1 or 2 megabytes to stop

> getting those TS continuity errors, is there a reason why this buffer
> was chosen to be so small ? Spec of
> SAA7146 says it can handle 4 megabytes for DMA.

I guess this size was chosen because dma buffer size is usually large
enough. Afaik you are the first one who needs a larger buffer...

Since the driver is widely used on systems with limited memory I vote
against increasing the default value.

But if you deliver a clean patch which adds a module parameter for that,
I will commit it to the hg repository (something like DMA_BUF_SIZE in
KByte).

> Also, there is a special handling for BUDGET_FS_ACTIVY which has a
> different buffer "layout" - why is this ?

The buffer size is the same, only the DMA ist configured in a slightly
different way. That must be done to strip the ECC bytes from the data
stream: 188 bytes data + 16 bytes ECC = 204 bytes total.

Other budget cards have a different hardware design and do not require
this.

Oliver

--
--------------------------------------------------------
VDR Remote Plugin available at
http://www.escape-edv.de/endriss/vdr/
--------------------------------------------------------



------------------------------

Message: 11
Date: Wed, 15 Feb 2006 13:48:53 +0100
From: Johannes Stezenbach <js at linuxtv.org>
Subject: Re: [linux-dvb] DVB-H, time slicing, MPE-FEC and multicast...
To: linux-dvb at linuxtv.org
Message-ID: <20060215124853.GF5510 at linuxtv.org>
Content-Type: text/plain; charset=us-ascii

On Mon, Feb 13, 2006, frankio wrote:
> I think dvbnet should honor multiprotocol_encapsulation_info found in
> Data_broadcast_descriptor if data_broadcast_id==0x0005 (MPE), so it
has
> to scan SDT first (don't know another way to check MAC_address_range
value).

The dvb_net interface was meant for IP-via-DVB applications, where
doing MPE (or ULE) processing in userspace would mean
- copying packets to userspace for unpacking / processing
- copying network packets back into kernel
- so that other applications can copy them back from kernel via socket
-> too much overhead

For DVB-H it might be easier to just do it all in userspace, using the
section filter API. Evaluating the data_broadcast_descriptor is the
most complicated part of it ;-), the code for handling the sections
can be copied from dvb-apps/test/test_dvr.c and dvb_net.c, plus you
need to handle the IP+UDP headers (which I think isn't too complicated
for broadcast data, but I have no clue about DVB-H ;-/).

Another way would be to extend the NET_ADD_IF API to include
MAC_address_range. However, I think the MAC from the MPE packet
should always be copied completely, just the section filter
mask (mask_normal etc. in dvb_net.c) should be changed.

HTH,
Johannes



------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb at linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

End of linux-dvb Digest, Vol 13, Issue 45
*****************************************


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com



More information about the linux-dvb mailing list