Hi, Please help me to begin programming of donau family from thoshiba. -Sajjan -----Original Message----- From: linux-dvb-bounces@xxxxxxxxxxx [mailto:linux-dvb-bounces@xxxxxxxxxxx] On Behalf Of linux-dvb-request@xxxxxxxxxxx Sent: Wednesday, February 15, 2006 6:20 PM To: linux-dvb@xxxxxxxxxxx Subject: linux-dvb Digest, Vol 13, Issue 45 Send submissions to linux-dvb@xxxxxxxxxxx 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@xxxxxxxxxxx You can reach the person managing the list at linux-dvb-owner@xxxxxxxxxxx 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@xxxxxxxxxxxxxx> Subject: Re: [PATCH] Kworld-ATSC110 To: Michael Krufky <mkrufky@xxxxxxx> Cc: Andrew Burri <andrew.burri@xxxxxxxxx>, Dwaine Garden <DwaineGarden@xxxxxxxxxx>, Linux and Kernel Video <video4linux-list@xxxxxxxxxx>, David Freeman <lists@xxxxxxxxxxxxxxxx>, LinuxDVB Mailing List <linux-dvb@xxxxxxxxxxx> Message-ID: <43F30B9A.6090809@xxxxxxxxxxxxxx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed # HG changeset patch # User cmeyers@xxxxxxxxx # 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@xxxxxxxxxxxxxx> - * 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@xxxxxxxxx> Subject: pidPMT To: linux-dvb@xxxxxxxxxxx Message-ID: <9c84df780602150316w324ea0d9i48fd3115e7b991ec@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx> Subject: Re: pidPMT To: linux-dvb@xxxxxxxxxxx Message-ID: <200602151231.36713.mws@xxxxxxxxxxx> 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@xxxxxxxxxxx> Subject: Re: DVB-T devices supporting hierarchical mode? To: linux-dvb@xxxxxxxxxxx Message-ID: <20060215115612.GC5510@xxxxxxxxxxx> 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@xxxxxxxxxxx> Subject: Re: SAA7146 DMA buffer overflow To: linux-dvb@xxxxxxxxxxx Message-ID: <20060215120004.GD5510@xxxxxxxxxxx> 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@xxxxxxx> Subject: Re: DVB-T devices supporting hierarchical mode? To: <linux-dvb@xxxxxxxxxxx> Message-ID: <7319E50A02BD477D8FC0CD03E2AC5CA0@powerstation> Content-Type: text/plain; charset="iso-8859-1" From: "Patrick Boettcher" <patrick.boettcher@xxxxxxx> > 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@xxxxxxx Berlin, Germany ------------------------------ Message: 7 Date: Wed, 15 Feb 2006 16:00:55 +0400 From: Manu Abraham <abraham.manu@xxxxxxxxx> Subject: Re: DVB-T devices supporting hierarchical mode? To: Johannes Stezenbach <js@xxxxxxxxxxx>, linux-dvb@xxxxxxxxxxx Message-ID: <43F317F7.3000005@xxxxxxxxx> 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@xxxxxxxxxxx> Subject: Re: SAA7146 DMA buffer overflow To: linux-dvb@xxxxxxxxxxx Message-ID: <20060215122155.GE5510@xxxxxxxxxxx> 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@xxxxxxxxx> Subject: Re: SAA7146 DMA buffer overflow To: Johannes Stezenbach <js@xxxxxxxxxxx>, linux-dvb@xxxxxxxxxxx Message-ID: <43F31B51.6030402@xxxxxxxxx> 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@xxxxxx> Subject: Re: SAA7146 DMA buffer overflow To: linux-dvb@xxxxxxxxxxx Message-ID: <200602151329.28092@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> Subject: Re: DVB-H, time slicing, MPE-FEC and multicast... To: linux-dvb@xxxxxxxxxxx Message-ID: <20060215124853.GF5510@xxxxxxxxxxx> 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@xxxxxxxxxxx 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 _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
