[PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes-2
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes-2 for the following: em28xx: Don't let device work unless connected to a high speed USB port au0828: Don't let device work unless connected to a high speed USB port em28xx: Add support for the K-World 2800d tuner-core: fix warning introduced when cleaning up xc5000 init routine em28xx: provide module option to disable USB speed check au0828: provide module option to disable USB speed check The series changes the comment as you requested, adds a routine to allow advanced users to override the bus speed check (at their own risk), and removes the patch related to the loading of the em28xx-audio if no audio present. I will need to revisit that code and come up with the correct patch that works even with i2s audio. Thanks, 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
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Wed, May 27, 2009 at 9:00 AM, Mauro Carvalho Chehab wrote: > Em Thu, 21 May 2009 22:26:35 -0400 > Devin Heitmueller escreveu: > >> Hello Mauro, >> >> Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for >> the following: >> >> em28xx: don't create the audio device if no onboard audio processor > > I don't think that this patch is right. > > There are some devices that are equipped with non ac97 audio processors, for > example the ones with msp34xx. Those devices have digital audio. I'm not sure > if > they work with em28xx-audio or with snd-usb-audio. So, the safest way is not > to > deny the load of em28xx-audio. Mauro, The code does take into account devices that provide I2S audio. However, I think you may be correct that if I2S audio is configured, the driver will not load. I think I'm going to need to rework the patch a bit. The correct behavior should be that the em28xx-audio driver should only be loaded if vendor audio is required (either AC97 or I2S), and it appears that my logic didn't accomplish that [I confused an "if()" for an "else if()"]. 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
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Wed, May 27, 2009 at 8:54 AM, Mauro Carvalho Chehab wrote: > Em Sat, 23 May 2009 03:48:21 +0200 (CEST) > BOUWSMA Barry escreveu: > >> 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. > > There are some cases where USB 1.1 is fine, being the most trivial example the > FM radio reception. > > The trouble with em28xx and 1.5 Mbps or 12 Mbps is that, currently, em28xx > doesn't limit its usage to fit into lower bus bandwidth. > > So, it would accept users call to provide non-compressed analog TV, at maximum > resolution and at 30 fps even without having enough bandwidth at USB. It won't > even generate a warning at dmesg. The problem will be noticed only due to the > video garbage. > > So, the right solution to support 12 Mbps (or even 1.5 Mbps) would be to have > some routines there to estimate the maximum bus bandwidth and to deny requests > that would exceed it. Another alternative would be to have a whitelist for > those devices that works fine with usb 1.1 (for example ISDB-T 1 seg and DVB-H > devices without analog). > > I don't think it would be a worthy trial to do such patch (since USB 3.0 is > arriving the market and USB 1.1 is an old standard), but if someone write such > patch, we may later revert this one. > > While we don't have this, it is better to just deny rates lower than 480 Mbps. > > That's said, the reasons given at the patch for nacking USB low speed (on both > the driver and the patch descriptions) are not ok, since the problem is not > that em28xx only works with usb 2.0 or that all DVB streams will fail. > > Instead of: > > + /* Make sure they are connected to a USB 2.0 port. If the device is > + connected to a USB 1.1 port at 12 Mbps, things like dvb scanning > + will work but tuning will fail, and attempts to watch analog will > + show garbage video. Better to just fail explicitly... */ > > So, it should be saying, instead: > > /* > * Make sure we have 480 Mbps of bandwidth, otherwise things like > * video stream wouldn't likely work, since 12 Mbps is generally > * not enough even for most Digital TV streams. > */ > > Devin, > > Could you please change the comment and the patch description and resubmit the > pull request? > > > > Cheers, > Mauro > Hello Mauro, I certainly agree that when we start supporting ISDB-T, we may need to revisit the logic (if we actually care about supporting 12Mbps). I will update the comment and issue a new PULL request, as you proposed. Thanks, 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
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
Em Sat, 23 May 2009 03:48:21 +0200 (CEST) BOUWSMA Barry escreveu: > 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. There are some cases where USB 1.1 is fine, being the most trivial example the FM radio reception. The trouble with em28xx and 1.5 Mbps or 12 Mbps is that, currently, em28xx doesn't limit its usage to fit into lower bus bandwidth. So, it would accept users call to provide non-compressed analog TV, at maximum resolution and at 30 fps even without having enough bandwidth at USB. It won't even generate a warning at dmesg. The problem will be noticed only due to the video garbage. So, the right solution to support 12 Mbps (or even 1.5 Mbps) would be to have some routines there to estimate the maximum bus bandwidth and to deny requests that would exceed it. Another alternative would be to have a whitelist for those devices that works fine with usb 1.1 (for example ISDB-T 1 seg and DVB-H devices without analog). I don't think it would be a worthy trial to do such patch (since USB 3.0 is arriving the market and USB 1.1 is an old standard), but if someone write such patch, we may later revert this one. While we don't have this, it is better to just deny rates lower than 480 Mbps. That's said, the reasons given at the patch for nacking USB low speed (on both the driver and the patch descriptions) are not ok, since the problem is not that em28xx only works with usb 2.0 or that all DVB streams will fail. Instead of: + /* Make sure they are connected to a USB 2.0 port. If the device is + connected to a USB 1.1 port at 12 Mbps, things like dvb scanning + will work but tuning will fail, and attempts to watch analog will + show garbage video. Better to just fail explicitly... */ So, it should be saying, instead: /* * Make sure we have 480 Mbps of bandwidth, otherwise things like * video stream wouldn't likely work, since 12 Mbps is generally * not enough even for most Digital TV streams. */ Devin, Could you please change the comment and the patch description and resubmit the pull request? Cheers, Mauro -- 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: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
Em Thu, 21 May 2009 22:26:35 -0400 Devin Heitmueller escreveu: > Hello Mauro, > > Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for > the following: > > em28xx: don't create the audio device if no onboard audio processor I don't think that this patch is right. There are some devices that are equipped with non ac97 audio processors, for example the ones with msp34xx. Those devices have digital audio. I'm not sure if they work with em28xx-audio or with snd-usb-audio. So, the safest way is not to deny the load of em28xx-audio. Cheers, Mauro -- 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: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Sat, May 23, 2009 at 4:07 PM, Markus Rechberger wrote: > On Sat, May 23, 2009 at 4:00 PM, BOUWSMA Barry > wrote: >> Moin Devin, thanks for the reply. >> >> On Fri, 22 May 2009, Devin Heitmueller wrote: >> >> [cut my drivel] >>> The dvb core does have infrastructure to support hardware pid >>> filtering. >> >> If you don't mind, and this is a serious question, could you >> give me some keywords to look for? I've come up with some >> obvious winners in dvb-usb with uppercase FILTER, but lowercase >> filter didn't give me any serious Aha! moments for other >> devices, in an attempt to determine device capabilities by >> simple code reading. Thanks! (And I'll gladly eat my shoes >> when it turns out to be something stupendously simple, as I'm >> no code-reader) >> >> >>> 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. >> >> Bleedin' 'ell, I knew things were bigger in Texas, but I >> didn't know they wuz that big! ;-) Just kidding, I know >> what you meant... >> >> Just for background, the overall bandwidth of DVB-T will be >> determined by choice of frequency at one transmitter site or >> whether shared by several and how far apart, as well as other >> factors that are basically able to be simplified as a tradeoff >> of reliability over distance against bandwidth. There's a wide >> variance here, but in even the most widely-reaching Single- >> Frequency-Networks that are meant to be received at large >> distances under difficult conditions, where available overall >> bandwidth is less than that of a single transmitter serving >> a local area, said overall bandwidth is generally going to >> exceed that which I've achieved from USB1.1. A certain DVB-H >> network with 1/2 FEC and 1/4 guard interval drops below >> 10 000kbit/sec but isn't likely to represent common usage >> for broadcast TV services. >> >> On the other hand, the individual services within each >> multiplex will generally be well within the USB1.1 available >> bandwidth, provided hardware PID filtering can be applied. >> Bitrates for television services can be from some 2Mbit/sec >> up to over 5Mbit/sec at times, depending on whether that >> service has been configured to get the lion's share of the >> bandwidth at the expense of the other services with rates >> dynamically varying based on picture content thanks to >> statistical multiplexing. >> >> In any case, while I've been able to watch average-per-second >> bitrates of different PIDs on different multiplexes, I've >> just realized that I haven't actually used any DVB-T >> receivers for any length of time on a USB1.1 port to see >> if instantaneous bursts will exceed that bandwidth, as is >> the case for quality services delivered via DVB-S and USB1.1. >> >> But I've read that it's the exception rather than the rule >> that a particular service will be privileged to get more >> than its proportional share of overall bandwidth, to be free >> of most artifacts and be watchable, so I'd be willing to posit >> that a full service (video, multiple audio, PMT, teletext, and >> the like) will fit onto USB1.1. >> >> So much for background. Anyone still bothering to read? >> >> >>> 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. >> >> No argument there. I had a look through Herr Rechberger's >> code (simply because it's had a wider variety of included >> hardware, not to say anything about the linuxtv code) to get >> a feel for how many devices were exclusively DVB-T, or at >> least didn't include some baseband video. >> >> It appears that a group of EM2870 devices (may well be the >> 2874 in reality, I just numbly scan the code) are limited >> to DVB-T, including Terratec Cinergy T XS, Pinnacle PCTV DVB-T, >> a couple KWorld 35xU DVB-T devices, and a Compro VideoMate. >> Apart from that, all remaining devices (apart from DMB and >> the like) appear to have the ability to handle analogue >> signals, and need USB2.0 to reach full potential. >> >> >> >>> 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. >> >> I actually have dredged from the dank dingy decaying dumpster >> depths or doom a machine fast enough to decode and display SD >> images, even without XVMC MPEG-2 acceleration, after replacing >> most of the electrolytic condensers/capacitors on the board, yet >> the internal USB ports are again 1.1. Gi
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Sat, May 23, 2009 at 4:00 PM, BOUWSMA Barry wrote: > Moin Devin, thanks for the reply. > > On Fri, 22 May 2009, Devin Heitmueller wrote: > > [cut my drivel] >> The dvb core does have infrastructure to support hardware pid >> filtering. > > If you don't mind, and this is a serious question, could you > give me some keywords to look for? I've come up with some > obvious winners in dvb-usb with uppercase FILTER, but lowercase > filter didn't give me any serious Aha! moments for other > devices, in an attempt to determine device capabilities by > simple code reading. Thanks! (And I'll gladly eat my shoes > when it turns out to be something stupendously simple, as I'm > no code-reader) > > >> 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. > > Bleedin' 'ell, I knew things were bigger in Texas, but I > didn't know they wuz that big! ;-) Just kidding, I know > what you meant... > > Just for background, the overall bandwidth of DVB-T will be > determined by choice of frequency at one transmitter site or > whether shared by several and how far apart, as well as other > factors that are basically able to be simplified as a tradeoff > of reliability over distance against bandwidth. There's a wide > variance here, but in even the most widely-reaching Single- > Frequency-Networks that are meant to be received at large > distances under difficult conditions, where available overall > bandwidth is less than that of a single transmitter serving > a local area, said overall bandwidth is generally going to > exceed that which I've achieved from USB1.1. A certain DVB-H > network with 1/2 FEC and 1/4 guard interval drops below > 10 000kbit/sec but isn't likely to represent common usage > for broadcast TV services. > > On the other hand, the individual services within each > multiplex will generally be well within the USB1.1 available > bandwidth, provided hardware PID filtering can be applied. > Bitrates for television services can be from some 2Mbit/sec > up to over 5Mbit/sec at times, depending on whether that > service has been configured to get the lion's share of the > bandwidth at the expense of the other services with rates > dynamically varying based on picture content thanks to > statistical multiplexing. > > In any case, while I've been able to watch average-per-second > bitrates of different PIDs on different multiplexes, I've > just realized that I haven't actually used any DVB-T > receivers for any length of time on a USB1.1 port to see > if instantaneous bursts will exceed that bandwidth, as is > the case for quality services delivered via DVB-S and USB1.1. > > But I've read that it's the exception rather than the rule > that a particular service will be privileged to get more > than its proportional share of overall bandwidth, to be free > of most artifacts and be watchable, so I'd be willing to posit > that a full service (video, multiple audio, PMT, teletext, and > the like) will fit onto USB1.1. > > So much for background. Anyone still bothering to read? > > >> 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. > > No argument there. I had a look through Herr Rechberger's > code (simply because it's had a wider variety of included > hardware, not to say anything about the linuxtv code) to get > a feel for how many devices were exclusively DVB-T, or at > least didn't include some baseband video. > > It appears that a group of EM2870 devices (may well be the > 2874 in reality, I just numbly scan the code) are limited > to DVB-T, including Terratec Cinergy T XS, Pinnacle PCTV DVB-T, > a couple KWorld 35xU DVB-T devices, and a Compro VideoMate. > Apart from that, all remaining devices (apart from DMB and > the like) appear to have the ability to handle analogue > signals, and need USB2.0 to reach full potential. > > > >> 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. > > I actually have dredged from the dank dingy decaying dumpster > depths or doom a machine fast enough to decode and display SD > images, even without XVMC MPEG-2 acceleration, after replacing > most of the electrolytic condensers/capacitors on the board, yet > the internal USB ports are again 1.1. Given all the Blinkenlights > it's probably an ex-gamer machine, but compared with my machine > at some 1/7 the CPU clock, it's not as obsolete as it could be, > thou
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
Moin Devin, thanks for the reply. On Fri, 22 May 2009, Devin Heitmueller wrote: [cut my drivel] > The dvb core does have infrastructure to support hardware pid > filtering. If you don't mind, and this is a serious question, could you give me some keywords to look for? I've come up with some obvious winners in dvb-usb with uppercase FILTER, but lowercase filter didn't give me any serious Aha! moments for other devices, in an attempt to determine device capabilities by simple code reading. Thanks! (And I'll gladly eat my shoes when it turns out to be something stupendously simple, as I'm no code-reader) > 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. Bleedin' 'ell, I knew things were bigger in Texas, but I didn't know they wuz that big! ;-) Just kidding, I know what you meant... Just for background, the overall bandwidth of DVB-T will be determined by choice of frequency at one transmitter site or whether shared by several and how far apart, as well as other factors that are basically able to be simplified as a tradeoff of reliability over distance against bandwidth. There's a wide variance here, but in even the most widely-reaching Single- Frequency-Networks that are meant to be received at large distances under difficult conditions, where available overall bandwidth is less than that of a single transmitter serving a local area, said overall bandwidth is generally going to exceed that which I've achieved from USB1.1. A certain DVB-H network with 1/2 FEC and 1/4 guard interval drops below 10 000kbit/sec but isn't likely to represent common usage for broadcast TV services. On the other hand, the individual services within each multiplex will generally be well within the USB1.1 available bandwidth, provided hardware PID filtering can be applied. Bitrates for television services can be from some 2Mbit/sec up to over 5Mbit/sec at times, depending on whether that service has been configured to get the lion's share of the bandwidth at the expense of the other services with rates dynamically varying based on picture content thanks to statistical multiplexing. In any case, while I've been able to watch average-per-second bitrates of different PIDs on different multiplexes, I've just realized that I haven't actually used any DVB-T receivers for any length of time on a USB1.1 port to see if instantaneous bursts will exceed that bandwidth, as is the case for quality services delivered via DVB-S and USB1.1. But I've read that it's the exception rather than the rule that a particular service will be privileged to get more than its proportional share of overall bandwidth, to be free of most artifacts and be watchable, so I'd be willing to posit that a full service (video, multiple audio, PMT, teletext, and the like) will fit onto USB1.1. So much for background. Anyone still bothering to read? > 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. No argument there. I had a look through Herr Rechberger's code (simply because it's had a wider variety of included hardware, not to say anything about the linuxtv code) to get a feel for how many devices were exclusively DVB-T, or at least didn't include some baseband video. It appears that a group of EM2870 devices (may well be the 2874 in reality, I just numbly scan the code) are limited to DVB-T, including Terratec Cinergy T XS, Pinnacle PCTV DVB-T, a couple KWorld 35xU DVB-T devices, and a Compro VideoMate. Apart from that, all remaining devices (apart from DMB and the like) appear to have the ability to handle analogue signals, and need USB2.0 to reach full potential. > 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. I actually have dredged from the dank dingy decaying dumpster depths or doom a machine fast enough to decode and display SD images, even without XVMC MPEG-2 acceleration, after replacing most of the electrolytic condensers/capacitors on the board, yet the internal USB ports are again 1.1. Given all the Blinkenlights it's probably an ex-gamer machine, but compared with my machine at some 1/7 the CPU clock, it's not as obsolete as it could be, though that still doesn't stop me from periodically wanting to hurl it across the room every so often. So there are probably still a fair number of boxen out there with internal USB1.1 ports, that would be my guess. And whil
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Thu, May 21, 2009 at 10:26 PM, Devin Heitmueller wrote: > Hello Mauro, > > Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for > the following: > > em28xx: don't create the audio device if no onboard audio processor > em28xx: Add support for the K-World 2800d > au0828: Don't let device work unless connected to a high speed USB port > em28xx: Don't let device work unless connected to a high speed USB port > > Thank you, > > Devin Mauro, I tacked one more patch onto the end of this series, if you could please include it as well: tuner-core: fix warning introduced when cleaning up xc5000 init routine Thanks, 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
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Fri, May 22, 2009 at 9:48 PM, BOUWSMA Barry 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, Th
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for the following: em28xx: don't create the audio device if no onboard audio processor em28xx: Add support for the K-World 2800d au0828: Don't let device work unless connected to a high speed USB port em28xx: Don't let device work unless connected to a high speed USB port Thank you, 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
