Re: PAC7302 short datasheet from PixArt
On Sat, 30 Jan 2010 14:56:56 -0600 (CST) Theodore Kilgore kilg...@banach.math.auburn.edu wrote: First, I am glad that mouse-copying reproduces the accent in your name. If you can help explain how to reproduce such things by typing while using apine over an ssh connection, using a standard US keyboard, I would be glad of the explanation. My wife is Hungarian, and I am thus very sensitized to the importance of the question, how to do the accents required for writing Hungarian properly. Hello Theodore, I am also using a US keyboard and I have no problem with accents and utf-8. You must define the character encoding to 'UTF-8' and the font codeset to 'Lat2' (central Europe). The locale must be set to 'en_US.UTF-8'. Eventually, you may use the compose mechanism setting the compose character to a specific key. In Debian, this in done at installation time, but it may be changed by dpkg-reconfigure or by hand. The character encoding and the font codeset are in the file /etc/default/console-setup. The locale is defined in the file /etc/default/locale. For the keyboard, in X, I set the 'compose' keyboard option to 'rwin', i.e. the right 'ms-windows' key. This is defined in the file /etc/default/keyboard or /etc/default/console-setup: XKBOPTIONS=compose:rwin To insert a composed character, press/release left-rwin, then the accent and then the character. The compose sequences may be found in the file /etc/console-setup/compose.ISO-8859-2.inc. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PAC7302 short datasheet from PixArt
Hi, Theodore Kilgore wrote: On Sat, 30 Jan 2010, Németh Márton wrote: Hi, if anyone interested there is a brief overview datasheet about PixArt PAC7301/PAC7302 at http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf [...] Now, as to the substance of the mail above, thanks a lot. I had a bunch of the PixArt datasheets already, but I had missed that one. I would have a question, though: This datasheet gives a lot of information about pinouts on the sensor chip and such good stuff which might be useful if one were constructing a circuit board on which to put the chip. What it does not give, very unfortunately, is any information about the command set which needs to be sent across the USB connection, which in turn actuates the circuits which in turn sends something to the sensor across one of those pins. For example, to set green gain one has to do something on connector X. But how does one send a command from the computer which does something on connector X? Some other datasheets from some other companies (Omnivision, for example) do seem occasionally to provide such information. Thus, a question for you or for anyone else who reads it: Has anyone figured out any shortcuts for matching up the missing pieces of information? Probably the answer is no but I think this is the kind of question which is worth asking again on some periodic basis. I have created some notes about my experiments, but they are only based on trial-and-error. I started to created a PixArt PAC7301/PAC7302 Wiki page this morning but the communication protocol details I could found out is not yet finished. The page can be found at http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302 . I hope I'll have the time to add a section about the communication protocol details I could find out from the current gspca_pac7302 driver source code and my experiments. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CAM appears to introduce packet loss
Hi all, For quite some time now, I'm fighting with my DVB-C setup and I think I've eliminated any hardware issues that could be the origin of the issue I'm seeing. Here is my setup: Hardware: * KNC1 TV-Station DVB-C with KNC1 CineView CI (I also tried the SATELCO EasyWatch PCI (DVB-C) with SATELCO EasyWatch CI which is exactly the same hardware, just different brand) * Conax 4.00e CAM (tested in a DVB-C capable TV, works fine) * Smartcard from the DVB provider (http://www.sasag.ch, tested and properly accessible through `gnutv -cammenu`) * Dell PE700, P4 2.80GHz, 4GB RAM Software: * Mythbuntu 9.10 (karmic) * kernel 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux My DVB provider uses the free-to-view system for all channels except the local TV channel which is transmitted unencrypted. When the CAM is not inserted in the CI, I'm getting a perfect video stream ([PS/PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream]) for that unencrypted channel. dvbsnoop tells me that the stream is coming in at a fairly constant bandwidth of 4852 kbit/s. The moment I insert the CAM into the CI, the bandwidth drops to an average of 4070 kbit/s. I did analyze both streams with Peter Daniel's MPEG-2 Transport Stream packet analyser. As expected, the former stream has no continuity issues whereas the latter does. I see the continuity counter jump from 12 to 15 for example. The resulting video stream is visually distorted, I've uploaded an example at https://sites.google.com/site/msslinux/linuxmce/SFInfo.mpeg?attredirects=0d=1 to give you an idea. I get exactly the same result for any free-to-view channel which makes me suspect that the CAM/Smartcard does properly decrypt the stream. However, something appears not to be able to keep up. My DVB provider used QAM_256 which makes the bandwidth susceptible to the signal to noise ratio. The S/N ratio is at f5f5 without the CAM inserted and drops to f4f4 with the CAM inserted. I don't think that's the issue. I saw a few postings on the net about performance issues of budget cards with QAM_256 when using CI/CAM. Is that really the problem? How can I find out, i.e. further narrow down the problem? Any pointers will be appreciated. Thanks, Marc -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CAM appears to introduce packet loss
Hello, Try to check raw speed coming from demod: echo 1 /sys/module/dvb_core/parameters/dvb_demux_speedcheck and then: tail -f /var/log/messages | grep -i speed or dmesg | grep -i speed what values do you see ? this TS going through CAM. CAM has a bitrate limitation which they can pass (this depends on CAM model). On Sun, 2010-01-31 at 13:12 +0100, Marc Schmitt wrote: Hi all, For quite some time now, I'm fighting with my DVB-C setup and I think I've eliminated any hardware issues that could be the origin of the issue I'm seeing. Here is my setup: Hardware: * KNC1 TV-Station DVB-C with KNC1 CineView CI (I also tried the SATELCO EasyWatch PCI (DVB-C) with SATELCO EasyWatch CI which is exactly the same hardware, just different brand) * Conax 4.00e CAM (tested in a DVB-C capable TV, works fine) * Smartcard from the DVB provider (http://www.sasag.ch, tested and properly accessible through `gnutv -cammenu`) * Dell PE700, P4 2.80GHz, 4GB RAM Software: * Mythbuntu 9.10 (karmic) * kernel 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux My DVB provider uses the free-to-view system for all channels except the local TV channel which is transmitted unencrypted. When the CAM is not inserted in the CI, I'm getting a perfect video stream ([PS/PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 11172-2 video stream]) for that unencrypted channel. dvbsnoop tells me that the stream is coming in at a fairly constant bandwidth of 4852 kbit/s. The moment I insert the CAM into the CI, the bandwidth drops to an average of 4070 kbit/s. I did analyze both streams with Peter Daniel's MPEG-2 Transport Stream packet analyser. As expected, the former stream has no continuity issues whereas the latter does. I see the continuity counter jump from 12 to 15 for example. The resulting video stream is visually distorted, I've uploaded an example at https://sites.google.com/site/msslinux/linuxmce/SFInfo.mpeg?attredirects=0d=1 to give you an idea. I get exactly the same result for any free-to-view channel which makes me suspect that the CAM/Smartcard does properly decrypt the stream. However, something appears not to be able to keep up. My DVB provider used QAM_256 which makes the bandwidth susceptible to the signal to noise ratio. The S/N ratio is at f5f5 without the CAM inserted and drops to f4f4 with the CAM inserted. I don't think that's the issue. I saw a few postings on the net about performance issues of budget cards with QAM_256 when using CI/CAM. Is that really the problem? How can I find out, i.e. further narrow down the problem? Any pointers will be appreciated. Thanks, Marc -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: updated dvb-t/uk-StocklandHill scan file
2010/1/21 Steven Côté steven.c...@gmail.com: I have an updated scan file for uk-StocklandHill for the new settings after the digital switch over. # UK, Stockland Hill # http://www.ukfree.tv/txdetail.php?a=ST222014 T 514167000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # PSB1 T 490167000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # PSB2 #T 538167000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # PSB3 (DVB-T2) T 505833000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM4 T 481833000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM5 T 529833000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM6 Updated, thanks! Christoph I've commented out the line for PSB3, since it's not actually activated yet and when it is, it'll be carrying a DVB-T2 signal. So even once it's up and running, there's nothing out there that supports it as far as I'm aware. There are a couple other transmitters in the south-west that have switched over as well so I'll bug some people on the Devon/Cornwall LUG mailing list to see if I can gather up the rest of them. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] gspca pac7302: add USB PID range based on heuristics
Hi,
On 01/31/2010 11:19 AM, Németh Márton wrote:
Hi,
as I was reading the PixArt PAC7301/PAC7302 datasheet
(
http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf )
I recognised a little description on the schematics. This is about how to
set up the USB Product ID from range 0x2620..0x262f via hardware wires.
I had the idea that the list of supported devices could be extended with the
full
range because the System on a Chip internals will not change just because it is
configured to a different USB Product ID.
I don't know much about the maintenance implications that's why I'm very
much listening to the comments of this idea.
So, what do you think?
Seems like a good idea to me.
Regards,
Hans
Regards,
Márton Németh
---
From: Márton Némethnm...@freemail.hu
On the schematics in PixArt PAC7301/PAC7302 datasheet
(http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes
the possible product ID range 0x2620..0x262f. In this range there are some
known webcams, however, there are some PIDs with unknown or future devices.
Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is
probable that this driver will work correctly independent of the used PID.
Signed-off-by: Márton Némethnm...@freemail.hu
---
diff -r dfa82cf98a85 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sat Jan 30 20:03:02 2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 31 11:08:21 2010 +0100
@@ -96,6 +96,7 @@
u8 flags;
#define FL_HFLIP 0x01 /* mirrored by default */
#define FL_VFLIP 0x02 /* vertical flipped by default */
+#define FL_EXPERIMENTAL 0x80 /* USB IDs based on heuristic without any known
product */
u8 sof_read;
u8 autogain_ignore_frames;
@@ -1220,17 +1221,33 @@
};
/* -- module initialisation -- */
+/* Note on FL_EXPERIMENTAL:
+ * On the schematics in PixArt PAC7301/PAC7302 datasheet
+ *
(http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
+ * pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes
+ * the possible product ID range 0x2620..0x262f. In this range there are some
+ * known webcams, however, there are some PIDs with unknown or future devices.
+ * Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is
+ * probable that this driver will work correctly independent of the used PID.
+ */
static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x06f8, 0x3009)},
{USB_DEVICE(0x093a, 0x2620)},
{USB_DEVICE(0x093a, 0x2621)},
{USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2623), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2625), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2626)},
+ {USB_DEVICE(0x093a, 0x2627), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2628)},
{USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP},
{USB_DEVICE(0x093a, 0x262a)},
+ {USB_DEVICE(0x093a, 0x262b), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x262c)},
+ {USB_DEVICE(0x093a, 0x262d), .driver_info = FL_EXPERIMENTAL },
+ {USB_DEVICE(0x093a, 0x262e), .driver_info = FL_EXPERIMENTAL },
+ {USB_DEVICE(0x093a, 0x262f), .driver_info = FL_EXPERIMENTAL },
{}
};
MODULE_DEVICE_TABLE(usb, device_table);
@@ -1239,6 +1256,17 @@
static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
+ if ((u8)id-driver_info FL_EXPERIMENTAL) {
+ PDEBUG(D_ERR | D_PROBE, WARNING: USB device ID %04x:%04x is
+ not known, but based on some heuristics this driver
+ tries to handle it.,
+ id-idVendor, id-idProduct);
+ PDEBUG(D_ERR | D_PROBE, WARNING: Plase send an email to
+ linux-media@vger.kernel.org with 'lsusb -v' output,
+ the vendor and name of the product and whether the
+ device is working or not.);
+ }
+
return gspca_dev_probe(intf, id,sd_desc, sizeof(struct sd),
THIS_MODULE);
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
Am 27.01.2010 21:47, schrieb Mauro Carvalho Chehab: Stefan Ringel wrote: Hi, I have a problem with usb bulk transfer. After a while, as I scan digital channel (it found a few channel), it wrote this in the log: Jan 26 21:58:35 linux-v5dy kernel: [ 548.756585] tm6000: status != 0 I updated the tm6000_urb_received function so that I can read the Error code and it logged: Jan 27 17:41:28 linux-v5dy kernel: [ 3121.892793] tm6000: status = 0xffb5 Probablt it is this error: #define EOVERFLOW 75 /* Value too large for defined data type */ It would be good to make it display the error as a signed int. the tm6000-video error handler has some common causes for those status. In this particular case: case -EOVERFLOW: errmsg = Babble (bad cable?); break; This looks the same kind of errors I was receiving during the development of the driver: a large amount of frames are got broken, even if the device is programmed with the exact values used on the original driver. On my tests, changing the URB size were changing the position where such errors were occurring. Can you help me? Who I can calculate urb size? Take a look on tm6000-video: size = usb_maxpacket(dev-udev, pipe, usb_pipeout(pipe)); if (size dev-max_isoc_in) size = dev-max_isoc_in; It depends on the alternate interface used. The driver should select an alternate interface that is capable of receiving the entire size of a message. Maybe the tm6000 driver is missing the code that selects this size. Take a look on em28xx-core, at em28xx_set_alternate() code for an example on how this should work. The calculated size there assumes that each pixel has 16 bits, and has some magic that were experimentally tested on that device. Cheers, Mauro. I know why it's going to overflow. It's not usb pipe calculating, it's numbers of feeds that it's used. But then I cannot use more than one filter! It's bad!! Cheers Stefan Ringel -- Stefan Ringel stefan.rin...@arcor.de -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DM1105: could not attach frontend 195d:1105
On 20 января 2010 23:20:20 pau...@planar.id.au wrote:
Igor wrote:
Oh, that is wrong. It is registers addresses, Never touch this.
Let's look on that part of code:
/* GPIO's for LNB power control */
#define DM1105_LNB_MASK 0x // later in
code write it to
DM1105_GPIOCTR, all GPIO's as OUT
#define DM1105_LNB_OFF 0x0002 // later in
code write it to
DM1105_GPIOVAL, set GPIO17 to HIGH
But you have not to change this.
Right way is to write another entry in cards structure and so on.
Better leave it to me.
Regards
Igor
Thanks for all your help, I understand better now. I have moved to code
like that at the bottom. It still doesn't work, but feels a lot closer.
Before I keep playing with values, I want to check I'm on the right track.
Does it look right? Specific questions:
1. I see there is a hw_init function. Should I be using that? I put the
logic into fe_attach because there was already card-specific logic in
there. But this feels like hw initialisation.
2. Should I set the control to input or output? I'm assuming input = 1.
3. Would pin 15 be numbered from the left or right - is it 0x4, or 0x2000?
Thanks,
Paul
*** dm1105.c.old2010-01-13 16:15:00.0 +1100
--- dm1105.c2010-01-21 08:13:14.0 +1100
***
*** 51,56
--- 51,57
#define DM1105_BOARD_DVBWORLD_20021
#define DM1105_BOARD_DVBWORLD_20042
#define DM1105_BOARD_AXESS_DM05 3
+ #define DM1105_BOARD_UNBRANDED4
/* --- */
/*
***
*** 171,176
--- 172,181
#define DM05_LNB_13V 0x0002
#define DM05_LNB_18V 0x0003
+ /* GPIO's for demod reset for unbranded 195d:1105 */
+ #define UNBRANDED_DEMOD_MASK 0x8000
+ #define UNBRANDED_DEMOD_RESET 0x8000
+
static unsigned int card[] = {[0 ... 3] = UNSET };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, card type);
***
*** 206,211
--- 211,219
[DM1105_BOARD_AXESS_DM05] = {
.name = Axess/EasyTv DM05,
},
+ [DM1105_BOARD_UNBRANDED] = {
+ .name = Unbranded 195d:1105,
+ },
};
static const struct dm1105_subid dm1105_subids[] = {
***
*** 229,234
--- 237,246
.subvendor = 0x195d,
.subdevice = 0x1105,
.card = DM1105_BOARD_AXESS_DM05,
+ }, {
+ .subvendor = 0x195d,
+ .subdevice = 0x1105,
+ .card = DM1105_BOARD_UNBRANDED,
},
};
***
*** 698,703
--- 710,727
dm1105dvb-fe-ops.set_voltage =
dm1105dvb_set_voltage;
break;
+ case DM1105_BOARD_UNBRANDED:
+ printk(KERN_ERR Attaching as board_unbranded\n);
+ outl(UNBRANDED_DEMOD_MASK, dm_io_mem(DM1105_GPIOCTR));
+ outl(UNBRANDED_DEMOD_RESET , dm_io_mem(DM1105_GPIOVAL));
+ dm1105dvb-fe = dvb_attach(
+ si21xx_attach, serit_config,
+ dm1105dvb-i2c_adap);
+ if (dm1105dvb-fe)
+ dm1105dvb-fe-ops.set_voltage =
+ dm1105dvb_set_voltage;
+
+ break;
case DM1105_BOARD_DVBWORLD_2002:
case DM1105_BOARD_AXESS_DM05:
default:
Some things are missed, like keep GPIO15 high in set_voltage function.
Try attached patch against current v4l-dvb tree with modprobe option card=4
modprobe dm1105 card=4
--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
diff -r d6520e486ee6 linux/drivers/media/dvb/dm1105/dm1105.c
--- a/linux/drivers/media/dvb/dm1105/dm1105.c Sat Jan 30 01:27:34 2010 -0200
+++ b/linux/drivers/media/dvb/dm1105/dm1105.c Sun Jan 31 15:35:30 2010 +0200
@@ -52,6 +52,7 @@
#define DM1105_BOARD_DVBWORLD_2002 1
#define DM1105_BOARD_DVBWORLD_2004 2
#define DM1105_BOARD_AXESS_DM05 3
+#define DM1105_BOARD_UNBRANDED_GPIO15 4
/* --- */
/*
@@ -207,6 +208,9 @@
[DM1105_BOARD_AXESS_DM05] = {
.name = Axess/EasyTv DM05,
},
+ [DM1105_BOARD_UNBRANDED_GPIO15] = {
+ .name = Unbranded Board GPIO15,
+ },
};
static const struct dm1105_subid dm1105_subids[] = {
@@ -327,6 +331,8 @@
#define dm_setl(reg, bit) dm_andorl((reg), (bit), (bit))
#define dm_clearl(reg, bit) dm_andorl((reg), (bit), 0)
+#define DM1105_GPIO(x) (1 x)
+
static int dm1105_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg *msgs, int num)
{
@@ -441,6 +447,12 @@
u32 lnb_mask, lnb_13v, lnb_18v, lnb_off;
switch (dev-boardnr) {
+ case
Re: CAM appears to introduce packet loss
Hi there, On Sun, Jan 31, 2010 at 1:43 PM, Abylai Ospan aos...@netup.ru wrote: Hello, Try to check raw speed coming from demod: echo 1 /sys/module/dvb_core/parameters/dvb_demux_speedcheck What do I need to do to make dvb_demux_speedcheck appear in /sys/module/dvb_core/parameters? Cheers, Marc -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CAM appears to introduce packet loss
Looks like I need to build the DVB subsystem from the latest sources to get this option as it was recently added only (http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/1d956b581b02). On it. On Sun, Jan 31, 2010 at 4:07 PM, Marc Schmitt marc.schm...@gmail.com wrote: What do I need to do to make dvb_demux_speedcheck appear in /sys/module/dvb_core/parameters? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CAM appears to introduce packet loss
On Sun, 2010-01-31 at 16:23 +0100, Marc Schmitt wrote: Looks like I need to build the DVB subsystem from the latest sources to get this option as it was recently added only (http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/1d956b581b02). On it. yes. this option should show raw bitrate coming from demod and which passed to CI. In user level you may be measuring bitrate after software PID filtering ( may be not ). -- Abylai Ospan aos...@netup.ru NetUP Inc. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CAM appears to introduce packet loss
Compiling from source made me stumble across http://www.mail-archive.com/ubuntu-devel-disc...@lists.ubuntu.com/msg09422.html I just left out the firedtv driver as recommended. I'm getting the following kernel output after enabling dvb_demux_speedcheck: [ 330.366115] TS speed 40350 Kbits/sec [ 332.197693] TS speed 40085 Kbits/sec [ 334.011856] TS speed 40528 Kbits/sec [ 335.843466] TS speed 40107 Kbits/sec [ 337.665411] TS speed 40261 Kbits/sec [ 339.496959] TS speed 40107 Kbits/sec [ 341.318289] TS speed 40350 Kbits/sec Do you think the CI/CAM can not handle that? On Sun, Jan 31, 2010 at 4:32 PM, Abylai Ospan aos...@netup.ru wrote: On Sun, 2010-01-31 at 16:23 +0100, Marc Schmitt wrote: Looks like I need to build the DVB subsystem from the latest sources to get this option as it was recently added only (http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/1d956b581b02). On it. yes. this option should show raw bitrate coming from demod and which passed to CI. In user level you may be measuring bitrate after software PID filtering ( may be not ). -- Abylai Ospan aos...@netup.ru NetUP Inc. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CAM appears to introduce packet loss
On Sun, 2010-01-31 at 17:25 +0100, Marc Schmitt wrote: Compiling from source made me stumble across http://www.mail-archive.com/ubuntu-devel-disc...@lists.ubuntu.com/msg09422.html I just left out the firedtv driver as recommended. I'm getting the following kernel output after enabling dvb_demux_speedcheck: [ 330.366115] TS speed 40350 Kbits/sec [ 332.197693] TS speed 40085 Kbits/sec [ 334.011856] TS speed 40528 Kbits/sec [ 335.843466] TS speed 40107 Kbits/sec [ 337.665411] TS speed 40261 Kbits/sec [ 339.496959] TS speed 40107 Kbits/sec [ 341.318289] TS speed 40350 Kbits/sec Do you think the CI/CAM can not handle that? 40 Mbit/sec is high bitrate for some CAM's. You can: 1. Try to contact with CAM vendor and check maximum bitrate which can be passed throught this CAM 2. Try to find reception card with hardware PID filtering and pass only interesting PID's throught CAM. Bitrate should be equal to bitrate of one channel - aprox. 4-5 mbit/sec ( not 40 mbit/sec). 3.may be some fixes can be made on TS output from demod. Demod's usually has tunable TS output timings/forms. You should check TS clock by oscilloscope and then try to change TS timings/forms in demod. -- Abylai Ospan aos...@netup.ru NetUP Inc. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kaffeine 1.0-pre3 released
See the announcement at http://kaffeine.kde.org/?q=node/26 Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CAM appears to introduce packet loss
On Sun, Jan 31, 2010 at 5:31 PM, Abylai Ospan aos...@netup.ru wrote: On Sun, 2010-01-31 at 17:25 +0100, Marc Schmitt wrote: Compiling from source made me stumble across http://www.mail-archive.com/ubuntu-devel-disc...@lists.ubuntu.com/msg09422.html I just left out the firedtv driver as recommended. I'm getting the following kernel output after enabling dvb_demux_speedcheck: [ 330.366115] TS speed 40350 Kbits/sec [ 332.197693] TS speed 40085 Kbits/sec [ 334.011856] TS speed 40528 Kbits/sec [ 335.843466] TS speed 40107 Kbits/sec [ 337.665411] TS speed 40261 Kbits/sec [ 339.496959] TS speed 40107 Kbits/sec [ 341.318289] TS speed 40350 Kbits/sec Do you think the CI/CAM can not handle that? 40 Mbit/sec is high bitrate for some CAM's. You can: 1. Try to contact with CAM vendor and check maximum bitrate which can be passed throught this CAM I tried that CAM in a TV with DVB-C support. The image was perfect so I suspect that the CAM itself can handle it unless the TV did HW PID filtering before sending the stream to the CAM, as you point out below... Is that to be expected? 2. Try to find reception card with hardware PID filtering and pass only interesting PID's throught CAM. Bitrate should be equal to bitrate of one channel - aprox. 4-5 mbit/sec ( not 40 mbit/sec). Do you have a recommendation for such a card? Would it be possible to do the filtering in software somehow? 3.may be some fixes can be made on TS output from demod. Demod's usually has tunable TS output timings/forms. You should check TS clock by oscilloscope and then try to change TS timings/forms in demod. Unfortunately, I don't have the necessary equipment/knowledge to do this. :( I'd assume the DVB provider could give me the TS clock? But then I'm at bit at a loss with change TS timings/forms in demod. What exactly are you referring to by demod. Thanks, Marc -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 0979:0280 :-) (fwd)
This is the first of two mails I am sending. The problem is about a jeilinj camera which is not working. The second mail indicates that the problem seems to have been in a certain external USB hub, through which the camera was connected. So, one might say the problem is fixed but in case there is need to dig more deeply I am reporting this. I do find the reported error to be very strange, namely (a typical specimen) Jan 28 17:56:18 linux kernel: [26920.452427] gspca: frame overflow 77885 77824 Please see the next mail, too. Theodore Kilgore -- Forwarded message -- Date: Fri, 29 Jan 2010 09:06:26 +0100 From: Matthias Huber matthias.hu...@wollishausen.de To: Theodore Kilgore kilg...@banach.math.auburn.edu Subject: Re: 0979:0280 :-) 29.01.2010 02:24, Theodore Kilgore : On Thu, 28 Jan 2010, Matthias Huber wrote: 28.01.2010 20:03, Theodore Kilgore : On Thu, 28 Jan 2010, Matthias Huber wrote: 28.01.2010 18:36, Theodore Kilgore : On Thu, 28 Jan 2010, Matthias Huber wrote: Well, I guess one needs some more information. If jlj_startup() is returning 0 then that is not exactly an error. What else is going on? Theodore Kilgore Now i have a few unsuccessful tries: (problem seems to be here the frame overflow) Jan 28 17:54:48 linux kernel: [26830.766387] jeilinj: deregistered Jan 28 17:54:56 linux kernel: [26838.306693] gspca: probing 0979:0280 Jan 28 17:54:56 linux kernel: [26838.306701] jeilinj: JEILINJ camera detected (vid/pid 0x0979:0x0280) Jan 28 17:54:56 linux kernel: [26838.306791] gspca: video1 created Jan 28 17:54:56 linux kernel: [26838.306808] usbcore: registered new interface driver jeilinj Jan 28 17:54:56 linux kernel: [26838.306812] jeilinj: registered Jan 28 17:55:14 linux matthias: first try Jan 28 17:55:28 linux kernel: [26870.892905] jeilinj: jlj_start retval is 0 Jan 28 17:55:55 linux matthias: result: try was unsuccessful, window stayed empty Jan 28 17:56:16 linux kernel: [26918.931515] jeilinj: jlj_start retval is 0 Jan 28 17:56:17 linux kernel: [26919.192148] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.332527] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.496030] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.657412] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.815662] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.975667] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26920.132793] gspca: frame overflow 77885 77824 Jan 28 17:56:18 linux kernel: [26920.293049] gspca: frame overflow 77885 77824 Jan 28 17:56:18 linux kernel: [26920.452427] gspca: frame overflow 77885 77824 Jan 28 17:56:18 linux kernel: [26920.612805] gspca: frame overflow 77885 77824 Jan 28 17:56:18 linux kernel: [26920.774057] gspca: frame overflow 77885 77824 Jan 28 17:56:24 linux matthias: result: second try was unsuccessful, window stayed empty Jan 28 17:56:35 linux matthias: try three Jan 28 17:56:37 linux kernel: [26939.307986] jeilinj: jlj_start retval is 0 Jan 28 17:56:45 linux matthias: result: try was unsuccessful, window stayed empty Jan 28 17:56:47 linux kernel: [26949.358593] jeilinj: jlj_start retval is 0 Jan 28 17:56:47 linux kernel: [26949.601474] gspca: frame overflow 77885 77824 Jan 28 17:56:47 linux kernel: [26949.739477] gspca: frame overflow 77885 77824 Jan 28 17:56:47 linux kernel: [26949.891633] gspca: frame overflow 77885 77824 Jan 28 17:56:47 linux kernel: [26950.048487] gspca: frame overflow 77885 77824 Jan 28 17:56:48 linux kernel: [26950.208738] gspca: frame overflow 77885 77824 Jan 28 17:56:48 linux kernel: [26950.368497] gspca: frame overflow 77885 77824 Jan 28 17:56:48 linux kernel: [26950.528500] gspca: frame overflow 77885 77824 Jan 28 17:56:50 linux matthias: result: try was unsuccessful, window stayed empty Jan 28 17:56:52 linux kernel: [26954.171578] jeilinj: jlj_start retval is 0 Jan 28 17:57:18 linux matthias: try from user matz Jan 28 17:57:24 linux kernel: [26987.147964] jeilinj: jlj_start retval is 0 Jan 28 17:57:25 linux kernel: [26987.374362] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26987.512100] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26987.650728] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26987.803980] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26987.965110] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26988.123614] gspca: frame overflow 77885 77824 Jan 28 17:57:26 linux kernel: [26988.284368] gspca: frame overflow 77885 77824 Jan 28 17:57:26 linux kernel: [26988.443495] gspca: frame overflow 77885 77824 Jan 28 17:57:26 linux kernel: [26988.607500] gspca: frame overflow 77885 77824 Jan 28 17:58:44 linux kernel: [27066.439232] usbcore: deregistering interface driver jeilinj Jan 28 17:58:44 linux
Re: solved // more debug from 979:280 (fwd)
For further background see my previous message. This message explains that the problem with device 0x0979:0x0280 which Matthias was having appears to be related to running the camera through his USB 2.0 hub (details below). I should also mention that I have a similar camera myself (same ID) and so does Andy Walls. I never had any such problems with my camera, but I do not even own any external USB hub. Theodore Kilgore -- Forwarded message -- Date: Fri, 29 Jan 2010 17:49:39 +0100 From: Matthias Huber matthias.hu...@wollishausen.de To: Theodore Kilgore kilg...@banach.math.auburn.edu Cc: Andy Walls awa...@radix.net Subject: Re: solved // more debug from 979:280 29.01.2010 17:32, Theodore Kilgore : Andy, Matthias found the solution, but it seems to me that the problems involved might possibly need more attention from some quarter, not necessarily from linux-media, but possibly from linux-usb: Briefly, Matthias is saying that the problem arises when he plugs the camera in on his USB 2.0 port. and now i can say that it is this special usb2.0 hub. on the market the vendor calles itself digitus, but i think this is a german vendor. i tried another super-cheap hub of a cube with time, temperature, and changing colors and holder for pens, and this hub works ok with the camera. because of that it seems, that the problem is hub-specific. the working hub calls: Bus 003 Device 010: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x05e3 Genesys Logic, Inc. idProduct 0x0608 USB-2.0 4-Port HUB bcdDevice9.01 iManufacturer 0 iProduct1 USB2.0 Hub iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x00e0 Ganged power switching Ganged overcurrent protection Port indicators bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent100 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0xff Hub Port Status: Port 1: .0100 power Port 2: .0100 power Port 3: .0103 power enable connect Port 4: .0100 power Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0001 Self Powered My impression is that, at least in theory, there is not supposed to be any problem, even so. Of course, the problem could be one which was present in 2.6.28 and has been fixed now that we have 2.6.32. What do you think? Theodore Kilgore On Fri, 29 Jan 2010, Matthias Huber wrote: Good Morning (?) Theodore, today i made some tries again with the camera: the first resulted in a big crash (system hung). i tried magic sysrq, but only with partial success. the error on the first try was: it created video0, which is my dvb-card in the second try, one sees the misunderstanding between jeilinj and gspca_main about the buffer size. another successful try shows correct parameters for frame size. and the solution was: (i remembered from our last communicaiton about the camera) *** not to use my usb-2.0 hub, which seems to work buggy. or at least the camera on it works buggy. (maybe a timing problem ?) this hub often has the problem, that after some connects / disconnects, one has to power off and on for enumerating again plugged devices on it. so i don't know, if this is a general problem in gspca-timing or not. the usb-hub with the problem is: m...@linux:~$ lsusb -v Bus 001 Device
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jan 31 19:00:05 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14075:d6520e486ee6 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-rc5-armv5-davinci: OK linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-rc5-x86_64: WARNINGS spec: OK sparse (linux-2.6.32.6): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Twinhan dtv 3030 mantis dvb-t
Hi, I'm trying to use this tv-card with ubuntu 9.10. I've installed Manu's drivers from http://jusst.de/hg/mantis-v4l-dvb/ and did modprobe mantis which resulted in the following in /var/log/messages Jan 31 20:57:40 niklas-desktop kernel: [ 179.000227] Mantis :05:02.0: PCI INT A - GSI 23 (level, low) - IRQ 23 Jan 31 20:57:40 niklas-desktop kernel: [ 179.001234] DVB: registering new adapter (Mantis DVB adapter) Jan 31 20:57:41 niklas-desktop kernel: [ 179.672664] *pde = bac3e067 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672676] Modules linked in: mantis(+) mantis_core ir_common ir_core tda665x lnbp21 mb86a16 stb6100 tda10021 tda10023 zl10353 stb0899 stv0299 dvb_core joydev hidp binfmt_misc ppdev bridge stp bnep arc4 ecb snd_hda_codec_analog rtl8187 mac80211 led_class eeprom_93cx6 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm usblp snd_seq_dummy iptable_filter ip_tables x_tables btusb cfg80211 asus_atk0110 lirc_imon lirc_dev lp parport snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc nvidia(P) usbhid skge ohci1394 ieee1394 sky2 intel_agp agpgart Jan 31 20:57:41 niklas-desktop kernel: [ 179.672743] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672748] Pid: 2768, comm: modprobe Tainted: P (2.6.31-17-generic #54-Ubuntu) System Product Name Jan 31 20:57:41 niklas-desktop kernel: [ 179.672752] EIP: 0060:[f8517480] EFLAGS: 00010292 CPU: 1 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672761] EIP is at dvb_unregister_frontend+0x10/0xe0 [dvb_core] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672764] EAX: EBX: f398f800 ECX: f6a51cc0 EDX: Jan 31 20:57:41 niklas-desktop kernel: [ 179.672767] ESI: EDI: f398f9fc EBP: f4983dec ESP: f4983dc8 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672771] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672779] f4983dec f851c07e f398f800 f398f9fc f4983dec f398f800 f398f800 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672797] 0 f4983e2c f85955d5 f70fc858 f8599b50 f398f800 f398fc70 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672804] 0 f398f848 f398fc64 f398fc58 f85a9500 f398fbfc f398f9ac f398f800 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672820] [f851c07e] ? dvb_net_release+0x1e/0xb0 [dvb_core] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672827] [f85955d5] ? mantis_dvb_init+0x398/0x3de [mantis_core] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672833] [f85a6606] ? mantis_pci_probe+0x1d7/0x2f8 [mantis] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672839] [c03285ae] ? local_pci_probe+0xe/0x10 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672843] [c0329330] ? pci_device_probe+0x60/0x80 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672848] [c03a2e30] ? really_probe+0x50/0x140 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672852] [c0570cea] ? _spin_lock_irqsave+0x2a/0x40 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672855] [c03a2f39] ? driver_probe_device+0x19/0x20 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672859] [c03a2fb9] ? __driver_attach+0x79/0x80 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672862] [c03a2488] ? bus_for_each_dev+0x48/0x70 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672866] [c03a2cf9] ? driver_attach+0x19/0x20 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672869] [c03a2f40] ? __driver_attach+0x0/0x80 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672872] [c03a26df] ? bus_add_driver+0xbf/0x2a0 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672876] [c0329270] ? pci_device_remove+0x0/0x40 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672879] [c03a3245] ? driver_register+0x65/0x120 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672883] [c0329550] ? __pci_register_driver+0x40/0xb0 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672887] [f85a642d] ? mantis_init+0x17/0x19 [mantis] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672890] [c010112c] ? do_one_initcall+0x2c/0x190 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672894] [f85a6416] ? mantis_init+0x0/0x19 [mantis] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672899] [c0173711] ? sys_init_module+0xb1/0x1f0 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672903] [c01e83ed] ? sys_write+0x3d/0x70 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672906] [c010336c] ? syscall_call+0x7/0xb Jan 31 20:57:41 niklas-desktop kernel: [ 179.672961] ---[ end trace 035b3cc151b9cf1a ]--- I can't even get the drivers from http://jusst.de/hg/mantis/ to compile: Kernel build directory is /lib/modules/2.6.31-17-generic/build make -C /lib/modules/2.6.31-17-generic/build SUBDIRS=/home/niklas/Hämtningar/mantis-5292a47772ad/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.31-17-generic' CC [M] /home/niklas/Hämtningar/mantis-5292a47772ad/v4l/tuner-xc2028.o In file included from /home/niklas/Hämtningar/mantis-5292a47772ad/v4l/tuner-xc2028.h:10, from
Re: CAM appears to introduce packet loss
You can: 1. Try to contact with CAM vendor and check maximum bitrate which can be passed throught this CAM I tried that CAM in a TV with DVB-C support. The image was perfect so I suspect that the CAM itself can handle it unless the TV did HW PID filtering before sending the stream to the CAM, as you point out below... Is that to be expected? Depends on TV vendor. But it's not impossible. 2. Try to find reception card with hardware PID filtering and pass only interesting PID's throught CAM. Bitrate should be equal to bitrate of one channel - aprox. 4-5 mbit/sec ( not 40 mbit/sec). Do you have a recommendation for such a card? try to search on linuxtv wiki. Would it be possible to do the filtering in software somehow? usually TS going from demod to CI directly without any programmable IC between. in this case you can't do PID filtering nor SW nor HW. 3.may be some fixes can be made on TS output from demod. Demod's usually has tunable TS output timings/forms. You should check TS clock by oscilloscope and then try to change TS timings/forms in demod. Unfortunately, I don't have the necessary equipment/knowledge to do this. :( I'd assume the DVB provider could give me the TS clock? But then I'm at bit at a loss with change TS timings/forms in demod. What exactly are you referring to by demod. demod is IC doing demodulation of signal and producing Transport Stream. In your card seems Philips TDA10021 is used as DVB-C demodulator. -- Abylai Ospan aos...@netup.ru NetUP Inc. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Twinhan dtv 3030 mantis dvb-t
Thank you for the quick answer! I downloaded http://linuxtv.org/hg/v4l-dvb/archive/tip.tar.bz2 and did: make release VER=`uname -r` make sudo make install I had to disable firedtv as well, but that is another (ubuntu related) known issue. Unfortunately it's not working and I get the same errors. Is there any way to verify that I'm using the latest driver? Are there any dependencies I'm not aware of? /var/log/messages: Feb 1 00:43:30 niklas-desktop kernel: [ 10.513329] *pde = Feb 1 00:43:30 niklas-desktop kernel: [ 10.513338] Modules linked in: snd_hda_codec_analog arc4 ecb mantis(+) mantis_core ir_common ir_core tda665x lnbp21 mb86a16 stb6100 tda10021 tda10023 zl10353 stb0899 stv0299 dvb_core rtl8187 mac80211 led_class eeprom_93cx6 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq iptable_filter cfg80211 lp parport snd_timer snd_seq_device ip_tables x_tables lirc_imon lirc_dev btusb usblp asus_atk0110 nvidia(P) snd soundcore snd_page_alloc ohci1394 skge ieee1394 usbhid sky2 intel_agp agpgart Feb 1 00:43:30 niklas-desktop kernel: [ 10.513386] Feb 1 00:43:30 niklas-desktop kernel: [ 10.513390] Pid: 861, comm: modprobe Tainted: P (2.6.31-17-generic #54-Ubuntu) System Product Name Feb 1 00:43:30 niklas-desktop kernel: [ 10.513393] EIP: 0060:[f84e9480] EFLAGS: 00010292 CPU: 0 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513400] EIP is at dvb_unregister_frontend+0x10/0xe0 [dvb_core] Feb 1 00:43:30 niklas-desktop kernel: [ 10.513402] EAX: EBX: f616b000 ECX: f6391d40 EDX: Feb 1 00:43:30 niklas-desktop kernel: [ 10.513405] ESI: EDI: f616b1fc EBP: f61abdec ESP: f61abdc8 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513407] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513413] f61abdec f84ee01e f616b000 f616b1fc f61abdec f616b000 f616b000 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513420] 0 f61abe2c f859b4dc f70fc858 f859fb90 f616b000 f616b470 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513427] 0 f616b048 f616b464 f616b458 f85af4e0 f616b3fc f616b1ac f616b000 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513444] [f84ee01e] ? dvb_net_release+0x1e/0xb0 [dvb_core] Feb 1 00:43:30 niklas-desktop kernel: [ 10.513452] [f859b4dc] ? mantis_dvb_init+0x398/0x3de [mantis_core] Feb 1 00:43:30 niklas-desktop kernel: [ 10.513457] [f85ac606] ? mantis_pci_probe+0x1d7/0x2f8 [mantis] Feb 1 00:43:30 niklas-desktop kernel: [ 10.513464] [c03285ae] ? local_pci_probe+0xe/0x10 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513468] [c0329330] ? pci_device_probe+0x60/0x80 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513474] [c03a2e30] ? really_probe+0x50/0x140 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513479] [c0570cea] ? _spin_lock_irqsave+0x2a/0x40 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513483] [c03a2f39] ? driver_probe_device+0x19/0x20 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513486] [c03a2fb9] ? __driver_attach+0x79/0x80 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513490] [c03a2488] ? bus_for_each_dev+0x48/0x70 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513493] [c03a2cf9] ? driver_attach+0x19/0x20 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513497] [c03a2f40] ? __driver_attach+0x0/0x80 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513501] [c03a26df] ? bus_add_driver+0xbf/0x2a0 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513504] [c0329270] ? pci_device_remove+0x0/0x40 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513508] [c03a3245] ? driver_register+0x65/0x120 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513511] [c0329550] ? __pci_register_driver+0x40/0xb0 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513516] [f85ac42d] ? mantis_init+0x17/0x19 [mantis] Feb 1 00:43:30 niklas-desktop kernel: [ 10.513519] [c010112c] ? do_one_initcall+0x2c/0x190 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513523] [f85ac416] ? mantis_init+0x0/0x19 [mantis] Feb 1 00:43:30 niklas-desktop kernel: [ 10.513528] [c0173711] ? sys_init_module+0xb1/0x1f0 Feb 1 00:43:30 niklas-desktop kernel: [ 10.513532] [c010336c] ? syscall_call+0x7/0xb Feb 1 00:43:30 niklas-desktop kernel: [ 10.513612] ---[ end trace fbdc5992aad42451 ]--- lspci: 05:02.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: Twinhan Technology Co. Ltd Device 0024 Flags: bus master, medium devsel, latency 64, IRQ 23 Memory at dfeff000 (32-bit, prefetchable) [size=4K] Kernel driver in use: Mantis Med vänliga hälsningar Niklas Claesson 2010/1/31 Manu Abraham abraham.m...@gmail.com: Hi, The mantis driver has been merged. So you can as well try out the latest changes from http://linuxtv.org/hg/v4l-dvb as well. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe
