offering bounty for GPL'd dual em28xx support

offering bounty for GPL'd dual em28xx support

[Steve Castellotti]

Hello everyone-

     Apologies in advance for spamming the list, but we're after adding 
dual device support for the existing, GPL'd em28xx tuner driver 
currently in the mainline Linux kernel. We do not have this development 
resource in house and had hoped perhaps someone on the list might be 
capable and interested (or able to point us in the appropriate direction).


     By way of more detail, it seems that multiple times in the past, 
other users have also requested this feature, but it is still not 
currently available in the current GPL'd driver. For some time support 
may have been present in the "em28xx-new" driver, provided by Markus 
Rechberger, but I have since been told it is "discontinued, and does not 
compile anymore with the latest kernels."


     This message thread as recently as April 9th, 2009, seems to 
indicate interest is still present at the community level, but no 
resolution was reached by the tail of the conversation:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg04245.html


     Going further back, it does seem that the em28xx-new driver at one 
point successfully addressed this issue, so supporting multiple devices 
should be possible with driver modification:

http://mcentral.de/pipermail/em28xx/2008-November/002111.html


     We can confirm that a development system running Fedora 11 with the 
latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx 
devices connected still exhibits the error message "v4l2: ioctl queue 
buffer failed: No space left on device" when attempting to display video 
input on two identical em28xx devices simultaneously.

     On the other hand, display is successful through either device when 
trying to display individually (with both still connected).


     We are a small company, which relies on the Linux platform for the 
core of our products and services. Occasionally a situation presents 
itself for us to contribute back to the Open Source community (in 
however small a fashion), either by releasing existing code or 
contracting a small amount of work to be performed and subsequently 
released under the GPL. This is one such instance.


     If anyone is interested in contributing such work and is prepared 
to quote for what they feel their time would be worth, please do not 
hesitate to contact me.

     Again, apologies if this message appears to be a misuse of the 
mailing list, hopefully our intentions are understandable!


Cheers


-- 

Steve Castellotti
sc@eyemagnet.com
Technical Director
Eyemagnet Limited
http://www.eyemagnet.com

Re: offering bounty for GPL'd dual em28xx support

[Devin Heitmueller]

On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellotti<sc@eyemagnet.com> wrote:
> Hello everyone-
>
>    Apologies in advance for spamming the list, but we're after adding dual
> device support for the existing, GPL'd em28xx tuner driver currently in the
> mainline Linux kernel. We do not have this development resource in house and
> had hoped perhaps someone on the list might be capable and interested (or
> able to point us in the appropriate direction).
>
>
>    By way of more detail, it seems that multiple times in the past, other
> users have also requested this feature, but it is still not currently
> available in the current GPL'd driver. For some time support may have been
> present in the "em28xx-new" driver, provided by Markus Rechberger, but I
> have since been told it is "discontinued, and does not compile anymore with
> the latest kernels."
>
>
>    This message thread as recently as April 9th, 2009, seems to indicate
> interest is still present at the community level, but no resolution was
> reached by the tail of the conversation:
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg04245.html
>
>
>    Going further back, it does seem that the em28xx-new driver at one point
> successfully addressed this issue, so supporting multiple devices should be
> possible with driver modification:
>
> http://mcentral.de/pipermail/em28xx/2008-November/002111.html
>
>
>    We can confirm that a development system running Fedora 11 with the
> latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx
> devices connected still exhibits the error message "v4l2: ioctl queue buffer
> failed: No space left on device" when attempting to display video input on
> two identical em28xx devices simultaneously.
>
>    On the other hand, display is successful through either device when
> trying to display individually (with both still connected).
>
>
>    We are a small company, which relies on the Linux platform for the core
> of our products and services. Occasionally a situation presents itself for
> us to contribute back to the Open Source community (in however small a
> fashion), either by releasing existing code or contracting a small amount of
> work to be performed and subsequently released under the GPL. This is one
> such instance.
>
>
>    If anyone is interested in contributing such work and is prepared to
> quote for what they feel their time would be worth, please do not hesitate
> to contact me.
>
>    Again, apologies if this message appears to be a misuse of the mailing
> list, hopefully our intentions are understandable!
>
>
> Cheers
>
>
> --
>
> Steve Castellotti
> sc@eyemagnet.com
> Technical Director
> Eyemagnet Limited
> http://www.eyemagnet.com

Hello Steve,

The issue occurs with various different drivers.  Basically the issue
is the device attempts to reserve a certain amount of bandwidth on the
USB bus for the isoc stream, and in the case of analog video at
640x480 this adds up to about 200Mbps.  As a result, connecting
multiple devices can result in exceeding the available bandwidth on
the USB bus.

Depending on your how many devices you are trying to connect, what
your target capture resolution is, and whether you can put each device
on its own USB bus will dictate what solution you can go with.

I've done a considerable amount of work with the mainline em28xx
driver, so if you would like to discuss your desired configuration
further and what we might be able to do to accommodate those
requirements (including possibly optimizing the driver to better
support more devices), feel free to email me off-list.

Regards,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: offering bounty for GPL'd dual em28xx support

[Steve Castellotti]

On 07/21/2009 06:42 PM, Devin Heitmueller wrote:
> On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellotti<sc@eyemagnet.com>  wrote:
>>     We can confirm that a development system running Fedora 11 with the
>> latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx
>> devices connected still exhibits the error message "v4l2: ioctl queue buffer
>> failed: No space left on device" when attempting to display video input on
>> two identical em28xx devices simultaneously.
>>
>>     On the other hand, display is successful through either device when
>> trying to display individually (with both still connected).
>>      
>
> Hello Steve,
>
> The issue occurs with various different drivers.  Basically the issue
> is the device attempts to reserve a certain amount of bandwidth on the
> USB bus for the isoc stream, and in the case of analog video at
> 640x480 this adds up to about 200Mbps.  As a result, connecting
> multiple devices can result in exceeding the available bandwidth on
> the USB bus.
>
> Depending on your how many devices you are trying to connect, what
> your target capture resolution is, and whether you can put each device
> on its own USB bus will dictate what solution you can go with.
>
> I've done a considerable amount of work with the mainline em28xx
> driver, so if you would like to discuss your desired configuration
> further and what we might be able to do to accommodate those
> requirements (including possibly optimizing the driver to better
> support more devices), feel free to email me off-list.
>
> Regards,
>
> Devin
>    

Devin-

     Thanks for the quick response. Happy to take the conversation 
off-list, but first, to clarify what may be useful to future web searchers:

     So if I'm working with a USB 2.0 bus, which should have a 
theoretical maximum of 480 Mbps, if the only two ports connected are 
both em28xx capture devices running at (say) 640x480, shouldn't that be 
sufficient for displaying both streams simultaneously?

     Talking in the general sense of course, perhaps some details vary 
from system to system - any idea what sort of variables might affect 
that however?

     I would assume most systems only have a single USB bus (regardless 
of whether plugs are present on the front/back/side). If a given system 
has a second USB bus or chipset, them perhaps plugging the second device 
into that would solve the problem, but that surely that would be a rare 
situation?

     Most of the systems we use do not have expansion slots, so adding a 
PCI USB board is not possible (in which case we would probably just add 
a PCI TV Capture board anyway!).


     That said, if you do have some thoughts or suggestions as to how we 
might be able to investigate specific hardware, or there is some other 
way you think you might be able to help address this particular problem 
(ideally in a way that benefits the larger community too!) please let me 
know.


Thanks again

Steve

-- 

Steve Castellotti
sc@eyemagnet.com
Technical Director
Eyemagnet Limited
http://www.eyemagnet.com

Re: offering bounty for GPL'd dual em28xx support

[Devin Heitmueller]

On Tue, Jul 21, 2009 at 10:19 PM, Steve Castellotti<sc@eyemagnet.com> wrote:
> On 07/21/2009 06:42 PM, Devin Heitmueller wrote:
>>
>> On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellotti<sc@eyemagnet.com>
>>  wrote:
>>>
>>>    We can confirm that a development system running Fedora 11 with the
>>> latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx
>>> devices connected still exhibits the error message "v4l2: ioctl queue
>>> buffer
>>> failed: No space left on device" when attempting to display video input
>>> on
>>> two identical em28xx devices simultaneously.
>>>
>>>    On the other hand, display is successful through either device when
>>> trying to display individually (with both still connected).
>>>
>>
>> Hello Steve,
>>
>> The issue occurs with various different drivers.  Basically the issue
>> is the device attempts to reserve a certain amount of bandwidth on the
>> USB bus for the isoc stream, and in the case of analog video at
>> 640x480 this adds up to about 200Mbps.  As a result, connecting
>> multiple devices can result in exceeding the available bandwidth on
>> the USB bus.
>>
>> Depending on your how many devices you are trying to connect, what
>> your target capture resolution is, and whether you can put each device
>> on its own USB bus will dictate what solution you can go with.
>>
>> I've done a considerable amount of work with the mainline em28xx
>> driver, so if you would like to discuss your desired configuration
>> further and what we might be able to do to accommodate those
>> requirements (including possibly optimizing the driver to better
>> support more devices), feel free to email me off-list.
>>
>> Regards,
>>
>> Devin
>>
>
> Devin-
>
>    Thanks for the quick response. Happy to take the conversation off-list,
> but first, to clarify what may be useful to future web searchers:
>
>    So if I'm working with a USB 2.0 bus, which should have a theoretical
> maximum of 480 Mbps, if the only two ports connected are both em28xx capture
> devices running at (say) 640x480, shouldn't that be sufficient for
> displaying both streams simultaneously?
>
>    Talking in the general sense of course, perhaps some details vary from
> system to system - any idea what sort of variables might affect that
> however?
>
>    I would assume most systems only have a single USB bus (regardless of
> whether plugs are present on the front/back/side). If a given system has a
> second USB bus or chipset, them perhaps plugging the second device into that
> would solve the problem, but that surely that would be a rare situation?
>
>    Most of the systems we use do not have expansion slots, so adding a PCI
> USB board is not possible (in which case we would probably just add a PCI TV
> Capture board anyway!).
>
>
>    That said, if you do have some thoughts or suggestions as to how we might
> be able to investigate specific hardware, or there is some other way you
> think you might be able to help address this particular problem (ideally in
> a way that benefits the larger community too!) please let me know.
>
>
> Thanks again
>
> Steve
>
> --
>
> Steve Castellotti
> sc@eyemagnet.com
> Technical Director
> Eyemagnet Limited
> http://www.eyemagnet.com

I agree that *in theory* you should be able to do two devices.  A back
of the envelope calculation of 640x480 at 30fps in YUVY capture should
be about 148Mbps.  That said, I don't think the scenario you are
describing has really been tested/debugged previously.  If I had to
guess, my suspicion would be a bug in the driver code that calculates
which USB alternate mode to operate in, which results in the driver
reserving more bandwidth than necessary.

I would have dig into the code and do some testing in order to have a
better idea where the problem is.  Do you have a specific em28xx
product in mind that you intend to use?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: offering bounty for GPL'd dual em28xx support

[Steve Castellotti]

On 07/21/2009 07:32 PM, Devin Heitmueller wrote:
> I agree that *in theory* you should be able to do two devices.  A back
> of the envelope calculation of 640x480 at 30fps in YUVY capture should
> be about 148Mbps.  That said, I don't think the scenario you are
> describing has really been tested/debugged previously.  If I had to
> guess, my suspicion would be a bug in the driver code that calculates
> which USB alternate mode to operate in, which results in the driver
> reserving more bandwidth than necessary.
>
> I would have dig into the code and do some testing in order to have a
> better idea where the problem is.  Do you have a specific em28xx
> product in mind that you intend to use?
>

     Well in theory there's no difference between theory and practice, 
but in practice there is (c:


     More than happy to coordinate some testing of a variety of em28xx 
devices we have handy around the office if it would help isolate any 
bugs. We could throw some QA resource at the problem if nothing else.


     One of the devices we're supposed to be able to acquire in bulk is 
no-name brand that simply says "VC-211A" on the label. "lsusb" output 
looks like this:

ID eb1a:2861 eMPIA Technology, Inc.


     The other says "GrabBeeX+ deluxe" and has this identifier:


ID eb1a:2821 eMPIA Technology, Inc.


     We have a 2-3 others on hand as well.


     Once again, thanks for the responsiveness and please let me know 
what we can do to contribute.


Cheers

Steve


-- 

Steve Castellotti
sc@eyemagnet.com
Technical Director
Eyemagnet Limited
http://www.eyemagnet.com

Re: offering bounty for GPL'd dual em28xx support

[Devin Heitmueller]

On Tue, Jul 21, 2009 at 11:47 PM, Steve Castellotti<sc@eyemagnet.com> wrote:
> On 07/21/2009 07:32 PM, Devin Heitmueller wrote:
>>
>> I agree that *in theory* you should be able to do two devices.  A back
>> of the envelope calculation of 640x480 at 30fps in YUVY capture should
>> be about 148Mbps.  That said, I don't think the scenario you are
>> describing has really been tested/debugged previously.  If I had to
>> guess, my suspicion would be a bug in the driver code that calculates
>> which USB alternate mode to operate in, which results in the driver
>> reserving more bandwidth than necessary.
>>
>> I would have dig into the code and do some testing in order to have a
>> better idea where the problem is.  Do you have a specific em28xx
>> product in mind that you intend to use?
>>
>
>    Well in theory there's no difference between theory and practice, but in
> practice there is (c:
>
>
>    More than happy to coordinate some testing of a variety of em28xx devices
> we have handy around the office if it would help isolate any bugs. We could
> throw some QA resource at the problem if nothing else.
>
>
>    One of the devices we're supposed to be able to acquire in bulk is
> no-name brand that simply says "VC-211A" on the label. "lsusb" output looks
> like this:
>
> ID eb1a:2861 eMPIA Technology, Inc.
>
>
>    The other says "GrabBeeX+ deluxe" and has this identifier:
>
>
> ID eb1a:2821 eMPIA Technology, Inc.
>
>
>    We have a 2-3 others on hand as well.
>
>
>    Once again, thanks for the responsiveness and please let me know what we
> can do to contribute.

Well, I think I own something like nine different em28xx products, so
I should be able to hook a couple of them up at the same time and
debug the issue.  The only issue at this point is that I already have
a rather full plate of issues I am currently working.

I'll see if I can schedule some cycles in the next couple of weeks to
take a look (unless someone else wants to step up and debug the
issue).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: offering bounty for GPL'd dual em28xx support

[Mauro Carvalho Chehab]

Em Tue, 21 Jul 2009 20:47:05 -0700
Steve Castellotti <sc@eyemagnet.com> escreveu:

> On 07/21/2009 07:32 PM, Devin Heitmueller wrote:
> > I agree that *in theory* you should be able to do two devices.  A back
> > of the envelope calculation of 640x480 at 30fps in YUVY capture should
> > be about 148Mbps.  That said, I don't think the scenario you are
> > describing has really been tested/debugged previously.  If I had to
> > guess, my suspicion would be a bug in the driver code that calculates
> > which USB alternate mode to operate in, which results in the driver
> > reserving more bandwidth than necessary.
> >
> > I would have dig into the code and do some testing in order to have a
> > better idea where the problem is.  Do you have a specific em28xx
> > product in mind that you intend to use?
> >

Steve,

I did last year some code optimizations and tests in order to support more than one
em28xx device:

	http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01634.html

In summary, a 480 Mbps Usb 2.0 bus can be used up to 80% of its maximum
bandwidth, and a single video stream eats more than 40% of the maximum
available bandwidth, according with Usb 2.0 isoc transfer tables.

On that time, I did a patch that auto-adjusts the amount of used bandwidth
based on the resolution. So, in thesis, if you select 320x200, you'll eat less
bandwidth and you may have two devices connected at the same usb bus.

Before my patch, a video stream whose resolution is 720x480x30fps,16
bits/pixel, meaning about 166 Mbps stream rate (without USB oveheads) was
eating 60% of the maximum allowed bus speed (80% of 480 Mbps).

The rationale is that USB 2.0 has a limit on the maximum number of isoc packets
and packet size per second, based on timing issues.

I remember I did some tests that succeeded on eating less bandwidth, and that
it did work with more than one em28xx hardware.

There are a few missing features to allow the em28xx driver to eat less bandwidth:

1) As we now support formats with 8 and 12 bits per pixel, we may optimize the
code as well to consider the number of bpp at the calculus on
em28xx_set_alternate(). 

In thesis, all we need to do is to replace the magic number "2" on the first
calculus:

        unsigned int min_pkt_size = dev->width * 2 + 4;

        /* When image size is bigger than a certain value,
           the frame size should be increased, otherwise, only
           green screen will be received.
         */

        if (dev->width * 2 * dev->height > 720 * 240 * 2)
                min_pkt_size *= 2;

So, changing the first calculus to:
        unsigned int min_pkt_size = ((dev->width * dev->format->depth + 7) >> 3) + 4;

and being sure that the function is properly called at the proper places (it
should be, already) will probably eat about half of the bandwidth, if you
select an 8 bpp output format (currently, only bayer formats are supported).

There's one issue here: most apps don't support bayer format, so we need libv4l
to convert. However, I'm not sure if libv4l will select bayer format, or will
keep using yuy2 for input. It would be nice to add some control on libv4l to
allow controlling the input format based on the user needs (less bandwidth or
less quality). I'm copying Hans here, since he maintains libv4l.

The second calculus were obtained experimentally. Not sure what is needed
there. Maybe Devin can came up with a better formula.

2) to select also fps and calculate bandwidth accordingly. 

For this to work, we need to discover a way to slow down the frame rate and see
if this will really allow using more devices.

On my tests on implementing em28xx Silvercrest webcam support, some weeks ago,
I discovered that slowing down the frame rate at the sensor is enough to slow
it down at em28xx driver. So, it is on my TODO list to add fps selection at the
driver, at least for devices with mt9v011 sensor.

I wish I had more than one em28xx webcam here for tests, but I currently have
just one (thanks to Hans that borrowed it to Douglas, that borrowed it to me).

If this strategy of slowing down the fps by changing the sensos also works with
analog demods, grabber devices can also benefit of such gains. In this case,
the solution is to add, if possible, a frame rate selection at saa7115 and
tvp5150 drivers. At the time I wrote the tvp5150 driver, I haven't cared to
provide such controls. I'll need to double check its datasheets to be sure if
this is possible.



Cheers,
Mauro

Re: offering bounty for GPL'd dual em28xx support

[Devin Heitmueller]

On Wed, Jul 22, 2009 at 1:43 AM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> I did last year some code optimizations and tests in order to support more than one
> em28xx device:
>
>        http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01634.html
>
> In summary, a 480 Mbps Usb 2.0 bus can be used up to 80% of its maximum
> bandwidth, and a single video stream eats more than 40% of the maximum
> available bandwidth, according with Usb 2.0 isoc transfer tables.
>
> On that time, I did a patch that auto-adjusts the amount of used bandwidth
> based on the resolution. So, in thesis, if you select 320x200, you'll eat less
> bandwidth and you may have two devices connected at the same usb bus.
>
> Before my patch, a video stream whose resolution is 720x480x30fps,16
> bits/pixel, meaning about 166 Mbps stream rate (without USB oveheads) was
> eating 60% of the maximum allowed bus speed (80% of 480 Mbps).
>
> The rationale is that USB 2.0 has a limit on the maximum number of isoc packets
> and packet size per second, based on timing issues.
>
> I remember I did some tests that succeeded on eating less bandwidth, and that
> it did work with more than one em28xx hardware.
>
> There are a few missing features to allow the em28xx driver to eat less bandwidth:
>
> 1) As we now support formats with 8 and 12 bits per pixel, we may optimize the
> code as well to consider the number of bpp at the calculus on
> em28xx_set_alternate().
>
> In thesis, all we need to do is to replace the magic number "2" on the first
> calculus:
>
>        unsigned int min_pkt_size = dev->width * 2 + 4;
>
>        /* When image size is bigger than a certain value,
>           the frame size should be increased, otherwise, only
>           green screen will be received.
>         */
>
>        if (dev->width * 2 * dev->height > 720 * 240 * 2)
>                min_pkt_size *= 2;
>
> So, changing the first calculus to:
>        unsigned int min_pkt_size = ((dev->width * dev->format->depth + 7) >> 3) + 4;
>
> and being sure that the function is properly called at the proper places (it
> should be, already) will probably eat about half of the bandwidth, if you
> select an 8 bpp output format (currently, only bayer formats are supported).
>
> There's one issue here: most apps don't support bayer format, so we need libv4l
> to convert. However, I'm not sure if libv4l will select bayer format, or will
> keep using yuy2 for input. It would be nice to add some control on libv4l to
> allow controlling the input format based on the user needs (less bandwidth or
> less quality). I'm copying Hans here, since he maintains libv4l.
>
> The second calculus were obtained experimentally. Not sure what is needed
> there. Maybe Devin can came up with a better formula.
>
> 2) to select also fps and calculate bandwidth accordingly.
>
> For this to work, we need to discover a way to slow down the frame rate and see
> if this will really allow using more devices.
>
> On my tests on implementing em28xx Silvercrest webcam support, some weeks ago,
> I discovered that slowing down the frame rate at the sensor is enough to slow
> it down at em28xx driver. So, it is on my TODO list to add fps selection at the
> driver, at least for devices with mt9v011 sensor.
>
> I wish I had more than one em28xx webcam here for tests, but I currently have
> just one (thanks to Hans that borrowed it to Douglas, that borrowed it to me).
>
> If this strategy of slowing down the fps by changing the sensos also works with
> analog demods, grabber devices can also benefit of such gains. In this case,
> the solution is to add, if possible, a frame rate selection at saa7115 and
> tvp5150 drivers. At the time I wrote the tvp5150 driver, I haven't cared to
> provide such controls. I'll need to double check its datasheets to be sure if
> this is possible.

