Hi Jan, hi Laurent...

    i have the same problem with different webcam... i think to have 
found the problem, Laurent tell me if i am wrong, i'll go to explain:

    The problem is in the bandwidth, the uvcdriver ALWAYS ask to usb 
layer a dw_MaxPayloadTransferSize that is fetched only when the device 
is opening;

    In my case is always set to 3072 (3x1024). I have tried changing 
uvc_video.c in a very dirty manner (excuse me Laurent) in this way:

    In function 'uvc_set_video_ctrl' where there is:
     put_unaligned_le32(ctrl->dwMaxVideoFrameSize, &data[18]);
     put_unaligned_le32(ctrl->dwMaxPayloadTransferSize, &data[22]);
    i have commented out the second line and changed it in:
    put_unaligned_le32(1024, &data[22]);

    In this way i have always force uvc driver to ask for a payload size 
of 1024.

    After recompiling, reinstalling, unload e load the module, i can get 
two webcam working fine and simultaneously.

    Now i didn't have a big experience and i can't change source myself 
in the right way... but i think that my observation can be usefull.

    I think that the best way to re-negotiate the bandwidth is to set 
video streaming parameters (framesize and frameinterval) and after ask 
the device wich bandwidth it requests.
    In a short way, at the end of uvc_set_video_ctrl function a call to 
uvc_get_video_ctrl will solve the problem... what do you think Laurent?)

BR Simone

P.S.: Excuse me for my english....

Jan Ciger wrote:
> Hash: SHA1
> Laurent Pinchart wrote:
>> That's bad. The USB EHCI driver will reject 2x 3072 bytes per microframe as 
>> exceeding the available bandwidth.
> Yep, I suspected something like that ...
>> I suppose you'll object that the cameras work on Windows, so I'll try to 
>> address that :-)
> Thank you :)
>> I see three possible reasons why Windows would stream video from both 
>> cameras 
>> at the same time.
>> - The Windows UVC driver might query the cameras slightly differently and 
>> receive a different bandwidth. A USB sniffer would help confirm or infirm 
>> this explanation.
> I can check this if I manage to get a sniffer to work. I will report
> back once that far.
>> - The Windows UVC driver might ignore the requested bandwidth and compute a 
>> value itself.
>> - Windows might accept 2x 3072 bytes per microframe. I seem to remember this 
>> might be the case, and that that behaviour is buggy according to the USB 2.0 
>> spec. You would have to contact the linux-usb mailing list for more 
>> information on that.
> Hard to say which one is correct. It could be even both - Windows
> accepts the value (doesn't report error) and the driver does some kind
> of black magic afterwards to get things actually working.
> I am getting different resolutions offered on Windows than on Linux and
> also the camera seems to run at a lower framerate if both cameras are
> streaming. I didn't try to measure it, but the stereo output looks like
> ~10fps or so. It could be a software issue as well, though.
> The documentation is also cautioning to plug the device ideally to a
> separate host and not to use the USB connectors on the front panel -
> they assume that those are not full-featured. So it could be indeed a
> marginal design.
>> It would be helpful if you could capture all USB control traffic from device 
>> enumeration to video streaming using a USB analyser (a software one will 
>> do). 
>> It would show what bandwidth the device requests, and what bandwidth the 
>> Windows UVC driver selects.
> As I said above, I will try to get a sniffer working and will report
> back once that far.
> Regards (and thanks),
> Jan
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
> iD8DBQFJhz2+n11XseNj94gRAlm+AKDOTMtUwPvAFW4sqLmLc+DhGzcXvgCeIuJP
> /Pq16p2jarKlLMQdVtCJmbI=
> =NsvL
> _______________________________________________
> Linux-uvc-devel mailing list
> Linux-uvc-devel@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/linux-uvc-devel

Linux-uvc-devel mailing list

Reply via email to