Head-Fi.org › Forums › Equipment Forums › Dedicated Source Components › Confirming whether your DAC is asynchronous as claimed or not.
New Posts  All Forums:Forum Nav:

Confirming whether your DAC is asynchronous as claimed or not.

post #1 of 36
Thread Starter 
Here's a quick way to verify whether your USB soundcard supports asynchronous transfer mode (or the claim was false advertising or a confused reviewer or confused audiophile reading the review...*cough-160D-cough*)

Source is a microsoft usb audio related doc referring to USB implementation related things you can't generally view without 3rd party tools: http://download.microsoft.com/download/5/7/7/577a5684-8a83-43ae-9272-ff260a9c20e2/USB_Audio_and_Windows.doc

According to the doc - audio devices supporting asynchronous transfer mode should have an extra 'endpoint descriptor' with
'bmAttributes' = 0x5 (USB_ENDPOINT_TYPE_ASYNCHRONOUS)
(the program you use to view the descriptors may use a different symbolic constant description after the constant)

If the device does not support async mode there will be no such descriptor. E.g. here's the log from my Prometheus dac (doesn't support it or claim to support it.) Warning: Spoiler! (Click to show)

port 1 : USB Composite Device


Parameter

Value

Hardware ID

USB\VID_08BB&PID_2707&REV_0100

Setup Class

USB

Class GUID

{36fc9e60-c465-11cf-8056-444553540000}

PDO Name

\Device\USBPDO-9

Service Name

usbccgp


Parameter

Value

Connection Information

ConnectionIndex

0x1

CurrentConfigurationValue

0x1

LowSpeed

FALSE

DeviceIsHub

FALSE

DeviceAddress

0x2

NumberOfOpenPipes

0x1

ConnectionStatus

DeviceConnected

Pipe #0

Endpoint Descriptor

bLength

0x7

bEndpointAddress

0x85 [IN]

bmAttributes

0x3 (USB_ENDPOINT_TYPE_INTERRUPT)

wMaxPacketSize

0x1

bInterval

0xA

Device Descriptor

bLength

0x12

bcdUSB

0x110

bDeviceClass

0x0

bDeviceSubClass

0x0

bDeviceProtocol

0x0

bMaxPacketSize0

0x8

idVendor

0x8BB

idProduct

0x2707

bcdDevice

0x100

iManufacturer

0x1

iProduct

0x2

iSerialNumber

0x0

bNumConfigurations

0x1


Parameter

Value

Configuration Descriptor

bLength

0x9

bDescriptorType

USB_CONFIGURATION_DESCRIPTOR_TYPE

wTotalLength

0xBE

bNumInterfaces

0x3

iConfiguration

0x0

bmAttributes

0x80 ( Bus_Powered )

MaxPower

0x32

Interface Descriptor

bLength

0x9

bInterfaceNumber

0x0

bAlternateSetting

0x0

bNumEndpoints

0x0

bInterfaceClass

0x1 (Audio)

bInterfaceSubClass

0x1 (AUDIOCONTROL)

bInterfaceProtocol

0x0 (INTERFACE_PROTOCOL_UNDEFINED)

iInterface

0x0

Interface Descriptor

bLength

0x9

bInterfaceNumber

0x1

bAlternateSetting

0x0

bNumEndpoints

0x0

bInterfaceClass

0x1 (Audio)

bInterfaceSubClass

0x2 (AUDIOSTREAMING)

bInterfaceProtocol

0x0 (INTERFACE_PROTOCOL_UNDEFINED)

iInterface

0x0

Interface Descriptor

bLength

0x9

bInterfaceNumber

0x1

bAlternateSetting

0x1

bNumEndpoints

0x1

bInterfaceClass

0x1 (Audio)

bInterfaceSubClass

0x2 (AUDIOSTREAMING)

bInterfaceProtocol

0x0 (INTERFACE_PROTOCOL_UNDEFINED)

iInterface

0x0

Endpoint Descriptor

bLength

0x9

bEndpointAddress

0x2 [OUT]

bmAttributes

0x9 (USB_ENDPOINT_TYPE_ISOCHRONOUS)

wMaxPacketSize

0xC0

bInterval

0x1

Interface Descriptor

bLength

0x9

bInterfaceNumber

0x1

bAlternateSetting

0x2

bNumEndpoints

0x1

bInterfaceClass

0x1 (Audio)

bInterfaceSubClass

0x2 (AUDIOSTREAMING)

bInterfaceProtocol

