Wonder if well ever see sync (0xD or 13) devices Also I think we need more ppl, with DAC that uses usb audio standard, to test out your procedure and my table. 1. It would be interesting to see the results.

For a better experience, please enable JavaScript in your browser before proceeding.

This one at least supports all major windows versions and both 32b and 64b).

Not sure which one, but this is a good first step in determining what the state of affairs is.

So you cant view the endpoint descriptors with it since MD11 is not longer technically on the USB bus.

Otherwise, if its on USB and is an Audio device, than you should be able to view the endpoint descriptors and verify whether async mode is there or not.

You should be able to do the same for MacOS X and linux through cli: cat procbususbdevices or pipe it to grep with a regex for looking for bmAttributes.0x0-95 or async (no idea what the GUI equivalent is).

Interestingly it doesnt seem to have the bmAttributes for endpoints like the utility above.

Te7022L Drivers Doesnt Work

As for MD11, connection it without drivers doesnt work either, since the actual device isnt there, just the bus shows up.

Te7022L Install The Bus

I.e. the audio device only appears after you install the bus drivers and on the Musiland Bus.

Youre also see that one usb device does not necessary have one endpoint (in the case of your prome dac), but you can see the correct one under Endpoint Descriptor section just after the Audio Streaming Format Type Descriptor section.

The md11 is not an actual usb audio device, it implement itself as a bulk transfer device (this mode that typical external HDD, printer use), to control the bus itself.

Some doc: (read the Audio Device Document 1.0 ) Disclaimer: these are posted as my opinions from reading provided documents and some prior knowledge I collected.

The musiland bus the device Ive posted the info file for in the post above.

MS seems to be referring to devices supporting async transfer mode as having the extra endpoint descriptor with the bmAttribs 0x5 (Async) for the isochronous mode.

On the other hand, Musiland ships all the data through their custom bus driver to the device and sorts it out on the other end (presumably the device sends requests for the rate regulation somewhere in there as well.).

But yes, youre right the bus interface driver they made seems the mechanism is no longer the conventional usbaudio.sys type arrangement at all, and hence the bulk data mode (although you get both CRC error detection and delivery guarantee, it doesnt seem like you have a bandwidth guarantee (although if you dont have any data in the buffer (CPU or IO are busy) or your cable is dead, probably doesnt make a lot of difference for either way))) Does that make sense, or am I wrong and should RTM PS the audio arrangement still has to come in at the other end of the Musiland bus, hence me wondering whether you can enumerate the properties for it.

If retransmission of faulty packets is guaranteed and the data is reconstructed on the other end, considering the bus speed, the latency is probably negligible.

Tasty.

So what you said is correct I think, and I have some misunderstanding in my last post, to conclude: All standard usb audio devices are isochronous and whether it is async or not can be determined by this table of bmAttributes values in their respective Audio Data Endpoint Descriptor: - 0x5 b0101: async - 0x9 b1001: adaptive - 0xd b1101: sync Ref: Audio Device Document 1.0 table 4-20.

Ill keep searching.

Also I think we need more ppl, with DAC that uses usb audio standard, to test out your procedure and my table.

It would be interesting to see the results.