Xbox Kinnect NUI Audio Device under Windows

NTDEV
1

We have a discussion on libusb-win32 mailing list about a device
from Microsoft. Xbox Kinnect has the Xbox NUI Audio device which
is a high speed USB device and it has an Isochronous IN
(EP2 IN) endpoint with bInterval of 5.
http://libusb.6.n5.nabble.com/Cheating-isochronous-transfers-with-bInterval-5-td4397497.html

Microsoft does not seem to support this with the Windows host
controller driver.
http://msdn.microsoft.com/en-us/library/ff539114(v=VS.85).aspx
“Isochronous transfers on high speed devices support polling period
values of 1, 2, 4, and 8. If a client driver submits a
URB_FUNCTION_ISOCH_TRANSFER request for a high speed
isochronous endpoint with polling period greater than 8 microframes,
the request fails with status USBD_STATUS_INVALID_PARAMETER.”

On the other hand, the USB 2.0 specification says this
(Page 271, Table 9-13).
+++++++++++++++++++++++
bInterval
"Interval for polling endpoint for data transfers.
Expressed in frames or microframes depending on the
device operating speed (i.e., either 1 millisecond or
125 μs units).

For full-/high-speed isochronous endpoints, this value
must be in the range from 1 to 16. The bInterval value
is used as the exponent for a 2^(bInterval-1) value; e.g.,
a bInterval of 4 means a period of 8 (2^(4-1))."
++++++++++++++++++++++++

So binterval of 5 does not violates USB specification yet it
will not work under Windows. Of course it works under
Xbox. And it is also reported to work under Linux.

(What does violate the spec is that there is no alternate setting with
an isoc bandwidth of zero but this is not the point of discussion here).

Is it even possible to make it work under Windows?

The following is the “lsusb -vvv” output.
http://openkinect.org/w/index.php?title=Lsusb_output&oldid=22

Bus 002 Device 013: ID 045e:02ad Microsoft Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x045e Microsoft Corp.
idProduct 0x02ad
bcdDevice 1.00
iManufacturer 1 Microsoft
iProduct 2 Xbox NUI Audio
iSerial 4 A44886D18656039A
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x020c 1x 524 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x0048 1x 72 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered

–
Xiaofan

2

>"Isochronous transfers on high speed devices support polling period

values of 1, 2, 4, and 8.

The isoch transfer DMA schedule is possibly built by MS’s stack as a binary tree - i.e. 2 items with frequency N has 1 parent with frequency N/2.

Interrupt transfer schedule is surely such, isoch is possibly too.

If my guess is correct - then only powers of 2 are supported, and more so: probably “5” actually means “4” and XBox lives with this.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

On Mon, Jun 6, 2011 at 3:35 PM, Maxim S. Shatskih
wrote:
>>"Isochronous transfers on high speed devices support polling period
>>values of 1, 2, 4, and 8.
>
> The isoch transfer DMA schedule is possibly built by MS’s stack as
> a binary tree - i.e. 2 items with frequency N has 1 parent with frequency N/2.
>
> Interrupt transfer schedule is surely such, isoch is possibly too.

Thanks for the explanations.

> If my guess is correct - then only powers of 2 are supported, and more so:
> probably “5” actually means “4” and XBox lives with this.
>

If that is the case, then I think Microsoft will probably keep the stack
as it is and update the Xbox Kinect firmware to use “4” when the Kinect
SDK got released.

On the other hand, can we say that there is no way this device
can work now under Windows (without Microsoft’s future firmware)?

–
Xiaofan

4

>> The isoch transfer DMA schedule is possibly built by MS’s stack as

> a binary tree - i.e. 2 items with frequency N has 1 parent with frequency N/2.
>
> Interrupt transfer schedule is surely such, isoch is possibly too.

Thanks for the explanations.

Sorry, I made a typo:

“2 items with frequency N/2 have 1 parent with frequency N/2”.

The ultimate parent of the whole tree will have the maximum possible frequency, and from it the control and bulk schedule starts.

And each ultimate child of the tree have a frequency of like N/1024, there are up to 1024 such children which are registered in the DMA schedule heads array. The hardware starts the next K’th frame with ( K %1024 )'s ultimate child.

This is how interrupt transfers work, and I think - especially in things like OHCI - isoch too.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

Maxim S. Shatskih wrote:

> "Isochronous transfers on high speed devices support polling period
> values of 1, 2, 4, and 8.
The isoch transfer DMA schedule is possibly built by MS’s stack as a binary tree - i.e. 2 items with frequency N has 1 parent with frequency N/2.

Interrupt transfer schedule is surely such, isoch is possibly too.

If my guess is correct - then only powers of 2 are supported, and more so: probably “5” actually means “4” and XBox lives with this.

We don’t have to guess – Xiaofan correctly quoted the USB spec. The
number in the descriptor is the logarithm base 2 of the period, plus
one. So, Windows accepts values of 1, 2, 3, and 4, which map to polling
periods of 1, 2, 4, and 8 microframes. The Kinect camera specifies a
value of 5, which maps to a period of 16 microframes, which Windows does
not support.

I assume the expectation was that if you didn’t need more than one hit
per frame, you’d just advertise yourself as full-speed instead of
high-speed. That doesn’t help if you also need a fast bulk pipe.

There are ways to work around this in a filter driver by rewriting the
descriptors, to change isochronous to interrupt, or to change the period
from 5 to 4. But the original point is valid – it is fascinating that
Microsoft would itself produce a device that its own mainline operating
systems do not support.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

> There are ways to work around this in a filter driver by rewriting the

descriptors, to change isochronous to interrupt, or to change the period
from 5 to 4. But the original point is valid – it is fascinating that
Microsoft would itself produce a device that its own mainline operating
systems do not support.

Hello,

It seems more reasonable to just change the period from 5 to 4.
From what I have collected from Xiaofan, this filter driver would be a low-level one in kernel-mode, sitting between the bus/host-controller and the device driver (in this case, libusb-win32/libusb0.sys).
I am now investigating some of the filter driver samples that come with the WDDK (7600):
.\src\general\toaster\kmdf\filter\generic
.\src\general\toaster\kmdf\filter\sideband

However, these examples do not modify any descriptor.
Is there another filter driver example in the DDK that redefines endpoint descriptors?
If not, is there some place/document on the subject?

(additional question: would it be possible/plausible to have such low-lever filter driver in user-mode?)

Thanks in advance,
Marcos Slomp

7

xxxxx@gmail.com wrote:

It seems more reasonable to just change the period from 5 to 4.
From what I have collected from Xiaofan, this filter driver would be a low-level one in kernel-mode, sitting between the bus/host-controller and the device driver (in this case, libusb-win32/libusb0.sys).

Well, hold on a moment. Libusb doesn’t care at all about the period.
What failure are you actually seeing? Does the device fail to enumerate?

However, these examples do not modify any descriptor.
Is there another filter driver example in the DDK that redefines endpoint descriptors?

There is no such sample in the WDK. However, I presume you know how to
create and submit an URB to read a descriptor. If so, then you know
what you need to do. You look for IOCTL_INTERNAL_USB_SUBMIT_URB, you
check for descriptor requests, you set a completion routine and forward
it, and in the completion routine you change what was returned from below.

(additional question: would it be possible/plausible to have such low-lever filter driver in user-mode?)

No.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

> Well, hold on a moment. Libusb doesn’t care at all about the period.

What failure are you actually seeing? Does the device fail to enumerate?

The device enumerates fine. The problem is when the
URB (_URB_ISOCH_TRANSFER) is submitted.
The request completes/callback immediately with status:
USBD_STATUS_INVALID_PARAMETER.

There is no such sample in the WDK. However, I presume you know how to
create and submit an URB to read a descriptor. If so, then you know
what you need to do. You look for IOCTL_INTERNAL_USB_SUBMIT_URB, you
check for descriptor requests, you set a completion routine and forward
it, and in the completion routine you change what was returned from below.

Right, so the idea is to intercept “GetDescriptor” requests, parse and
modify the returned byte stream and forward it to the next driver in the
stack (libusb0.sys).
There is only one thing that worries me:
http://msdn.microsoft.com/en-us/library/ff540414(v=vs.85).aspx
“Before the host controller sends an isochronous request to a USB device, it
requires information about the device’s endpoint to which it must send or
receive data. This information is stored in endpoint descriptors
(USB_ENDPOINT_DESCRIPTOR) that are retrieved from the selected configuration
descriptor.”

From this description, it seems that the host controller also
intercepts IOCTL_INTERNAL_USB_SUBMIT_URB
and caches end-point descriptors, when a configuration is selected (which
would be the the first one, always).
Since the host controller driver is the last driver in the stack, a
low-level filter driver would not be able to modify these URBs in time to
“cheat” the HCD.

Anyway, thanks for the advice.
Hopefully I will manage to have some free time tonight to mess around with
it.

Marcos Slomp

On Thu, Jun 9, 2011 at 1:36 AM, Tim Roberts wrote:

> xxxxx@gmail.com wrote:
> >
> > It seems more reasonable to just change the period from 5 to 4.
> > From what I have collected from Xiaofan, this filter driver would be a
> low-level one in kernel-mode, sitting between the bus/host-controller and
> the device driver (in this case, libusb-win32/libusb0.sys).
>
> Well, hold on a moment. Libusb doesn’t care at all about the period.
> What failure are you actually seeing? Does the device fail to enumerate?
>
> > However, these examples do not modify any descriptor.
> > Is there another filter driver example in the DDK that redefines endpoint
> descriptors?
>
> There is no such sample in the WDK. However, I presume you know how to
> create and submit an URB to read a descriptor. If so, then you know
> what you need to do. You look for IOCTL_INTERNAL_USB_SUBMIT_URB, you
> check for descriptor requests, you set a completion routine and forward
> it, and in the completion routine you change what was returned from below.
>
> > (additional question: would it be possible/plausible to have such
> low-lever filter driver in user-mode?)
>
> No.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

9

Marcos Slomp wrote:

There is only one thing that worries me:
http://msdn.microsoft.com/en-us/library/ff540414(v=vs.85).aspx
http:
> “Before the host controller sends an isochronous request to a USB
> device, it requires information about the device’s endpoint to which
> it must send or receive data. This information is stored in endpoint
> descriptors (USB_ENDPOINT_DESCRIPTOR) that are retrieved from the
> selected configuration descriptor.”
>
> From this description, it seems that the host controller also
> intercepts IOCTL_INTERNAL_USB_SUBMIT_URB and caches end-point
> descriptors, when a configuration is selected (which would be the the
> first one, always).
> Since the host controller driver is the last driver in the stack, a
> low-level filter driver would not be able to modify these URBs in time
> to “cheat” the HCD.

When you make a “select configuration” request, one of the parameters in
the URB is a pointer to your configuration descriptor . Now, does the
HCD believe the one you give it, or does it go fetch a new one from the
hardware? I don’t know that, and it’s an experiment well worth trying.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</http:>

10

> When you make a “select configuration” request, one of the parameters in

the URB is a pointer to your configuration descriptor . Now, does the
HCD believe the one you give it, or does it go fetch a new one from the
hardware? I don’t know that, and it’s an experiment well worth trying.

Thanks for the insight.
I try to implement the filter, check that and report back.

On Thu, Jun 9, 2011 at 10:25 AM, Tim Roberts wrote:

> Marcos Slomp wrote:
> >
> > There is only one thing that worries me:
> > http://msdn.microsoft.com/en-us/library/ff540414(v=vs.85).aspx
> > http:
> > “Before the host controller sends an isochronous request to a USB
> > device, it requires information about the device’s endpoint to which
> > it must send or receive data. This information is stored in endpoint
> > descriptors (USB_ENDPOINT_DESCRIPTOR) that are retrieved from the
> > selected configuration descriptor.”
> >
> > From this description, it seems that the host controller also
> > intercepts IOCTL_INTERNAL_USB_SUBMIT_URB and caches end-point
> > descriptors, when a configuration is selected (which would be the the
> > first one, always).
> > Since the host controller driver is the last driver in the stack, a
> > low-level filter driver would not be able to modify these URBs in time
> > to “cheat” the HCD.
>
> When you make a “select configuration” request, one of the parameters in
> the URB is a pointer to your configuration descriptor . Now, does the
> HCD believe the one you give it, or does it go fetch a new one from the
> hardware? I don’t know that, and it’s an experiment well worth trying.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></http:>

11

On Thu, Jun 9, 2011 at 2:52 PM, Marcos Slomp wrote:
>>?When you make a “select configuration” request, one of the parameters in
>>?the URB is a pointer to your configuration descriptor . ?Now, does the
>>?HCD believe the one you give it, or does it go fetch a new one from the
>> hardware? ?I don’t know that, and it’s an experiment well worth trying.
>
> Thanks for the insight.
> I try to implement the filter, check that and report back.
>

