exaU2I - Multi-Channel Asynchronous USB to I2S Interface

[qusp]

Originally Posted by exa065

My website will be released soon.

For now I will stay focused on the interface - driver and hardware to get the data delivered to a DAC.

My understanding is that the digital XO is usually a plug-in for the player - for example Foobar. Do you want to see the XO as a plug-in for the ASIO driver? What would be the reason for that?

i'm talking about hardware in the form of a dsp before the dac. software is all well and good and can work very well, but i would like to see more native hardware solutions either before or as part of the dac. the foobar plugin is very basic

[qusp]

i would also suggest after looking at your board that perhaps in a revision you provide an easy way of supplying your own regulation/power. us diyers often have our own favorites. also the smd micro bnc connectors from hirose are excellent for hispeed impedance controlled interconnects

[planet10]

Originally Posted by NeoY2k

Finally, even Apple ditched it out of most it's products, even Macbook Pros!

That is not true. The only Macs without FW800 are MacBook (probably to be deep sixed with the next laptop rev in March because no FW has pushed a lot of people to the MacBookPro 13" and the Airs are taking the rest), and the MacBook Air. But the MacBook Air have only USB, miniDisplayPort & a headphone jack to keep them tiny.

And even if you have a USB DAC, FW is a good idea for a music server, as it seems for best performance, the DAC should not be on the same bus as the system/player or the bus used for the DAC.

dave

[rsdio]

Originally Posted by qusp

i'm talking about hardware in the form of a dsp before the dac. software is all well and good and can work very well, but i would like to see more native hardware solutions either before or as part of the dac. the foobar plugin is very basic

This is a very good idea. TMS320 or SHARC would make an excellent XO, or anything else. It also reduces the load on both the PC and the interface bandwidth. DSP chips are designed to handle real-time calculations like this, so why ask your general purpose PC to handle the task if it might cause dropouts.

[rsdio]

Originally Posted by glt

The Musiland driver is bulk mode and it is good for 24/192. When you have plenty of bandwidth then bulk mode guarantees data delivery.

When you say "Bulk mode guarantees data delivery," you're only looking at half the picture. Bulk endpoints do not guarantee the timing of delivery. With Bulk hacked for audio use, all it takes is for some unwitting user to plug in a High Speed USB hard drive and then you get audio dropouts. That's because there's no way for the system to prioritize one Device's Bulk transfers over another. Sure, with Bulk, the data will eventually get there, but there is absolutely no guarantee that you won't get a dropout. This is not a professional design. The only way to fix Bulk is to use substantially more FIFO, which increases the latency of the audio, and even then you cannot be sure that you won't get a dropout unless the FIFO and latency are 80 minutes long (i.e. a full-length CD).

In contrast, Isochronous endpoints guarantee that the data will be delivered on time. The only way for this to fail is if your USB host cannot keep up with the timing, or if there are serious transmission problems with your USB hardware. If the host cannot keep up with the timing, then you're going to get dropouts whether you use Bulk or Isochronous, so how can Bulk have the advantage? In the second example, I am not aware of any USB devices where there are actually any errors in data transmission. Don't forget that Isochronous still has multiple bytes of CRC, so there is no way for a data transmission error to go undetected. The only thing that Isochronous sacrifices is automatic retransmission, but that still does not preclude manual retransmission.

Basically, I refer you to the USB Specification, where they made it perfectly clear that Isochronous is appropriate for real-time audio, and Bulk is appropriate for off-line storage. If you want an Audio device based on Bulk, then you're talking about a serious hack, which is not surprising from a cheap Chinese product.

[tdtsai]

Originally Posted by exa065

Thanks for offering help. OS X seems to be a hot topic. For now I have to go one step at the time.

The project supports only outputs. It is meant for high-end music playback.

I am using a FTDI USB. I am not using any third party reference designs – the hardware (FPGA core) is designed in-house from scratch.

If you use FTDI USB, I guess you use Bulk transfer to transfer audio data. And your device can't support USB Audio Class 2.0 or USB Audio Class 1.0. Because by USB Audio Class define audio data is transfer by ISO endpoint.
The two company(XMOS and C-Media) provide USB Audio Class 2.0 chip. It is supported by Windows/Mac/Linux. I has CM6610/CM6620/CM6631 demo boards. And I had an beta version of C-Media's USB Audio Class 2.0 device driver. It can function very well in XP/Vista/Win7. And C-Media also claim their USB Audio Class 2.0 chip also supported in Mac OS 10.5.7 and later version. Because in Mac OS 10.5.7 and later version native support USB Audio Class 2.0.
The C-Media beta driver don't support ASIO now. And the beta driver in windows XP don't support SPDIF Out AC3 RAW data. The beta driver seems defferent with Onkyo's P-3000R driver. Because Onkyo's P-3000R had support ASIO and in Windows XP can support SPDIF Out AC3 RAW data.
I had use RMAA to test CM6631 demo board(Loop SpeakerOut to LineIn) performance in Windows 7. The SNR is about -115dB and THD+N is about -110dB~-105dB. So I think maybe you can reference their design to do it.

[glt]

Originally Posted by rsdio

...
Basically, I refer you to the USB Specification, where they made it perfectly clear that Isochronous is appropriate for real-time audio, and Bulk is appropriate for off-line storage. If you want an Audio device based on Bulk, then you're talking about a serious hack, which is not surprising from a cheap Chinese product.

Just because some company has developed a bulk mode driver doesn't make that a "hack" or "cheap" or "unprofessional".

I've read the specs and perfectly understand iso-adaptive, iso-asynch and bulk. Basically between iso-asynch and bulk you are trading off guaranteed bandwidth with guaranteed data delivery. As you point out you get automatic retry with bulk in case data is lost or corrupted beyond CRC repair.

Regarding your comment about "all it takes is for some unwitting user to plug in a High Speed USB hard drive and then you get audio dropouts." Well that user is me and I've been using this device to play all sample rates up to 192K. I also have a usb mouse connected to it and use the computer for other things while playing music...

[AR2]

This is absolutely great project, and something of great interest for myself. I am in the middle of designing new active 4 way system and I have been researching a lot on the subject. I do like many aspects of this project. I will be using ESS chip as well. Here are few suggestions:

1. Definitely OSX support. Right now Macs are standard for Music production and it will be really loss for you to lose that part of the market. On the consumer side, with iPhone, iPad, iPod and Mac laptops having almost no competition in the market I do not see reason why not develop for system this all is based on. I certainly do not want to derail the discussion here, and I would gladly discourage anyone going into that direction, but if one is unclear who is the market driver and where things are going than just compare revenue numbers. In 2003 MS had 400 times bigger revenue than Apple. In 2010 the ratio is 1:3 MS vs Apple.

2. FW support - would be great and very much appreciated. Dismissal of FW is nonsense. Check RME - one of the best companies for audio interfaces, they just keep plugging new products based on FW.

3. ASIO drivers - Yes, perfect!

4. Crossover modules - YES but please do not tie it to one or two players. Right now Foobar is big, but why lock yourself to a player? Why not just VST plug in that can be applied on the top of the system in something like Console, or anything that support VST, and that includes Foobar. That way many people using iTunes could utilize it as well. I mean that just enlarges your market, which I am sure you would not refuse, besides many that will jump to argue against iTunes.

5. Crossover - There are two good software products out there on the market. Allocator, that supports ASIO and is very, very good product, stable and already mature. It has disadvantage that does not have measurement included and automatic linearization that has to be done manually. It does have great feature of importing measurement files and than it uses that for further adjustment and linearization. The second product is Ultimate EQ by Bodzio Software. The same software developer for Sound Easy. Conceptually very good program solidly based on outstanding measurement and design speaker software. The way how they approach to XO concept is the best. Unfortunately there is no ASIO support and is currently I believe meant only for 48KHz. They are in the middle of development of full commercial version and it is to be seen what they will come out with.
If one is to develop XO software than it has to include measurement and it's linearization implementation. Without that it is really not a real thing. Add on top room equalization as well. So my advice is to look into these two products and incorporate their best features in order to make really good Xover.

6. Lastly - stand alone DSP, would be great that could support all the processing for XO, linearization and room correction, and with that phase perfect.

Best luck with your development, and I assigned myself to the waiting list!

[AR2]

Originally Posted by qusp

i would also suggest after looking at your board that perhaps in a revision you provide an easy way of supplying your own regulation/power. us diyers often have our own favorites. also the smd micro bnc connectors from hirose are excellent for hispeed impedance controlled interconnects

One more vote for smd micro bnc connectors!

[rsdio]

Originally Posted by tdtsai

If you use FTDI USB, I guess you use Bulk transfer to transfer audio data. And your device can't support USB Audio Class 2.0 or USB Audio Class 1.0. Because by USB Audio Class define audio data is transfer by ISO endpoint.

That's a good point, but it depends upon which FTDI chip is used. Many of the FTDI Chips support Isochronous data transfer modes, including the FT232B and FT245B. They also have the Vinculum programmable USB 2 controller, which should be able to handle anything.
It would be helpful to know which chip is being used in this product. exa?