On Mon, 13 Jan 2014, Alan Ott wrote: > > By the way, isn't it true that f_sourcesink uses only one request for > > each bulk endpoint? That would naturally lead to a delay each time the > > request completes and has to be resubmitted. > > That's what the comment at the top of the file says, but it doesn't > appear to be true. See source_sink_start_ep(). It seems to start by > queueing up 8 transactions. I've adjusted this number up with no effect > (currently at 64). I don't follow your reasoning. The comment at the top of the file says: This just sinks bulk packets OUT to the peripheral... which is true, and also ... this doesn't queue more than one request at a time... which is also true for the bulk endpoints (although not for the isochronous endpoints). At high speed, one request = 8 transactions unless you specify a value for the buflen module parameter other than 4096. > Maybe there's something else I'm missing. At the end of the loop in source_sink_start_ep(): if (!is_iso) break; You could try removing those two lines and see what happens. (I'm not sure why those lines are there to begin with...) > > If the driver used two requests instead, the pipeline would be much > > less likely to empty out. > > Yes, I absolutely agree, the queue must be kept full, but in this case I > think it is. No, it isn't. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