I am not so sure if there are any updates about this but Travis has
some doubt whether it is possible to achieve the goal using the
approach Tim mentioned. Travis thinks maybe a bus filter is needed
and then it becomes too complicated.

Is this similar?
http://www.techtalkz.com/microsoft-device-drivers/252717-how-modify-serial-number-usb-device-usb-filter-driver.html

–
Xiaofan

12

> I am not so sure if there are any updates about this but Travis has

some doubt whether it is possible to achieve the goal using the
approach Tim mentioned. Travis thinks maybe a bus filter is needed
and then it becomes too complicated.

Well, I have tried many things and it seems it cannot be done: the HCD can’t
just be fooled by some filter driver that sits between the HCD and the
device driver itself (I am not sure if I did everything properly in my
filter driver, however!).
Since the past three weeks I have been quite busy with a lot of other stuff
and didn’t have spare time to play more with this. :frowning:
Moreover, Microsoft has released the Kinect SDK, so there will be no need
for such palliative amend anymore.

Is this similar?

http://www.techtalkz.com/microsoft-device-drivers/252717-how-modify-serial-number-usb-device-usb-filter-driver.html

I believe it is very similar to this thread.
However, as pointed by Doron Holan:
“you are proposing to write a bus filter driver. quite difficult to do and
completely undocumented and unsupported by microsoft.”
In the case of the Kinect Audio subdevice, we would also need such “bus
filter driver” in order to fool the HCD.

On Sat, Jun 25, 2011 at 2:06 PM, Xiaofan Chen wrote:

> On Thu, Jun 9, 2011 at 2:52 PM, Marcos Slomp wrote:
> >> When you make a “select configuration” request, one of the parameters in
> >> the URB is a pointer to your configuration descriptor . Now, does the
> >> HCD believe the one you give it, or does it go fetch a new one from the
> >> hardware? I don’t know that, and it’s an experiment well worth trying.
> >
> > Thanks for the insight.
> > I try to implement the filter, check that and report back.
> >
>
> I am not so sure if there are any updates about this but Travis has
> some doubt whether it is possible to achieve the goal using the
> approach Tim mentioned. Travis thinks maybe a bus filter is needed
> and then it becomes too complicated.
>
> Is this similar?
>
> http://www.techtalkz.com/microsoft-device-drivers/252717-how-modify-serial-number-usb-device-usb-filter-driver.html
>
>
> –
> Xiaofan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

13

I don’t think a bus filter driver will do any of this either, the host controller talks directly to the hardware, no irps. A bus filter needs to see irps to do its work

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Marcos Slomp
Sent: Friday, June 24, 2011 11:31 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Xbox Kinnect NUI Audio Device under Windows

I am not so sure if there are any updates about this but Travis has
some doubt whether it is possible to achieve the goal using the
approach Tim mentioned. Travis thinks maybe a bus filter is needed
and then it becomes too complicated.
Well, I have tried many things and it seems it cannot be done: the HCD can’t just be fooled by some filter driver that sits between the HCD and the device driver itself (I am not sure if I did everything properly in my filter driver, however!).
Since the past three weeks I have been quite busy with a lot of other stuff and didn’t have spare time to play more with this. :frowning:
Moreover, Microsoft has released the Kinect SDK, so there will be no need for such palliative amend anymore.

Is this similar?
http://www.techtalkz.com/microsoft-device-drivers/252717-how-modify-serial-number-usb-device-usb-filter-driver.html

I believe it is very similar to this thread.
However, as pointed by Doron Holan:
“you are proposing to write a bus filter driver. quite difficult to do and
completely undocumented and unsupported by microsoft.”
In the case of the Kinect Audio subdevice, we would also need such “bus filter driver” in order to fool the HCD.

On Sat, Jun 25, 2011 at 2:06 PM, Xiaofan Chen > wrote:
On Thu, Jun 9, 2011 at 2:52 PM, Marcos Slomp > wrote:
>> When you make a “select configuration” request, one of the parameters in
>> the URB is a pointer to your configuration descriptor . Now, does the
>> HCD believe the one you give it, or does it go fetch a new one from the
>> hardware? I don’t know that, and it’s an experiment well worth trying.
>
> Thanks for the insight.
> I try to implement the filter, check that and report back.
>
I am not so sure if there are any updates about this but Travis has
some doubt whether it is possible to achieve the goal using the
approach Tim mentioned. Travis thinks maybe a bus filter is needed
and then it becomes too complicated.

