|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
216.68.187.168
In Reply to: Question: posted by Crimson on January 22, 2007 at 11:33:58:
Crimson,With USB 2.0 you have more time slots so you can do things better. But there are no USB 2.0 Audio controllers because the various companies paying USB.org are wimpering over what they want in the specification. Stuff like multiple channel, midi crap, you name it... it's like a polical bill going to the house with pork barrel written all over it.
You could use a bulk transfer capable USB 2.0 controller like an ARM9 unit and then write custom drivers for it. But TI showed the results can be kinda of poor because bulk transfer has the lowest priority.
Whereas Audio streaming has the highest.
Follow Ups:
Gordon - isnt' there a way to make bulk transfers a higher priority?Even if they are a low priority, if the blocks are big enough will this not be good enough?
You can make all other processes low priority as well, correct?
Steve,I have used some of these ARM based controllers and tried this out. It is very simple to setup a bulk based system if it resides on a USB link that is not taxed by other things.
Basically what it comes down to is the buffering on the DAC side of things. What I did was use one of these Atmel AT91SAM7S128 which has 64K of SRAM and 128k or program space. IAR.com has a real nice dev kit for it with C eval and a USB JTAG emulator.
Basically what I did was setup 2 endpoints one bulk and one hid. The bulk would fill the buffer to like 75% then the HID would send a wait to the computer until the buffer would fall below 50% then the HID would send a ready.
This worked pretty well but the ap on the mac side would have needed to be written as a driver.
Is it better? well I guess if I wanted to sit around and write PC code all day. I would say a week of work on the mac and I could have had the driver done. Then what about 6 months before getting the PC to work.
There is not way that I know of to increase the priority of any of the USB devices.
Thanks Gordon. I have a friend that will do this for me. I just wanted to understand the pitfalls.
Steve,Sure thing... the Atmel ARM parts are pretty nice. There is a bunch of open source code for them and several modular platforms that have embeded linux in them.
If you need any help just ask.
Thanks Gordon. I was planning to have the driver talk to a TUSB3200. It has lots of buffering features already built-in. What do you think?
Steve,I have the dev system for the TUBS3200 if you want it I would be happy to sell it too you. I only looked at it for a couple of days. Comes with board and stuff. I linked the page below.
The TUSB3200 is better than the TAS1020 as far as doing Streaming Async. Both of these parts require the KEIL "C" compiler to compile the sample code which is basically standard 1.1 audio streaming.
You can change the enumeration code to make these work in any capacity. You may want to get an emulator to do much more than the standard audio stuff.
The thing about the TUSB3200 that's nice is that the clocking is better suited for ASYNC and bulk type transfers. In the TAS1020 there are several gotcha's that don't allow certain things, like slave mode in I2S and MCLK1 in for certain stuff. With the 3200 that is not the case.
I also have a parallel port Xeltek SuperproZ programmer if you need one of these. I bought the more expensive USB one and use that now for everything like PLD's and stuff not compatible with the Z model.
Thanks
Gordon
J. Gordon Rankin
Gordon email with your price on these items.
nugent@empiricalaudio.com
Makes sense.In your previous post you say: 'It is really best not to do this but to take the USB stream and convert it to a logical output to the dac and or filter if you are into that stuff.'
I assume this what you do in your dacs. Is converting the USB datastream to I2S the same thing?
Thanks.
Crimson,Well yes I prefer I2S as this protocol is better in my experience by the WCLK (Word Clock) delay of one clock cycle. This means you can with a really good BCLK (Bit clock) you can over come much of the problems with jitter. Because on I2S the WCLK only enables the latching of data into the dac. BCLK actual does the latching, as well as shifting in each data bit.
But with the new Crimson I am not limited to I2S. It can do any of the protocol's required for what ever dac chip I want to use.
This post is made possible by the generous support of people like you and our sponsors: