Hi, all
As we known, USB ISO endpoint is one kind of periodic endpoint, which has service interval, which is set by endpoint descriptor “bInterval”, and the value range from 1-16, and the real service interval is calculated by
2 exp (bInterval - 1) * 125 us
So if bInterval = 16
the service interval for this endpoint is
2 exp 15 8 125 us = 4,096,000 us
It is work fine as what we set in Win7 with 3rd party xHCI host controller driver,
but not on WDP with native xHCI host driver.
The phenomenon is, service interval do not change according to the bInterval value set.
So does WDP does not take this bInterval into account or any other reason, the service interval do not correct?
2 exp 15 * 125 us = 4,096,000 us
correct it.
workingmailing@163.com wrote:
As we known, USB ISO endpoint is one kind of periodic endpoint, which has service interval, which is set by endpoint descriptor “bInterval”, and the value range from 1-16, and the real service interval is calculated by
2 exp (bInterval - 1) * 125 us
So if bInterval = 16 the service interval for this endpoint is
2 exp 15 8 125 us = 4,096,000 us
It is work fine as what we set in Win7 with 3rd party xHCI host controller driver, but not on WDP with native xHCI host driver. The phenomenon is, service interval do not change according to the bInterval value set.
Right. Microsoft’s USB stacks do not support isochronous endpoints with
intervals longer than 1 ms.
http://msdn.microsoft.com/en-us/library/ff539114.aspx
You can use an interrupt endpoint to get a longer interval, but if your
interrupt interval is larger than 32 (frames or microframes), they’ll
use 32 instead.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
As the paper displayed: ISO support max 8 microframes, it is 8*125us on High speed case.
But when I set the bInterval with 16 in my USB3 device ep descriptor, from the trace, the service interval is 4ms (32*125us).
So does it change on the xHCI driver stack support for ISO?
workingmailing@163.com wrote:
As the paper displayed: ISO support max 8 microframes, it is 8*125us on High speed case.
But when I set the bInterval with 16 in my USB3 device ep descriptor, from the trace, the service interval is 4ms (32*125us).
So does it change on the xHCI driver stack support for ISO?
No one knows that yet. The MSDN chart clearly shows different levels of
support for different operating systems, so it’s quite possible it might
change.
Why does it matter?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It is because my USB device could not service with so quick interval.
workingmailing@163.com wrote:
It is because my USB device could not service with so quick interval.
That’s perfectly fine. Your device will not respond if it isn’t ready,
and the operating system will try again at the next interval.
When you have an interval that long, it usually makes sense to use an
interrupt pipe instead of an isochronous pipe.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I have review the USB3.0 spec, if device could sevice the Host, for ISO in data, it should respond with ZLP.
workingmailing@163.com wrote:
I have review the USB3.0 spec, if device could sevice the Host, for ISO in data, it should respond with ZLP.
I assume you meant “could not”.
It doesn’t really matter. To the driver, in an isochronous request,
“not responding” and “responding with a ZLP” look the same. “Not
responding” gets an error code in the IsoPacket array, but the net is
the same: you get 0 bytes in that packet.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
yes, it should be “could not”.
I agree with you, not matter it is “no response” or “ZLP”, host should take the same action, when the next service interval arriving, host will request the “IN data” again.
But it is not the case in WDP, when my USB3 device could not return the IN data, even the time is out, and next service interval arriving, host did not reqeust in data again.
So I was wonder, if USB3 spec differ from USB2 spec, when device could not return data in one service interval, it should explicitly return ZLP, but not no response.
workingmailing@163.com wrote:
yes, it should be “could not”.
I agree with you, not matter it is “no response” or “ZLP”, host should take the same action, when the next service interval arriving, host will request the “IN data” again.
But it is not the case in WDP, when my USB3 device could not return the IN data, even the time is out, and next service interval arriving, host did not reqeust in data again.
And your URB was still active? Remember that each packet in an
isochronous URB maps to one interval, whether you respond or not. If
you send a URB with 8 packets, and your device skips those 8 packets by
not responding, that URB is finished. If there isn’t another one
waiting, the host will not request more data.
So I was wonder, if USB3 spec differ from USB2 spec, when device could not return data in one service interval, it should explicitly return ZLP, but not no response.
Not as far as I know, but perhaps I should go double-check…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.