Is this similar?
http://www.techtalkz.com/microsoft-device-drivers/252717-how-modify-serial-number-usb-device-usb-filter-driver.html

–
Xiaofan

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

14

On Sat, Jun 25, 2011 at 2:31 PM, Marcos Slomp wrote:
> Moreover, Microsoft has released the Kinect SDK, so there will be no need
> for such palliative amend anymore.

Did they just change the firmware and thus change bInterval to 4 or
other acceptable value by Windows USB Stack?

–
Xiaofan

15

> Did they just change the firmware and thus change bInterval to 4 or

other acceptable value by Windows USB Stack?

That is indeed a good question! :slight_smile:
No one from the OpenKinect list reported me this information so far…
I haven’t installed the SDK myself yet, but I will do it next week.
I will let you guys know once I test it.

On Sat, Jun 25, 2011 at 6:26 PM, Xiaofan Chen wrote:

> On Sat, Jun 25, 2011 at 2:31 PM, Marcos Slomp wrote:
> > Moreover, Microsoft has released the Kinect SDK, so there will be no need
> > for such palliative amend anymore.
>
> Did they just change the firmware and thus change bInterval to 4 or
> other acceptable value by Windows USB Stack?
>
> –
> Xiaofan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

16

On Sat, Jun 25, 2011 at 9:52 PM, Marcos Slomp wrote:
>>?Did they just change the firmware and thus change bInterval to 4 or
>> other acceptable value by Windows USB Stack?
>
> That is indeed a good question! :slight_smile:
> No one from the OpenKinect list reported me this information so far…
> I haven’t installed the SDK myself yet, but I will do it next week.
> I will let you guys know once I test it.
>

Most likely yes. I do not have the Kinect Device but I just
installed the beta SDK and the drivers are all based on WinUSB.

–
Xiaofan

17

> Most likely yes. I do not have the Kinect Device but I just

installed the beta SDK and the drivers are all based on WinUSB.

Hmmm… Interesting. I thought that WinUSB did not support isochronous
transfers.

On Sun, Jun 26, 2011 at 11:30 PM, Xiaofan Chen wrote:

> On Sat, Jun 25, 2011 at 9:52 PM, Marcos Slomp wrote:
> >> Did they just change the firmware and thus change bInterval to 4 or
> >> other acceptable value by Windows USB Stack?
> >
> > That is indeed a good question! :slight_smile:
> > No one from the OpenKinect list reported me this information so far…
> > I haven’t installed the SDK myself yet, but I will do it next week.
> > I will let you guys know once I test it.
> >
>
> Most likely yes. I do not have the Kinect Device but I just
> installed the beta SDK and the drivers are all based on WinUSB.
>
>
> –
> Xiaofan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

18

On Sun, Jun 26, 2011 at 10:47 PM, Marcos Slomp wrote:
>> Most likely yes. I do not have the Kinect Device but I just
>> installed the beta SDK and the drivers are all based on WinUSB.
>
> Hmmm… Interesting. I thought that WinUSB did not support isochronous
> transfers.

Sorry the Camera still has its own driver and it should be still using
isochronous transfer. But the Audio, Audio Array and the Device
are based on WinUSB. So they probably use bulk transfer for the
Audio now.

–
Xiaofan

19

> Sorry the Camera still has its own driver and it should be still using

isochronous transfer. But the Audio, Audio Array and the Device
are based on WinUSB. So they probably use bulk transfer for the
Audio now.

Cool! That confirms that they changed/specialized the firmware. :slight_smile:

On Sun, Jun 26, 2011 at 11:58 PM, Xiaofan Chen wrote:

> On Sun, Jun 26, 2011 at 10:47 PM, Marcos Slomp wrote:
> >> Most likely yes. I do not have the Kinect Device but I just
> >> installed the beta SDK and the drivers are all based on WinUSB.
> >
> > Hmmm… Interesting. I thought that WinUSB did not support isochronous
> > transfers.
>
> Sorry the Camera still has its own driver and it should be still using
> isochronous transfer. But the Audio, Audio Array and the Device
> are based on WinUSB. So they probably use bulk transfer for the
> Audio now.
>
>
> –
> Xiaofan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>