Re: OvlK_Wait() fails for iso EP poll rate >1ms

Basically, this iso EP is part of a clock sync mechanism. An
oscillator in the Device if fixed while the Host adapts its average
data rate to it. Synching once a second would be more than enough.

Oh well. For the time being all I can do is tell users to avoid
Atom-class CPUs. Which is kind of ridiculous.

At least now it's less likely this is a bug in the code I maintain.

The Device basically sends the same information again and again. So if
I could dump 95% of the packets in kernel mode, the scheduler and user
mode part would have less to do. But I won't bother you with a hack
like that in your code.

Børge


On Fri, Aug 22, 2014 at 5:11 PM, Travis <[email protected]> wrote:
> I agree!  You are not the first to bitch about this.  I'm not sure why
> MS does it this way but it is build into the bottom of their driver
> stack. The only thing I can suggest is using lots of ISO packets per
> transfer.
>
> Regards,
> Travis
>
> On 8/22/2014 8:49 AM, Børge Strand-Bergesen wrote:
>> Thanks Travis.
>>
>> Then I'll bury this issue. Pity, really. That poor scheduler doesn't
>> need to do all this work.
>>
>> It works, but I need to tell users they must use a powerfull computer
>> to pull it off.
>>
>>
>> Have a good weekend!
>>
>> Best,
>> Børge
>>
>>
>> On Fri, Aug 22, 2014 at 4:45 PM, Travis <[email protected]> wrote:
>>> Greetings,
>>>
>>> This is a windows limitation.  For high speed ISO, bInterval can be only
>>> 1,2,3, or 4.
>>>    http://msdn.microsoft.com/en-us/library/windows/hardware/hh406225%28v=vs.85%29.aspx
>>>
>>> Back in early beta I standardize on "INT, UINT, PINT, PUINT" for 32bit
>>> types.  Understand that long's are also 32 bit types in C/C++.
>>> Microsoft has a habit of making a mess with all of these.
>>>
>>> Regards,
>>> Travis
>>>
>>> On 8/22/2014 6:47 AM, Børge Strand-Bergesen wrote:
>>>> Hi guys,
>>>>
>>>> I'm working on a USB ASIO driver based on libusbK. It uses an
>>>> isochronous IN endpont for a feedback from the Device. Descriptor dump
>>>> is attached.
>>>>
>>>> The ASIO driver fails when the IN endpoint's poll rate becomes >1ms.
>>>> (See w5.txt line 220.) Rapid polling isn't needed in the application,
>>>> and I'd like to make it slower.
>>>>
>>>> Values of 4 and below work as expected in libusbK and mimic what I see
>>>> in Linux. 4 gives 1ms polling rate, 3->1/2ms, 2->1/4ms etc. But on
>>>> Linux I also have 5->2ms, 6->4ms, 7->8ms, 8->16ms. (Testing on OS X
>>>> roughly tracks what I see on Linux, but with fewer transitions. There
>>>> may be bugs in the descriptors which cause libusbK and OS X to
>>>> misunderstand them in different ways, where Linux seems to be OK.)
>>>>
>>>> What seems to happen is a failure in OvlK_Wait(). When called,
>>>> GetLastErrorInternal(); returns 00000057h.
>>>>
>>>> The calling code is line 138 of:
>>>> https://github.com/nikkov/Win-Widget/blob/experimental/uaclib/UsbDevice.h
>>>>
>>>> I use the latest libusbK 3.0.7.0 which I downloaded, linked to and
>>>> installed today. The built .dll is a 32-bit application. My system is
>>>> Win7-64.
>>>>
>>>> One thing I notice is that OvlK_Wait() parameter TransferredLength is
>>>> now PUINT. In the ASIO driver code it was PULONG for a while, but I
>>>> believe I have fixed that in all of the code now.
>>>>
>>>> I hope you can help me out with this issue. I hope device performance
>>>> will be better on weaker computers with slower polling.
>>>>
>>>> Let me know if you need more details about my system.
>>>>
>>>>
>>>> Thanks,
>>>> Børge
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Slashdot TV.
>>>> Video for Nerds.  Stuff that matters.
>>>> http://tv.slashdot.org/
>>>>
>>>>
>>>> _______________________________________________
>>>> Libusb-win32-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Slashdot TV.
>>> Video for Nerds.  Stuff that matters.
>>> http://tv.slashdot.org/
>>> _______________________________________________
>>> Libusb-win32-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Libusb-win32-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Libusb-win32-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Libusb-win32-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel