> >960 USB frames per second (not bad) but there a memory
> leak
>
> Not bad...? Isn't the max 1000 USB frames per second? ;)
>
> >of about 70 bytes per IRP submission. I did relatively
> few
> >control pipe submissions yet so can't say if it's
> leaking
> >too.
>
> a real leak, or just constant new()s that are eventually
> garbage
> collected? I need to put back in recycling of the
> LinuxRequest objects
> (not difficult but hadn't got to it yet). I'll check for
> leaks too, could
> be in the Linux implementation.
It may be a real leak. I didn't use List submissions yet,
will try later. Now an array of IRPs is created once and
submitted in init(). Whichever IRP is completed is
resubmitted again (see a bit simplified code below).
I was looking at memory footprint and a counter of
resubmitted IRPs (same as event.getSequenceNumber()). With
960 frames per second (this is rerrific!!) the leak was
easy to see, it was roughly 70 bytes per resubmit.
Automatic resubmits are sure not necessary if it's a
headache for implementations and there are other decent
ways to achive same thing.
private UsbIrp[] irps;
void init(){
irps=new UsbIrp[20];
byte[] data;
for(int i=0 ;i<irps.length;i++){
log("create and submit composite #"+i);
irp=factory.createUsbIrp();
data=new byte[PACKET_SIZE];
irp.setData(data);
irps[i]=irp;
videoPipe.asyncSubmit(irp);
}
videoPipe.addUsbPipeListener(this);
}
public void dataEventOccurred(UsbPipeDataEvent event){
UsbIrp irp;
for(int i=0;i<irps.length;i++){
irp=irps[i];
if(irp.isCompleted()){
try{videoPipe.asyncSubmit(irp);}
catch(UsbException e){/*handle exception*/}
}
}
}
> >There is no way to set automatic resubmission in this
> API
> >so whenever I get a data event on a listener I got to
> check
> >all IRPs that were submitted to the iso pipe if they is
> a
> >completed one to submit it again. Older API with
> >setResubmit(true) looked better.
>
> resbumit may have been nice but the implementation of it
> went way beyond a
> nightmare.
>
> I'm assuming you're using the List submission methods (I
> hope, as it
> should greatly increase performance on Linux ISO) so why
> don't you just
> check the last UsbIrp for each List, and if it's
> complete, resubmit the
> entire List, or handle it however else you like.
>
> The new API (0.10) includes a getUsbIrp field in
> UsbPipeDataEvent, as well
> as allowing user-created UsbIrps (and I'm going to put in
> a default
> implementation to extend) which you can override the
> complete()
> method. In that you can resubmit the whole batch or do
> whatever.
>
> >I'll try to get a real picture and see how well control
> >pipe behaves in more detail.
>
> great! Thanks.
>
>
> --
> Dan Streetman
> [EMAIL PROTECTED]
> ---------------------
> 186,272 miles per second:
> It isn't just a good idea, it's the law!
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November
> 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to
> be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> javax-usb-devel mailing list
> [EMAIL PROTECTED]
>
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
javax-usb-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
