On Tue, Oct 11, 2011 at 9:27 PM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > On Tue, Oct 11, 2011 at 9:05 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Tue, 11 Oct 2011, Markus Rechberger wrote: >> >>> 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. >> >> Damaged in what way? > > http://sundtek.de/images/dtvjitter2.jpg > http://sundtek.de/images/gooddata.jpg exactly the same happens with Linux and Mac. I guess there's some latency issue with that chipset which is only okay with the mentioned packet size. I also tried to increase the packet size to 24064*2, it also causes corruptions (my linux kernel is patched to allow bigger sizes). Any further idea? Markus >> This should return exactly the same data as seven >> reads of 24064 bytes. The device doesn't see that URB boundaries; all >> it sees are the 512-byte packet boundaries. >> >> 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