Hello Mauro,

As far as I know, the em28xx has no capability to adjust the frame
rate.  It will forward the frames at whatever rate the ITU656 stream
is delivered from the decoder.  I also don't think the tvp5150 will
deliver frames at any rather other than the NTSC/PAL standard in
question (but I would have to double-check the tvp5150 datasheet to be
sure).

I would like to spend some time looking closer at the formula used to
calculate the set_alternate() call.  I just haven't had the time to
invest in such an investigation given all the other stuff I am working
on right now (in particular the three or four em28xx devices I am
adding support for, the xc4000 driver work, and hvr-950q analog
fixes).

I didn't know about the 80% utilization cap for isoc, so thanks for
providing the reference to that previous thread, which has some pretty
interesting information.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: offering bounty for GPL'd dual em28xx support

[Mauro Carvalho Chehab]

Em Wed, 22 Jul 2009 12:02:48 -0400
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> Hello Mauro,
> 
> As far as I know, the em28xx has no capability to adjust the frame
> rate.  It will forward the frames at whatever rate the ITU656 stream
> is delivered from the decoder.

Ok. So, the fps changing will be limited to the decoder and/or sensor that
supports it.

>  I also don't think the tvp5150 will
> deliver frames at any rather other than the NTSC/PAL standard in
> question (but I would have to double-check the tvp5150 datasheet to be
> sure).

On a very quick check on saa7114/saa7115 and tvp5150, I couldn't find any way
do do spatial decimation to reduce fps. So, it seems that we'll have this
feature only with webcams where such type of control is common.

> I would like to spend some time looking closer at the formula used to
> calculate the set_alternate() call.  I just haven't had the time to
> invest in such an investigation given all the other stuff I am working
> on right now (in particular the three or four em28xx devices I am
> adding support for, the xc4000 driver work, and hvr-950q analog
> fixes).

Maybe that magic calculus took from experimentation are due to vbi and/or audio
streams. It would be nice to adjust it to be less conservative.

> I didn't know about the 80% utilization cap for isoc, so thanks for
> providing the reference to that previous thread, which has some pretty
> interesting information.

Anytime.



Cheers,
Mauro

Re: offering bounty for GPL'd dual em28xx support

[Steve Castellotti]

On Wed, 2009-07-22 at 13:18 -0300, Mauro Carvalho Chehab wrote: 
> > I didn't know about the 80% utilization cap for isoc, so thanks for
> > providing the reference to that previous thread, which has some pretty
> > interesting information.
> 
> Anytime.

    Yeah have to agree, thanks so much for the illuminating and
informative discussion everyone!

-- 
Steve Castellotti
Technical Director
Eyemagnet - New Zealand

Re: offering bounty for GPL'd dual em28xx support

[Steve Castellotti]

On Wed, 2009-07-22 at 13:18 -0300, Mauro Carvalho Chehab wrote: 
> > I didn't know about the 80% utilization cap for isoc, so thanks for
> > providing the reference to that previous thread, which has some pretty
> > interesting information.
> 
> Anytime.

    Yeah have to agree, thanks so much for the illuminating and
informative discussion everyone!

-- 
Steve Castellotti
Technical Director
Eyemagnet - New Zealand

Re: offering bounty for GPL'd dual em28xx support

[Jelle de Jong]

Devin Heitmueller wrote:

<snip>

> The issue occurs with various different drivers.  Basically the issue
> is the device attempts to reserve a certain amount of bandwidth on the
> USB bus for the isoc stream, and in the case of analog video at
> 640x480 this adds up to about 200Mbps.  As a result, connecting
> multiple devices can result in exceeding the available bandwidth on
> the USB bus.
> 
> Depending on your how many devices you are trying to connect, what
> your target capture resolution is, and whether you can put each device
> on its own USB bus will dictate what solution you can go with.

Hi all,

So I felt like doing  a field test, with my dvb-t test system.

Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900
Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e
Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc.
Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex]
Bus 001 Device 002: ID 15a4:9016

I have now three devices with dvb-t channels running with different
channels and audio on an atom based cpu without problems.

two:
dvb-usb-dib0700

and one:
dvb-usb-af9015

the dvb-usb-af9015 takes way more cpu interrupts because of the usb
block size.

prove:
http://imagebin.ca/img/xM9Q7_A.jpg

I will be demonstrating this at har2009 (see demonstration village)

Devin could you login onto the dvb-t test system and see if you can get
those em28xx device running with your new code?

I will probably make an other test system with some more cpu power to
see if even more usb devices are possible, or I may use my nice powerful
multiseat quad core system for it.

Best regards,

Jelle de Jong

Re: offering bounty for GPL'd dual em28xx support

[Mauro Carvalho Chehab]

Em Wed, 22 Jul 2009 12:10:38 +0200
Jelle de Jong <jelledejong@powercraft.nl> escreveu:

> Devin Heitmueller wrote:
> 
> <snip>
> 
> > The issue occurs with various different drivers.  Basically the issue
> > is the device attempts to reserve a certain amount of bandwidth on the
> > USB bus for the isoc stream, and in the case of analog video at
> > 640x480 this adds up to about 200Mbps.  As a result, connecting
> > multiple devices can result in exceeding the available bandwidth on
> > the USB bus.
> > 
> > Depending on your how many devices you are trying to connect, what
> > your target capture resolution is, and whether you can put each device
> > on its own USB bus will dictate what solution you can go with.
> 
> Hi all,
> 
> So I felt like doing  a field test, with my dvb-t test system.
> 
> Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900
> Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e
> Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc.
> Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex]
> Bus 001 Device 002: ID 15a4:9016
> 
> I have now three devices with dvb-t channels running with different
> channels and audio on an atom based cpu without problems.
> 
> two:
> dvb-usb-dib0700
> 
> and one:
> dvb-usb-af9015
> 
> the dvb-usb-af9015 takes way more cpu interrupts because of the usb
> block size.
> 
> prove:
> http://imagebin.ca/img/xM9Q7_A.jpg
> 
> I will be demonstrating this at har2009 (see demonstration village)
> 
> Devin could you login onto the dvb-t test system and see if you can get
> those em28xx device running with your new code?
> 
> I will probably make an other test system with some more cpu power to
> see if even more usb devices are possible, or I may use my nice powerful
> multiseat quad core system for it.
> 
> Best regards,
> 
> Jelle de Jong

Jelle,

DVB-T is less consuming than analog, since the streams are mpeg compressed. The
issue with em28xx is that, on analog mode, all data come uncompressed. So, the
worse case is a NTSC stream with 16 bit YUY2 frame with using 720x480x30x2 Mbps (e. g.
207 Mbps) for the payload, plus some additional bandwidth for the transport
headers. On HD, mpeg stream are up to 23 Mbps on DTV systems (ISDB full-seg is the
worse case on DTV).

So, analog demands about 9x more bandwidth than digital at USB bus.



Cheers,
Mauro

Re: offering bounty for GPL'd dual em28xx support

[Markus Rechberger]

On Wed, Jul 22, 2009 at 4:48 PM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> Em Wed, 22 Jul 2009 12:10:38 +0200
> Jelle de Jong <jelledejong@powercraft.nl> escreveu:
>
>> Devin Heitmueller wrote:
>>
>> <snip>
>>
>> > The issue occurs with various different drivers.  Basically the issue
>> > is the device attempts to reserve a certain amount of bandwidth on the
>> > USB bus for the isoc stream, and in the case of analog video at
>> > 640x480 this adds up to about 200Mbps.  As a result, connecting
>> > multiple devices can result in exceeding the available bandwidth on
>> > the USB bus.
>> >
>> > Depending on your how many devices you are trying to connect, what
>> > your target capture resolution is, and whether you can put each device
>> > on its own USB bus will dictate what solution you can go with.
>>
>> Hi all,
>>
>> So I felt like doing  a field test, with my dvb-t test system.
>>
>> Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900
>> Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e
>> Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc.
>> Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex]
>> Bus 001 Device 002: ID 15a4:9016
>>
>> I have now three devices with dvb-t channels running with different
>> channels and audio on an atom based cpu without problems.
>>
>> two:
>> dvb-usb-dib0700
>>
>> and one:
>> dvb-usb-af9015
>>
>> the dvb-usb-af9015 takes way more cpu interrupts because of the usb
>> block size.
>>
>> prove:
>> http://imagebin.ca/img/xM9Q7_A.jpg
>>
>> I will be demonstrating this at har2009 (see demonstration village)
>>
>> Devin could you login onto the dvb-t test system and see if you can get
>> those em28xx device running with your new code?
>>
>> I will probably make an other test system with some more cpu power to
>> see if even more usb devices are possible, or I may use my nice powerful
>> multiseat quad core system for it.
>>
>> Best regards,
>>
>> Jelle de Jong
>
> Jelle,
>
> DVB-T is less consuming than analog, since the streams are mpeg compressed. The
> issue with em28xx is that, on analog mode, all data come uncompressed. So, the
> worse case is a NTSC stream with 16 bit YUY2 frame with using 720x480x30x2 Mbps (e. g.
> 207 Mbps) for the payload, plus some additional bandwidth for the transport
> headers. On HD, mpeg stream are up to 23 Mbps on DTV systems (ISDB full-seg is the
> worse case on DTV).
>

