Hi Alan, On Tue, Oct 11, 2011 at 8:27 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 11 Oct 2011, Markus Rechberger wrote: > >> Hi Greg, Alan, >> >> so I just received another device, the device supports Bulk transfers >> only and only returns jerky data with Linux. >> Unfortunately I guess it's based on the chipset since the datatransfer >> needs the lowest common multiple buffersize. >> The datapackets which I need are 188 bytes big, the EP size is 512 >> bytes, the buffer needed in order to get working data >> is 24064 bytes which exceeds the current accepted buffersize in Linux. >> I'm having exactly the same problem with MacOSX with lower >> packetsizes, but OSX allows bigger packet sizes so it's easy to fix. >> It's the same with Windows. >> >> Now is there any way to improve this situation? >> Additional to the video service, the device itself uses software >> demodulation for digital radio and has several vendor specific parts >> in userspace. > > 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. Markus -- 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