0x0 (INTERFACE_PROTOCOL_UNDEFINED)

iInterface

0x0

Endpoint Descriptor

bLength

0x9

bEndpointAddress

0x2 [OUT]

bmAttributes

0x9 (USB_ENDPOINT_TYPE_ISOCHRONOUS)

wMaxPacketSize

0x60

bInterval

0x1

Interface Descriptor

bLength

0x9

bInterfaceNumber

0x2

bAlternateSetting

0x0

bNumEndpoints

0x1

bInterfaceClass

0x3 (Human Interface Device)

bInterfaceSubClass

0x0 (No Subclass)

bInterfaceProtocol

0x0 (None)

iInterface

0x0

Endpoint Descriptor

bLength

0x7

bEndpointAddress

0x85 [IN]

bmAttributes

0x3 (USB_ENDPOINT_TYPE_INTERRUPT)

wMaxPacketSize

0x1

bInterval

0xA



It would be nice to verify marketing claims of other DACs that claim using async transfer mode.

If you have one and would like to try (on a windows PC):
500


  1. Download and install the free trial of sysnucleus USBTrace http://www.sysnucleus.com/usbtrace_download.html (or any other tool that lets you enumerate USB devices and view detailed property information. This one at least supports all major windows versions and both 32b and 64b)

  2. Disconnect all usb things except for your DAC. (easier to find your DAC in the list, if it's not 'named' in it).

  3. Run USBTrace



    1. Under the 'usb view' tab, 'device view' tab - find the connected USB device (should really be the only one, if you unplugged all the other ones)

    2. In the info window, verify that there's a table with 'Configuration Descriptor'
      where bInterfaceClass is 0x1 (Audio)

    That'd be your usb audio device.




  4. Now look for 'Endpoint Descriptors' tables. 'Endpoint Descriptor'

    (there are a couple)

    1. If you only find ones where:
      bmAttributes is 0x9 Endpoint_synchronous then it looks like your DAC isn't really asynchronous as claimed.

    2. If you find one with:
      bmAttributes = some number and description mentioning asynchronous after it. Then it's your DAC supports and does async transfer. Or at least the USB chip supports it. Not sure which one, but this is a good first step in determining what the state of affairs is.



    This should provide a reliable indication for devices without custom drivers (and probably for most with them). So far I wasn't able to do this with MD11 and its extensive custom drivers, since it installs its own BUS driver, and puts MD11 on the 'Musiland Bus'. So you can't view the endpoint descriptors with it since MD11 is not longer technically on the USB bus. Otherwise, if it's 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 /proc/bus/usb/devices
    or pipe it to grep with a regex for looking for bmAttributes.*=.*0x[0-9]?5 or async
    (no idea what the GUI equivalent is).


Edited by svyr - 3/25/11 at 10:49am
post #2 of 36

USBView is free, get it here http://www.ftdichip.com/Support/Utilities.htm

 

I think for your Musiland, you should try to connect the device without its driver, at least it should handshake with the host and negotiate transmission method then, or I might be wrong.

post #3 of 36
Thread Starter 
Quote:
Originally Posted by thuantran View Post

USBView is free, get it here http://www.ftdichip.com/Support/Utilities.htm

 

I think for your Musiland, you should try to connect the device without its driver, at least it should handshake with the host and negotiate transmission method then, or I might be wrong.


Tried USBView. Thanks. Still works on Win 7 64b. and looks like there's a linux version too.

Here's the log for prome-dac. Interestingly it doesn't seem to have the bmAttributes for endpoints like the utility above. Warning: Spoiler! (Click to show)
Device Descriptor:
bcdUSB: 0x0110
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x08 (8)
idVendor: 0x08BB (Burr-Brown Japan, Ltd.)
idProduct: 0x2707
bcdDevice: 0x0100
iManufacturer: 0x01
0x0409: "Burr-Brown from TI "
iProduct: 0x02
0x0409: "USB Audio DAC "
iSerialNumber: 0x00
bNumConfigurations: 0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed: Full
Device Address: 0x02
Open Pipes: 1

Endpoint Descriptor:
bEndpointAddress: 0x85 IN
Transfer Type: Interrupt
wMaxPacketSize: 0x0001 (1)
bInterval: 0x0A

Configuration Descriptor:
wTotalLength: 0x00BE
bNumInterfaces: 0x03
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0x80 (Bus Powered )
MaxPower: 0x32 (100 Ma)

Interface Descriptor:
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x00
bInterfaceClass: 0x01 (Audio)
bInterfaceSubClass: 0x01 (Audio Control)
bInterfaceProtocol: 0x00
iInterface: 0x00

Audio Control Interface Header Descriptor:
bLength: 0x09
bDescriptorType: 0x24
bDescriptorSubtype: 0x01
bcdADC: 0x0100
wTotalLength: 0x0028
bInCollection: 0x01
baInterfaceNr[1]: 0x01

Audio Control Input Terminal Descriptor:
bLength: 0x0C
bDescriptorType: 0x24
bDescriptorSubtype: 0x02
bTerminalID: 0x01
wTerminalType: 0x0101 (USB streaming)
bAssocTerminal: 0x00
bNrChannels: 0x02
wChannelConfig: 0x0003
iChannelNames: 0x00
iTerminal: 0x00

Audio Control Output Terminal Descriptor:
bLength: 0x09
bDescriptorType: 0x24
bDescriptorSubtype: 0x03
bTerminalID: 0x02
wTerminalType: 0x0301 (Speaker)
bAssocTerminal: 0x00
bSoruceID: 0x03
iTerminal: 0x00

Audio Control Feature Unit Descriptor:
bLength: 0x0A
bDescriptorType: 0x24
bDescriptorSubtype: 0x06
bUnitID: 0x03
bSourceID: 0x01
bControlSize: 0x01
bmaControls[0]:
01
bmaControls[1]:
02
bmaControls[2]:
02
iFeature: 0x00

Interface Descriptor:
bInterfaceNumber: 0x01
bAlternateSetting: 0x00
bNumEndpoints: 0x00
bInterfaceClass: 0x01 (Audio)
bInterfaceSubClass: 0x02 (Audio Streaming)
bInterfaceProtocol: 0x00
iInterface: 0x00

Interface Descriptor:
bInterfaceNumber: 0x01
bAlternateSetting: 0x01
bNumEndpoints: 0x01
bInterfaceClass: 0x01 (Audio)
bInterfaceSubClass: 0x02 (Audio Streaming)
bInterfaceProtocol: 0x00
iInterface: 0x00

Audio Streaming Class Specific Interface Descriptor:
bLength: 0x07
bDescriptorType: 0x24
bDescriptorSubtype: 0x01
bTerminalLink: 0x01
bDelay: 0x00
wFormatTag: 0x0001 (PCM)

Audio Streaming Format Type Descriptor:
bLength: 0x11
bDescriptorType: 0x24
bDescriptorSubtype: 0x02
bFormatType: 0x01
bNrChannels: 0x02
bSubframeSize: 0x02
bBitResolution: 0x10
bSamFreqType: 0x03
tSamFreq[1]: 0x007D00 (32000 Hz)
tSamFreq[2]: 0x00AC44 (44100 Hz)
tSamFreq[3]: 0x00BB80 (48000 Hz)

Endpoint Descriptor:
bEndpointAddress: 0x02 OUT
Transfer Type: Isochronous
wMaxPacketSize: 0x00C0 (192)
wInterval: 0x0001
bSyncAddress: 0x00

Audio Streaming Class Specific Audio Data Endpoint Descriptor:
bLength: 0x07
bDescriptorType: 0x25
bDescriptorSubtype: 0x01
bmAttributes: 0x00
bLockDelayUnits: 0x02
wLockDelay: 0x0200

Interface Descriptor:
bInterfaceNumber: 0x01
bAlternateSetting: 0x02
bNumEndpoints: 0x01
bInterfaceClass: 0x01 (Audio)
bInterfaceSubClass: 0x02 (Audio Streaming)
bInterfaceProtocol: 0x00
iInterface: 0x00

Audio Streaming Class Specific Interface Descriptor:
bLength: 0x07
bDescriptorType: 0x24
bDescriptorSubtype: 0x01
bTerminalLink: 0x01
bDelay: 0x00
wFormatTag: 0x0001 (PCM)

Audio Streaming Format Type Descriptor:
bLength: 0x11
bDescriptorType: 0x24
bDescriptorSubtype: 0x02
bFormatType: 0x01
bNrChannels: 0x01
bSubframeSize: 0x02
bBitResolution: 0x10
bSamFreqType: 0x03
tSamFreq[1]: 0x007D00 (32000 Hz)
tSamFreq[2]: 0x00AC44 (44100 Hz)
tSamFreq[3]: 0x00BB80 (48000 Hz)

Endpoint Descriptor:
bEndpointAddress: 0x02 OUT
Transfer Type: Isochronous
wMaxPacketSize: 0x0060 (96)
wInterval: 0x0001
bSyncAddress: 0x00

Audio Streaming Class Specific Audio Data Endpoint Descriptor:
bLength: 0x07
bDescriptorType: 0x25
bDescriptorSubtype: 0x01
bmAttributes: 0x00
bLockDelayUnits: 0x02
wLockDelay: 0x0200

Interface Descriptor:
bInterfaceNumber: 0x02
bAlternateSetting: 0x00
bNumEndpoints: 0x01
bInterfaceClass: 0x03 (HID)
bInterfaceSubClass: 0x00
bInterfaceProtocol: 0x00
iInterface: 0x00

HID Descriptor:
bcdHID: 0x0100
bCountryCode: 0x00
bNumDescriptors: 0x01
bDescriptorType: 0x22
wDescriptorLength: 0x0024

Endpoint Descriptor:
bEndpointAddress: 0x85 IN
Transfer Type: Interrupt
wMaxPacketSize: 0x0001 (1)
bInterval: 0x0A

I don't know if you just look for async and hope for the best, or use the other app...


As for MD11, connection it without drivers doesn't work either, since the actual device isn't there, just the bus shows up. I.e. the audio device only appears after you install the bus drivers and on the 'Musiland Bus' Warning: Spoiler! (Click to show)
Device Descriptor:
bcdUSB: 0x0200
bDeviceClass: 0xFF
bDeviceSubClass: 0xFF
bDeviceProtocol: 0xFF
bMaxPacketSize0: 0x40 (64)
idVendor: 0x04B4 (Cypress Semiconductor)
idProduct: 0x5011
bcdDevice: 0x0000
iManufacturer: 0x01
0x0409: "MUSILAND"
iProduct: 0x02
0x0409: "MD11"
iSerialNumber: 0x00
bNumConfigurations: 0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x00
Device Bus Speed: High
Device Address: 0x02
Open Pipes: 0

Configuration Descriptor:
wTotalLength: 0x0020
bNumInterfaces: 0x01
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0x40 (Self Powered )
MaxPower: 0x00 (0 Ma)

Interface Descriptor:
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x02
bInterfaceClass: 0xFF
bInterfaceSubClass: 0xFF
bInterfaceProtocol: 0xFF
iInterface: 0x00

Endpoint Descriptor:
bEndpointAddress: 0x02 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x00

Endpoint Descriptor:
bEndpointAddress: 0x04 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x00
[/quote]

Meh, I very much doubt they wrote a custom bus driver and custom audio device drivers not have async transfer as claimed biggrin.gif
Still, for the curious out there, there's probably some app that enumerates any device attributes in a similar way USBView and the like do for USB?

Edited by svyr - 3/25/11 at 10:26pm
post #4 of 36

 

hum, it is there. For your prome dac it is isochronous transfer mode and for md11 it uses bulk transfer mode for its bus. isochronous can be adaptive, sync, or async and bulk is async. You're 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:

http://www.beyondlogic.org/usbnutshell/usb4.shtml

 

http://www.usb.org/developers/devclass_docs (read the Audio Device Document 1.0)

 

Disclaimer: these are posted as my opinions from reading provided documents and some prior knowledge I collected. They might be wrong so correct me if I was.

 

EDIT: Correction.


Edited by thuantran - 3/26/11 at 2:32am
post #5 of 36
Thread Starter 
Quote:
Originally Posted by thuantran View Post

hum, it is there. For your prome dac it is isochronous transfer mode and for md11 it uses bulk transfer mode for its bus. isochronous or adaptive is sync and bulk is async. You're 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:

http://www.beyondlogic.org/usbnutshell/usb4.shtml

 

http://www.usb.org/developers/devclass_docs (read the Audio Device Document 1.0)

 

Disclaimer: these are posted as my opinions from reading provided documents and some prior knowledge I collected. They might be wrong so correct me if I was.


When you have the drivers installed, MD11 comes up as an audio device on the 'musiland bus'.

The musiland bus the device I've posted the info file for in the post above.

I think it's just a different way of implementing async. 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, you're 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 doesn't seem like you have a bandwidth guarantee (although if you don't have any data in the buffer (CPU or IO are busy) or your cable is dead, probably doesn't make a lot of difference for either way)))

Does that make sense, or am I wrong and should RTM biggrin.gif ?

PS the audio arrangement still has to come in at the other end of the Musiland bus biggrin.gif, hence me wondering whether you can enumerate the properties for it. (then again, it may well be a bulk data mode device with in endpoints... That would make sense)...If it's not a bidirectional mode...some sort of polling?

PSS sort of looks like using bulk mode is a good idea. 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?
Edited by svyr - 3/26/11 at 2:32am
post #6 of 36

What I meant by "actual usb audio device" was the md11 didn't follow standard, it they had been the md11 would have used the standard usb audio driver. 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.
 
usbview indeed doesn't show enough information, we need a free tool without installation hassle for that. I'll keep searching. Also I think we need more ppl, with DAC that uses usb audio standard, to test out your procedure and my table.

Edited by thuantran - 3/26/11 at 2:35am
post #7 of 36
Thread Starter 
Quote:
Originally Posted by thuantran View Post

What I meant by "actual usb audio device" was the md11 didn't follow standard, it they had been the md11 would have used the standard usb audio driver. 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.
 
usbview indeed doesn't show enough information, we need a free tool without installation hassle for that. I'll keep searching. Also I think we need more ppl, with DAC that uses usb audio standard, to test out your procedure and my table.

Cheers smily_headphones1.gif , that sounds fine to me and the table looks good (some chip related docs e.g. http://code.google.com/p/goddac/downloads/detail?name=doc32139.pdf (nice read too, although a bit old) suggested async was 0x5 as well (not that they'd be an overriding authority to the usb standards docs biggrin.gif ) Thanks for the link to that one. Wonder if we'll ever see sync (0xD or 13) devices biggrin.gif


>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 biggrin.gif
Edited by svyr - 3/26/11 at 2:41am
post #8 of 36
USB Prober log for the Tenor TE7022L chip:

Audio Class Specific Audio Data Format
Audio Stream Format Type Desc.
Format Type: 1 PCM
Number Of Channels: 2 STEREO
Sub Frame Size: 2
Bit Resolution: 24
Sample Frequency Type: 0x04 (Discrete)
Sample Frequency: 32000 Hz
Sample Frequency: 44100 Hz
Sample Frequency: 48000 Hz
Sample Frequency: 96000 Hz
Endpoint 0x03 - Isochronous Output
Address: 0x03 (OUT)
Attributes: 0x09 (Isochronous adaptive data endpoint)
Max Packet Size: 388
Polling Interval: 1 ms
post #9 of 36
Thread Starter 
Quote:
Originally Posted by leeperry View Post

USB Prober log for the Tenor TE7022L chip:

Audio Class Specific Audio Data Format
Audio Stream Format Type Desc.
Format Type: 1 PCM
Number Of Channels: 2 STEREO
Sub Frame Size: 2
Bit Resolution: 24
Sample Frequency Type: 0x04 (Discrete)
Sample Frequency: 32000 Hz
Sample Frequency: 44100 Hz
Sample Frequency: 48000 Hz
Sample Frequency: 96000 Hz
Endpoint 0x03 - Isochronous Output
Address: 0x03 (OUT)
Attributes: 0x09 (Isochronous adaptive data endpoint)
Max Packet Size: 388
Polling Interval: 1 ms

10x. I presume that's from 160D and so it's indeed adaptive mode. (same goes for ADG NFB-10 which uses the same chip).

I really want to see the results for audio-gd digital interface DI which I think also uses TE7022 but claims async.
Edited by svyr - 3/27/11 at 5:05am
post #10 of 36
I've got a contact at Galaxy Corp(who bought Tenor), and that's his reply for TE7022L:

"On 7/28/10, ***** Wang (***@gfec.com.tw) wrote:
> isochronous adaptive mode

They have a newer chip that does 24/192(TE8802L) and can work both in adaptive or async, but it does require proprietary drivers for the latter. And tbh, they have made ASIO/KS drivers for TE7022L that are utterly crappy IME(and also others)...it's a glitching feast \o/ Proprietary drivers simply never work as they should.
Edited by leeperry - 3/27/11 at 5:15am
post #11 of 36
Thread Starter 
Quote:
Originally Posted by leeperry View Post

I've got a contact at Galaxy Corp(who bought Tenor), and that's his reply for TE7022L:

"On 7/28/10, ***** Wang (***@gfec.com.tw) wrote:
> isochronous adaptive mode

They have a newer chip that does 24/192(TE8802L) and can work both in adaptive or async, but it does require proprietary drivers for the latter. And tbh, they have made ASIO/KS drivers for TE7022L that are utterly crappy IME(and also others)...it's a glitching feast \o/ Proprietary drivers simply never work as they should.

It'd be funny if DI uses TE7022L, sticks a dummy memory chip that's not used and calls it async. Looks to me more like a re-clocking http://www.audio-gd.com/Pro/dac/USBface/Digital1EN.htm http://www.audio-gd.com/Pro/dac/USBface/DI5.jpg (http://www.audio-gd.com/Pro/dac/USBface/DI4.jpg and on that one the clock looks to be relating to Coax only)
FYI, I've also seen ASIO drivers for TE7022L http://www.ab-system.hk/USB.html . Guess it might work with 160D and NFB-10WM
PS does the TE8802L also not support 88.2khz?

>it's a glitching feast \o/ Proprietary drivers simply never work as they should

Wonder if the driver-less async mode implementations aren't full of bugs as well... Except bugs in firmware.

I'm also wondering whether Endpoints depend on the current firmware, or are hardware specific (in which case all tenor chip products claiming async USB are FoS). Maybe you could ask Cedric biggrin.gif
Edited by svyr - 3/27/11 at 6:23am
post #12 of 36

I think the reason they say the TE8802L requires a driver is because it supports 24/192 which is USB audio class 2, I guess (haven't read the spec if available). MS USB audio driver is class 1 and supports 24/96 top in whatever transfer mode.

 

BTW, svyr, you don't have your D100 anymore? It uses the TAS1020B IIRC, so we can check it out.

post #13 of 36

 

Originally Posted by svyr View Post

It'd be funny if DI uses TE7022L, sticks a dummy memory chip that's not used and calls it async. Looks to me more like a re-clocking http://www.audio-gd.com/Pro/dac/USBface/Digital1EN.htm http://www.audio-gd.com/Pro/dac/USBface/DI5.jpg (http://www.audio-gd.com/Pro/dac/USBface/DI4.jpg and on that one the clock looks to be relating to Coax only)
FYI, I've also seen ASIO drivers for TE7022L http://www.ab-system.hk/USB.html . Guess it might work with 160D and NFB-10WM
PS does the TE8802L also not support 88.2khz?

>it's a glitching feast \o/ Proprietary drivers simply never work as they should

Wonder if the driver-less async mode implementations aren't full of bugs as well... Except bugs in firmware.

I'm also wondering whether Endpoints depend on the current firmware, or are hardware specific (in which case all tenor chip products claiming async USB are FoS). Maybe you could ask Cedric biggrin.gif
 


Can't comment on drivers-free async chips, they're too pricey and I'm a WM8804 fanboy anyway.

 

No idea what the RAM chip in the DI does, only Kingwa knows...but TE7702L is not async. AFAIK, the reclocking takes place in the Cyclon II DSP and it's not documented whatsoever.

 

Cedric has clearly told me that he doesn't give a damn about bug reports and won't provide tech support to end-users. His semi-working ASIO drivers are the least of his worries...they're just here to look good in the datasheet.


Edited by leeperry - 3/27/11 at 10:55am
post #14 of 36
Thread Starter 
>I think the reason they say the TE8802L requires a driver is because it supports 24/192 which is USB audio class 2

+1


>BTW, svyr, you don't have your D100 anymore? It uses the TAS1020B IIRC, so we can check it out.

nope, apc is sending me a replacement. Should be here some time next week. It doesn't claim to by async anyway, but I suppose it'd be interesting to see whether there's an endpoint for it since some people have implemented async using it?


> Cedric has clearly told me that he doesn't give a damn about bug reports and won't provide tech support to end-users. His semi-working ASIO drivers are the least of his worries...they're just here to look good in the datasheet.

Never been able to find the datasheets for TE chips anyway... Dodgiest chip manufacturer in the world biggrin.gif
post #15 of 36

 

Originally Posted by svyr View Post

Never been able to find the datasheets for TE chips anyway... Dodgiest chip manufacturer in the world biggrin.gif

 

Their only competition is the crummy sounding PCM2704, and once reclocked TE7022L does sound amazing to my ears.

 

Also, TE8802L is backward compatible and can do 24/96 w/o drivers...prolly 88.2 as well, but this freq might require drivers, not sure.


Edited by leeperry - 3/27/11 at 4:09pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Dedicated Source Components
Head-Fi.org › Forums › Equipment Forums › Dedicated Source Components › Confirming whether your DAC is asynchronous as claimed or not.