207Mbps??

720*480*30 = 20736000 bytes == 19.78 Mbyte == 158.20 Mbit sure there's
some overhead but your calculation is wrong.

Markus

Re: offering bounty for GPL'd dual em28xx support

[Devin Heitmueller]

On Wed, Jul 22, 2009 at 6:10 AM, Jelle de Jong<jelledejong@powercraft.nl> wrote:
> So I felt like doing  a field test, with my dvb-t test system.
>
> Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900
> Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e
> Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc.
> Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex]
> Bus 001 Device 002: ID 15a4:9016
>
> I have now three devices with dvb-t channels running with different
> channels and audio on an atom based cpu without problems.
>
> two:
> dvb-usb-dib0700
>
> and one:
> dvb-usb-af9015
>
> the dvb-usb-af9015 takes way more cpu interrupts because of the usb
> block size.
>
> prove:
> http://imagebin.ca/img/xM9Q7_A.jpg
>
> I will be demonstrating this at har2009 (see demonstration village)
>
> Devin could you login onto the dvb-t test system and see if you can get
> those em28xx device running with your new code?
>
> I will probably make an other test system with some more cpu power to
> see if even more usb devices are possible, or I may use my nice powerful
> multiseat quad core system for it.

Hello Jelle,

Please understand that your experiment isn't really an appropriate
test.  The original user was referring to analog capture mode, in
which the uncompressed video is coming across the USB bus.  Analog
mode uses about 200Mbps while digital mode uses only 10-20Mbps.  If
you had tried capturing analog video with those devices you would have
seen similar results to what Steve described.

I haven't forgotten about your test environment, and I look forward to
getting the HVR-900 R2 and PCTV 330e working.  I have been sick in bed
for the last two days and have done no LinuxTV related work.  I look
forward to getting back to it this week.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: offering bounty for GPL'd dual em28xx support

[Jelle de Jong]

Devin Heitmueller wrote:
> On Wed, Jul 22, 2009 at 6:10 AM, Jelle de Jong<jelledejong@powercraft.nl> wrote:
>> So I felt like doing �a field test, with my dvb-t test system.
>>
>> Bus 001 Device 008: ID 2040:6502 Hauppauge WinTV HVR-900
>> Bus 001 Device 007: ID 2304:0226 Pinnacle Systems, Inc. [hex] PCTV 330e
>> Bus 001 Device 005: ID 0b05:173f ASUSTek Computer, Inc.
>> Bus 001 Device 003: ID 2304:0236 Pinnacle Systems, Inc. [hex]
>> Bus 001 Device 002: ID 15a4:9016
>>
>> I have now three devices with dvb-t channels running with different
>> channels and audio on an atom based cpu without problems.
>>
>> two:
>> dvb-usb-dib0700
>>
>> and one:
>> dvb-usb-af9015
>>
>> the dvb-usb-af9015 takes way more cpu interrupts because of the usb
>> block size.
>>
>> prove:
>> http://imagebin.ca/img/xM9Q7_A.jpg
>>
>> I will be demonstrating this at har2009 (see demonstration village)
>>
>> Devin could you login onto the dvb-t test system and see if you can get
>> those em28xx device running with your new code?
>>
>> I will probably make an other test system with some more cpu power to
>> see if even more usb devices are possible, or I may use my nice powerful
>> multiseat quad core system for it.
> 
> Hello Jelle,
> 
> Please understand that your experiment isn't really an appropriate
> test.  The original user was referring to analog capture mode, in
> which the uncompressed video is coming across the USB bus.  Analog
> mode uses about 200Mbps while digital mode uses only 10-20Mbps.  If
> you had tried capturing analog video with those devices you would have
> seen similar results to what Steve described.
> 
> I haven't forgotten about your test environment, and I look forward to
> getting the HVR-900 R2 and PCTV 330e working.  I have been sick in bed
> for the last two days and have done no LinuxTV related work.  I look
> forward to getting back to it this week.
> 
> Cheers,
> 
> Devin
> 

Funky timing of those mails :D.

I saw only after sending my mail that Steve was talking about analog and
that this is indeed different. Dual analog tuner support should be
possible right? Maybe with some other analog usb chipsets? I don't know
what the usb blocksize is or if they are isochronous transfers or bulk
or control.

I assume the video must be uncompressed transferred over usb because the
decoding chip is on the usb device is not capable of doing compression
encoding after the analog video decoding? Are there usb devices that do
such tricks?

Best regards,

Jelle

Re: offering bounty for GPL'd dual em28xx support

[Devin Heitmueller]

On Wed, Jul 22, 2009 at 11:01 AM, Jelle de
Jong<jelledejong@powercraft.nl> wrote:
> Funky timing of those mails :D.
>
> I saw only after sending my mail that Steve was talking about analog and
> that this is indeed different. Dual analog tuner support should be
> possible right? Maybe with some other analog usb chipsets? I don't know
> what the usb blocksize is or if they are isochronous transfers or bulk
> or control.
>
> I assume the video must be uncompressed transferred over usb because the
> decoding chip is on the usb device is not capable of doing compression
> encoding after the analog video decoding? Are there usb devices that do
> such tricks?

There were older devices that did compression, mainly designed to fit
the stream inside of 12Mbps USB.  However, they required onboard RAM
to buffer the frame which added considerable cost (in addition to the
overhead of doing the compression), and as a result pretty much all of
the USB 2.0 designs I have seen do not do any on-chip compression.

The example which comes to mind is the Hauppauge Win-TV USB which uses
the usbvision chipset.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: offering bounty for GPL'd dual em28xx support

[Mauro Carvalho Chehab]

Em Wed, 22 Jul 2009 11:06:12 -0400
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> On Wed, Jul 22, 2009 at 11:01 AM, Jelle de
> Jong<jelledejong@powercraft.nl> wrote:
> > Funky timing of those mails :D.
> >
> > I saw only after sending my mail that Steve was talking about analog and
> > that this is indeed different. Dual analog tuner support should be
> > possible right? Maybe with some other analog usb chipsets? I don't know
> > what the usb blocksize is or if they are isochronous transfers or bulk
> > or control.
> >
> > I assume the video must be uncompressed transferred over usb because the
> > decoding chip is on the usb device is not capable of doing compression
> > encoding after the analog video decoding? Are there usb devices that do
> > such tricks?
> 
> There were older devices that did compression, mainly designed to fit
> the stream inside of 12Mbps USB.  However, they required onboard RAM
> to buffer the frame which added considerable cost (in addition to the
> overhead of doing the compression), and as a result pretty much all of
> the USB 2.0 designs I have seen do not do any on-chip compression.
> 
> The example which comes to mind is the Hauppauge Win-TV USB which uses
> the usbvision chipset.

pvrusb2 also has compression, provided by an external mpeg encoder. Those
devices are USB 2.0



Cheers,
Mauro

Re: offering bounty for GPL'd dual em28xx support

[Mike Isely]

On Wed, 22 Jul 2009, Mauro Carvalho Chehab wrote:

> Em Wed, 22 Jul 2009 11:06:12 -0400
> Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:
> 
> > On Wed, Jul 22, 2009 at 11:01 AM, Jelle de
> > Jong<jelledejong@powercraft.nl> wrote:
> > > Funky timing of those mails :D.
> > >
> > > I saw only after sending my mail that Steve was talking about analog and
> > > that this is indeed different. Dual analog tuner support should be
> > > possible right? Maybe with some other analog usb chipsets? I don't know
> > > what the usb blocksize is or if they are isochronous transfers or bulk
> > > or control.
> > >
> > > I assume the video must be uncompressed transferred over usb because the
> > > decoding chip is on the usb device is not capable of doing compression
> > > encoding after the analog video decoding? Are there usb devices that do
> > > such tricks?
> > 
> > There were older devices that did compression, mainly designed to fit
> > the stream inside of 12Mbps USB.  However, they required onboard RAM
> > to buffer the frame which added considerable cost (in addition to the
> > overhead of doing the compression), and as a result pretty much all of
> > the USB 2.0 designs I have seen do not do any on-chip compression.
> > 
> > The example which comes to mind is the Hauppauge Win-TV USB which uses
> > the usbvision chipset.
> 
> pvrusb2 also has compression, provided by an external mpeg encoder. Those
> devices are USB 2.0
> 

I know this is a fairly old thread, but I've been away on vacation and 
I'm catching up on e-mail right now.  So forgive me if this has already 
been answered...

The Hauppauge Win-TV PVR-USB2 is the most well-known device in this 
category and it's what the pvrusb2 driver originally targeted.  This 
device uses a dedicated mpeg encoder chip within the device, so the 
video stream coming from the hardware is actually compressed video (mpeg 
format, mostly DVD-style mpeg2).  The question of USB 1.1 vs USB 2.0 is 
actually due to the device's microcontroller (the "bridge chip") not the 
mpeg encoder.  In the pvrusb2 case, that controller is a Cypress FX2 
which includes an on-chip USB 2.0 high-speed device interface.  But the 
mpeg encoder actually doesn't REQUIRE USB 2.0 high-speed.  The default 
encoder settings configured by the pvrusb2 driver actually work quite 
well over USB 1.1, since the resulting video stream requires 
significantly less bandwidth than the 12Mbps that USB 1.1 can 
theoretically supply.  I've actually successfully tested such a 
configuration here.  The hardware works fine over USB 1.1.

  -Mike

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8