Am Dienstag 14 April 2009 22:40:20 schrieb Boris Borisov: > Josua Grawitter wrote: > > Am Dienstag 14 April 2009 16:47:19 schrieb Boris Borisov: > >> Josua Grawitter wrote: > >>> Am Montag 13 April 2009 19:47:24 schrieb Brian Johnson: > >>>> Bulk is sometimes useful for USB 1.1 were you have lower bandwidth > >>>> available. But yeah we shouldn't bother scanning the entire packet in > >>>> isoc mode as its not necessary at all. > >>>> > >>>> This patch has now been pushed out to the repo. > >>>> > >>>> 2009/4/12 Boris Borisov <[email protected]>: > >>>>> The bulk transfer and search in big stream is very hard task for > >>>>> processor. It is realy necesery to have bulk transfer? > >>>>> See my new proposal for patch. > >>>>> > >>>>> Brian Johnson wrote: > >>>>>> This code is necessary for bulk transfers since when using bulk mode > >>>>>> the header is not sent in a seperate packet by itself but is found > >>>>>> inside a larger bulk packet. however sicne when using isoc which is > >>>>>> the default the header is always a single 64 byte packet it should > >>>>>> be ok to run that scan only if you currently have bulk mode enabled. > >>>>>> > >>>>>> 2009/4/12 Boris Borisov <[email protected]>: > >>>>>>> Hello, > >>>>>>> The hunger function is detect start of frame, because is perform > >>>>>>> many comparation if received buffer is large than 64 bytes. > >>>>>>> See the patch > >>>>> > >>>>> snip > >>>>> > >>>>> > >>>>> > >>>>> diff --git a/sn9c20x-usb.c b/sn9c20x-usb.c > >>>>> index 4e7f1c7..ecec38d 100644 > >>>>> --- a/sn9c20x-usb.c > >>>>> +++ b/sn9c20x-usb.c > >>>>> @@ -501,12 +501,17 @@ int usb_sn9c20x_detect_frame(unsigned char > >>>>> *buf, unsigned int buf_length) else > >>>>> return -1; > >>>>> } > >>>>> - for (index = 0; index < buf_length - 63; index++) { > >>>>> - if (memcmp(buf + index, frame_header, 6) == 0) { > >>>>> - UDIA_DEBUG("Found Header at %d\n", index); > >>>>> - return index; > >>>>> - } > >>>>> - } > >>>>> + > >>>>> + if(bulk) > >>>>> + { > >>>>> + for (index = 0; index < buf_length - 63; index++) { > >>>>> + if (memcmp(buf + index, frame_header, 6) == 0) { > >>>>> + UDIA_DEBUG("Found Header at %d\n", > >>>>> index); + return index; > >>>>> + } > >>>>> + } > >>>>> + } > >>>>> + > >>>>> return -1; > >>>>> } > >>> > >>> Unfortunatly this didn't fix my problem either. > >>> > >>> I start to wonder if the problem is caused mplayer and not our driver. > >>> > >>> GWater > >>> > >>> BTW: Has anyone here experience with the linux HID-subsystem? > >> > >> This patch fix the processor load for isoc transfer. On my system from > >> 99% go to ~7% without libv4l (mean cat /dev/video0 > /dev/null) and ~50% > >> with libv4l. The jpeg format is loses bytes and picture is very poor > >> (flicker and lost synchronization). On all of my tests with mplayer and > >> bulk patch in isoc mode performance is ~70%. > > > > The lcok-ups must be caused by mplayer: > > VLC consumes ~30% of CPU under the same conditions. While the framerate > > is still low at 640x480 this doesn't bother the system - it only looks > > ugly. > > > > So we're fine. > > > > Are there anymore showstoppers for 2.6.31? Maybe one last call for > > testing? > > > > (BTW isn't the modern way to make send a git-pull request to the > > maintainer rather than sending patches?) > > > > GWater > > Very strange situation (I speak about skype and mplayer). I suspect > libv4l2 for this troubles. The code in libv4l is not optimal or have > some not cleared, or hidden bugs. > For 2.6.31 the driver is have full functionality, only some minor speed > optimization for stream functions usb_sn9c20x_detect_frame, > usb_sn9c20x_assemble_video, softautoexposure, jpeg preparation, and of > course final testing. > I try to optimize usb_sn9c20x_detect_frame and have some fresh idea for > more fast coding for bulk transfer. > Now the camera is plug&play for me :-) not plug&pray . > And one question to all: > Is really necessary to support JPEG? > Jpeg overloaded my CPU P4 2.8GHz. I prefer to run without JPEG compression. > Also I test driver on old computer with USB 1.1 Celeron 333MHz on this > machine not enough resource to process JPEG. On machine where have this > resource usually have also USB 2.0 port. > > > --~--~---------~--~----~------------~-------~--~----~ > Lets make microdia webcams plug'n play, (currently plug'n pray) > To post to this group, send email to [email protected] > Visit us online https://groups.google.com/group/microdia > -~----------~----~----~----~------~----~------~--~---
Like bulk transfer JPEG is necessary for most USB 1 computers. Without compression it is impossible to get more than 160x120 via USB 1.1 GWater
signature.asc
Description: This is a digitally signed message part.
