On Wed, 12 Oct 2011, Markus Rechberger wrote: > >>> > Instead of using a single 24064-byte transfer, you can try submitting a > >>> > first transfer of 12288 bytes followed by a second transfer of 11776 > >>> > bytes. �This will mean the sixty-sixth 188-byte datapacket will be > >>> > split between the two transfers, but that shouldn't cause any > >>> > difficulty. > >>> > > >>> > (The numbers 12288 and 11776 are the two multiples of 512 closest to > >>> > 12032 = 24064 / 2.) > >>> > > >>> > >>> Just tried this, > >>> this is the order how the read requests were submitted: > >>> > >>> BULK SIZE: 11776 > >>> BULK SIZE: 12288 > >>> BULK SIZE: 11776 > >>> BULK SIZE: 12288 > >>> BULK SIZE: 11776 > >>> BULK SIZE: 12288 > >>> BULK SIZE: 11776 > >>> BULK SIZE: 12288 > >>> BULK SIZE: 11776 > >>> BULK SIZE: 12288 > >>> BULK SIZE: 11776 > >>> BULK SIZE: 12288 > >>> BULK SIZE: 11776 > >>> BULK SIZE: 12288 > >>> > >>> Same issue on Mac and Linux, the returned data is damaged. > >> > >> Damaged in what way? > > > > http://sundtek.de/images/dtvjitter2.jpg > > > > http://sundtek.de/images/gooddata.jpg > exactly the same happens with Linux and Mac. Looking at images doesn't tell me much. I'd need to see the actual data bytes. > I guess there's some latency issue with that chipset which is only > okay with the mentioned packet size. The packet size is 512 bytes, no matter what. That doesn't change. > I also tried to increase the packet size to 24064*2, it also causes You mean you changed the transfer size, not the packet size. > corruptions (my linux kernel is patched to allow bigger sizes). > > Any further idea? Are you using synchronous transfers or async? To avoid latency problems, you should always use the async API. Also, it wouldn't hurt to acquire some usbmon logs. One that shows what happens with your 24064 transfer size and another with the alternating 11776/12288 sizes. 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
