On Thu, 21 May 2009, Devin Heitmueller wrote: > em28xx: Don't let device work unless connected to a high speed USB port (grrr, dyndns addresses that are actually dynamically changing) | The em28xx basically just doesn't work at 12 Mbps. The isoc pipe needs | nearly 200 Mbps for analog support, so users would see garbage video, | and on | the DVB/ATSC side scanning is likely to work but if the user tried to | tune it | would certainly appear to have failed. | It's better to fail explicity up front and tell the user to plug into a | USB 2.0 Hi Devin, I've spent the last night trying to wrap my brane around the DVB code and how it reflects on the ability of hardware to perform PID filtering or not, thereby the expected load due to interrupts and filtering in the CPU. If my current machine is being fed a single stream from a lower-bandwidth source (not sure where the filtering to a crummy audio stream is being performed, but even the full bandwidth available from a 1,5MHz-wide chunk of spectrum is well within USB1.1), load is negligible. Multicasting the filtered data back out over a USB1.1 net adapter bumps up the interrupt load somewhat, but `top' idle time remains high. As soon as I toss a dvb-usb device into the mix, which is allegedly capable of doing internal PID filtering but which presently can't, delivering a full transport stream from a 27,5MSym/sec transponder, the interrupt level goes up, in spite of the fact that the content of interest is only a slightly less crummy audio stream of some 1/250 the full transponder datarate. However, as soon as I try to listen through the internal soundcard to one of these streams, the interrupt level goes up by nearly a factor of three, the machine drops to around only 50% idle, despite that there's no significant CPU- crunching application, and the responsiveness drops, with something comparable to stuttering observed frequently when I do something on the console. Also, the CPU temperature hovers around the point where the fan turns on. So, in spite of the individual things I do hardly being any load on the CPU in themselves, apparently the load caused by handling USB interrupts is more than additive. Bring on USB 3.0, I say... I've been spoiled by hardware which does the internal filtering, and barely causes my slower machines to break a sweat, except when I do have to handle a full TS or a higher-bandwidth HDTV stream, which it can still do, and so I decided to look at which of the different devices available today are capable of delivering a filtered TS, whether via USB or PCI -- primarily I only care for audio, at up to 320kbit/sec, that happily fits on the spare USB1.1 ports and normally doesn't cause any bother. Now, with that background, I see that the dvb-usb framework makes the hardware's ability to PID filter quite obvious, as well as the b2c2 flexcop hardware. Not all devices have this ability, apparently, and I still need to go over the code when more awake to make sense of it. Now I do know that at least some of the em28xx hardware does have the ability to selectively filter and deliver only the PIDs of interest at well within USB1 bandwidth for audio, or selected lower-quality DVB-T video. And you made mention of this some months back on the list, when asking if it was worth your time. That's the problem with these composite devices -- they are fine for such things as watching Freeview or listening to that radio, not so much for decent-quality cable (where it exists), no different to the many USB1.1 DVB-T or DVB-C devices, but they are useless for the remaining analogue sources on USB1.1. And they don't fit into the dvb-usb framework. In my dream world, the em28xx devices would determine what they can do (analogue or full transport stream) based on the USB connection, rather than simply refusing to work, provided the hardware is capable of filtering the DVB TS. But, you provide the source, so in theory I should be able to fine-tune it as I wish. (Note that my experience is based on DVB-T SD video, which so far has fit into USB1.1. I know that DVB-S H.264 HD video does not, and I would imagine that if HD ATSC is really using MPEG 2 rather than AVC video compression, it would need even more than the 16Mbit/sec I see from DVB-S, or the 10Mbit/sec expected with DVB-T2 later this year, which also wouldn't fit reliably on USB1.1 if my experience with decent quality SD in MPEG 2 is any guide on my hardware. So even hardware PID filtering is no guarantee of flawless performance, but again, the user can employ it in cases which would work. Caveat emptor. Cave canem. Carpe cavy.) Just some rambling comments there. Ignore me. barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
