On Fri, May 22, 2009 at 9:48 PM, BOUWSMA Barry <freebeer.bouw...@gmail.com> wrote: > 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 >
Hello Barry, The dvb core does have infrastructure to support hardware pid filtering. I don't know too much about the DVB standards, but I know that ATSC is 19.39MB/s and QAM as deployed in US cable systems is about twice that. Neither would fit in a 12Mbps stream. If I knew of a em2874/em2884 device that also didn't use the drx, I would consider it worthwhile to spend the time to do the work for the hardware filtering. Until that happens though, I've got better things to spend my time on. Now, you're posting this in response to a PULL request where I am blocking 12Mbps ports on em28xx and au0828. Bear in mind that the PID filtering is separate from that. You can always use hardware PID filtering in conjunction with USB 2.0. The fix is really in response to users with older PCs trying to capture a full ATSC stream (or analog capture), and being *very* confused. If there is really a concern that we should be supporting USB 1.1 ports, even though USB 2.0 has been around for almost ten years, I guess I can add a modprobe option to allow the user to override the check. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
