• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

exaU2I - Multi-Channel Asynchronous USB to I2S Interface

Hello,
Thanks for your message on my previous thread.

You don't seem to use USB Audio 2.0 standard, as you don't have OSX compatibilty yet. I'd be happy to know how you made it :)

As a sound engineer, and now also a guy working for major brands of professionnal audio equipment, I can tell that FireWire is DEAD. Even for pro! USB is not dead: just old. USB 3.0 is of some interest. Some.

FireWire was an excellent idea. It (almost) never was correctly implemented. Compatibility issues were paramount. Finally, even Apple ditched it out of most it's products, even Macbook Pros! Developping FireWire equipment now is a nonsense. Its benefits have to be transferred to another technology that has a longer potential life.

USB is the standard. And, if designed correctly, there is no clocking problem. Ask MOTU's designers...

Where we really are heading is convergence. Network. TCP/IP Ethernet.
Just have a look at what Dante for pro audio does, Ethersound is also going native...

Didn't you just said Ethernet a few posts ago?

There is no open protocol for consumer audio streaming over TCP/IP (and especially WiFi). If you can do it, if you can have automatic delay compensation somehow for when the user is looking at videos, then... Then you'd probably better team with a few other guys, and sell a few trucks of these.

NeoY2k,
I agree with your thoughts and I am going to explore the issues of using standard network protocols and controlling latency for video. I was considering streaming the sound data over Ethernet. USB was easier and safer for the first release. I will be moving to USB 3.0 eventually. Right now I can do "only" four channels at 352.8 kHz.
 
where do i sign? you might also drop acko a line as he has full 8 channel es9018 dac kit available shortly. he may offer your solution as part of the range of modules. are you also looking at integrating a digital xo as part of your mcu?

ackolabs

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?
 
Have you tested with other applications, like Windows 7 Media Center, VLC Media Player, or Media Player Classic - Home Cinema?

I'm curious how your drivers handle playback of DVDs and Blu-rays (either BD discs, images or MKV files). If you are going to support multichannel, it obviously needs to support these formats.

How is the device listed in Control panel, does Windows see this as a multichannel device?

Do you have any mixer control. Is it possible to control the volume of individual channels and is there a master volume control?

What about USB2 Audio Class 2.0 drivers? Supported in OSX and Linux. Hopefully Microsoft will support USB2 Audio Class 2.0 in the future. I was holding my breath, but had to exhale.

I am using Foobar and J. River Media Center. Both players can cover almost all lossless audio formats. J. River can play most video formats, including DVD and MKV. Both players can do multichannel audio and automatic sampling rate switching.

I’ve also tested Winamp and Media Monkey. Unfortunately the ASIO output plug-ins for the last two are not very stable. There is also an open source project about ASIO plug-in for Windows Media Player and Windows Media Center. I couldn’t make it work. There are other ASIO capable players out there, I haven't tested them.

It’s a pity that VLC Media Player, and Media Player Classic - Home Cinema have no support for ASIO.

The remaining questions in your post are very important. I need many pages to explain the way ASIO works and the benefits of using ASIO for audiophile-grade multichannel playback. Some of it will be on my website – to be released soon.

I will try to continue my reply to you ASAP.
 
It's seems very interesting. What USB Chip you use on your board? Does your project only support output? I suggest you reference XMOS USB Audio Class 2.0 reference design or C-Media CM6632 USB Audio Class 2.0 reference design. All two company's product can do what you want to do except 352.8K output.
I had some experence in develop USB Audio device driver in windows and Mac. If you need help you can PM me too.

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.
 
Any thoughts of using bulk mode transfer instead of iso-asynch?
That would be a very bad choice. Bulk mode transfer does not guarantee the bandwidth, and thus you would have audio dropouts at any time. Bulk is only appropriate if you wanted to download a music file to a standalone player for later playback, not for real-time playback.

Iso-Asynch is the only choice for audio. If your operating system enables the device, then bandwidth is guaranteed. For Full Speed USB, this is 8.192 Mbps, for High Speed USB, it's something like 200 Mbps. If bandwidth is not available for some reason, then you will get an error message instead of dropped audio.
 
That would be a very bad choice. Bulk mode transfer does not guarantee the bandwidth, and thus you would have audio dropouts at any time. Bulk is only appropriate if you wanted to download a music file to a standalone player for later playback, not for real-time playback.

Iso-Asynch is the only choice for audio. If your operating system enables the device, then bandwidth is guaranteed. For Full Speed USB, this is 8.192 Mbps, for High Speed USB, it's something like 200 Mbps. If bandwidth is not available for some reason, then you will get an error message instead of dropped audio.

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.
 
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
 
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
 
frugal-phile™
Joined 2001
Paid Member
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
 
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.
 
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.
 
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.
 
...
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...
 
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!
:)
 
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?