Using Interrupt Transfer Type in USB2.0 for audio data transfer
May 16, 2008 at 12:21 AM Thread Starter Post #1 of 8

goodsound

100+ Head-Fier
Joined
May 25, 2005
Posts
290
Likes
11
I have been reading about USB data transfers and my knowledge about that is still in its infancy, so bear with me if its a stupid question, but I still wanted to ask something about the feasibility of using the Interrupt transfer type for realtime audio data transfer.

What I find attractive about Interrupt type transfer (over the unbiquitous Isochronous transfer) is that it has handshake(NAK - if I may use usb terminology) capability, which ischronous does not.
That makes it a viable option to let the device control the flow of data (use external clock). More specifically it can stop the flow of data from the source (PC) until it is ready for more.

Besides that Interrupt transfer in USB2.0 shares the same other advantages of Isochronous i.e. same data payload and guranteed latency.

Are there any devices out there that use Interrupt mode ? If not, then why ? What are the possible issues with this ?
I understand it wasn't a practical option in USB1.1, but in reality who uses 1.1 anymore ?

I posted this on a couple of forums so sorry if you're reading this again.
 
May 16, 2008 at 2:53 AM Post #2 of 8
I am not sure what interrupt type transfer on USB is but it looks like you want two features.

1. External master clock that regulates the flow of data from the PC

2. Reliable data transfer with retransmits

These are two seperate issues. There are USB audio adapters available that support async USB audio mode. In that mode you are still using isochronous transfer but the stream rate from the PC is regulared by a secondary connection back from the sound card to the device. Gordon Rankin has developed this code for his adapters.

If you insist on data integrity you probably will have to resolve to one of the pro interfaces with USB interface. some of these come with custom drivers that use standard data endpoints like a mouse or keyboard.

Cheers

Thomas
 
May 16, 2008 at 3:10 AM Post #3 of 8
Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif
There are USB audio adapters available that support async USB audio mode.


you mean interface chips like those made by TI (TUSB3200) ? those will handle async usb audio transfer without much ado ?
 
May 17, 2008 at 6:53 AM Post #4 of 8
I believe Gordon uses the TAS1020 and those chips do not handle async USB audio mode natively.

It took quite a while to develop the firmware to get this to work.

Cheers

Thomas
 
May 17, 2008 at 2:31 PM Post #5 of 8
as quoted from the specs of TAS1020 and TUSB3200 -

- On-chip adaptive clock generator (ACG) supports asynchronous, synchronous and adaptive synchronization modes for isochronous endpoints
- To support synchronization for streaming USB audio data, the ACG can be used to generate the master clock for the codec


but it still involves writing a driver for using async with these chips ? It almost sounded like this feature was native to the chip and wouldn't require anything else.
 
May 17, 2008 at 5:10 PM Post #6 of 8
well, isn't marketing fun...

These chips support async usb audio in the sense that it is not impossible to make it work.

Search a little for USB async and you will find the many threads over the years where this was discussed in great detail.

Windows, MacOS, and I believe even Linux do support async USB audio in theor native USB audio driver so you do not need any drivers. What was missing was the firmware for the chips to implement that mode.

Cheers

Thomas
 
May 17, 2008 at 9:38 PM Post #7 of 8
I see, so you would need a PIC sort of to go alongwith these chips that adds the 'intelligence' required on the other end. So much for USB being "host driven" where everything is supposedly controlled by the host.

going back to what you said in your first post about "USB audio adapters available that support async USB audio mode" were you referring to these chips only ? or there are ready complete packages available that do all of this ?
 

Users who are viewing this thread

Back
Top