On Wed, Oct 12, 2011 at 9:18 AM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > 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 >> > This was done with 24064 > http://sundtek.de/images/gooddata.jpg > exactly the same happens with Linux and Mac. > the other tests were done with 24064*2, and fragments of 24064 which end up to fail. > 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
