Really? Mine (2010) has FW800, all current Macbook Pros have FW800, the Minis have FW800 (FW800 is back-compatible to FW400).
FW is processor independent, manages itself, and needs no CPU cycles. Any two FW devices can talk to each other (ie , no computer need be involved, Camcorder direct to Hard Drive, for example).
Compatibility? Easy to solve. There was a bad chip some lowest-cost producers of peripherals tried to use that did not follow the IEEE 1394 protocol. Such a chip would be junk in any application (nor is it a "Firewire" chip since to use that trademark instead of IEEE 1394, you needed to comply with Apple's spec fully, amongst other things).
Check to see that your product used the Oxford chipset. Yes? No problems. Next ...
Many of the issues with audio and USB centre around the need for USB to be managed by the CPU. There is no need for asynchronous FW, there is a (perceived) need for async USB, so there must be a problem to solve.
USB is good, but far from perfect, and I see a lot of effort solving problems that should not exist in the first place.
That is not to say that FW should be the solution, but to say "it's dead" without understanding why it was the first choice for audio in the first place isn't helpful.
It was developed specifically for Audio and Video data transport, while USB was developed to be as versatile as possible, the spec incorporating many features intended to interface other products that specifically harm the integrity of audio data streams.
Now, we get to solve them because it's $3 cheaper a box for a USB chip than a FW chip. Async USB to I2S costs less than $3 to implement, right? So no need for FW then.
Last edited:
Eventually we will develop Linux drivers. It depends on the demand for the board. At the present time we try to understand what feature are in demand.
For the next revision I will have the option for external power supply.
I had the option and I removed it. In my opinion the benefit will be purely psychological. I've already cleaned the power for the sensitive circuits.
Micro BNC can be a add-on board for the current design. Would that be OK?
Hi exaU2I,
It looks very interesting, however I have a few questions:
1. Is the ASIO driver protocol 2.1?
2. Is it multi-client capable ie, can you use it with 2 applications (player + VST host - like plogue bidule or cubase) at the same time? This is very important for DRC.
3 Is the hardware working with other USB ASIO drivers like CEntrance or Ploytec?
Thank you.
It looks very interesting, however I have a few questions:
1. Is the ASIO driver protocol 2.1?
2. Is it multi-client capable ie, can you use it with 2 applications (player + VST host - like plogue bidule or cubase) at the same time? This is very important for DRC.
3 Is the hardware working with other USB ASIO drivers like CEntrance or Ploytec?
Thank you.
I have no thoughts at all about changing the USB implementation. I am happy with it - why should I change it? I’ve taken the road less travelled and I arrived on time.
exaU2I won’t get any better if I change the USB mode. It will get worse. I will focus on drivers / software improvements after I release the product.
Om my ES9018 DAC I use the chip default settings for everything. The goal was wide compatibility with Sabre32 and other DACs.
The ASIO implementation supports playback only. I am not sure which ASIO 2.1 functions affect playback. If there is something missing for your applications within we should be able to add it.
The driver is not multi-client capable. I've used ReaRoute to chain VST hosts. The driver worked fine with Reaper. Please contact me to discuss your configuration.
exaU2I is a piece of proprietary hardware. It won't work with any other drivers. I guess there is a price to pay if you want top performance. You get the multichannel bit-perfect 32 bit / 352.8kHz, the jitter elimination techniques and the galvanic isolation. You loose wide compatibility.
exaU2I is an alternative device. It deliverers top performance but it does things differently.
Guys,
I cannot be of any help on the FireWire vs. USB discussion. There is more than one way to skin a cat. In my opinion there aren’t any technological limitations in my USB implementation. Nothing will change in the output I2S stream if I use FireWire. It is a matter of convenience and compatibility to use one or the other. I admit FireWire is cool.
Regarding the various USB modes of operation – this discussion is relevant for traditional USB implementations. I don’t rely on the USB to do any synchronization. I have a proprietary solution. What matters is that exaU2I is the host, and the PC is the slave. Maybe that’s why I did it with a PC. I don’t want to enslave Macs.
So exaU2I (the FPGA core) controls the data flow over USB. Later it may be over FireWire. The FPGA makes sure that USB data has arrived and is uncorrupted in the exaU2I memory buffer. The FPGA makes sure that the buffer never gets empty. If Windows is terribly busy, sometimes the buffer does get empty. For cases like that I have an LED light to indicate an error. A parallel FPGA process reads the memory buffer, clocks the data with one of the two low-jitter quartz oscillators and sends it out in I2S format. This process will go well if the input stream transport (USB or something fancy) is faster than the output stream.
With other words I am confident I don’t need to reconsider the USB mode of operation or the use of alternative transport because I know that I can fill up the buffer faster than it is emptied. Remember these high-school math problems: “A swimming pool is filled up by one pipe delivering X litters per second and drained out by 3 drain pipes taking out Y litters per second. Calculate how long will take before the pool gets empty.” I just solved one of these math problems.
For the benefits of the users that are interested to try the coming release of exaU2I we should focus on the use of the device. How are you going to use it guys? What DAC boards do you have?
Is anybody listening to multichannel 192 kHz recordings? That’s how I use the device. I have Fubar2000 and J. RiverMedia Center. I use an old-fashioned PC because I know how to make it to do anything. The only thing I care about is sound quality. I use 4 speakers and I mix 5.1 and 7.1 to quarto. One day I will build the remaining four speakers. I am really excited about multichannel; there are recordings out there that are mixed in 5.1 with the audiophile in mind. Stereo is not the ultimate thing for me any more. Of course I listen to stereo 44.1 kHz recordings but I don’t up-mix stereo and I don’t up-sample.
Cheers,
exa
I cannot be of any help on the FireWire vs. USB discussion. There is more than one way to skin a cat. In my opinion there aren’t any technological limitations in my USB implementation. Nothing will change in the output I2S stream if I use FireWire. It is a matter of convenience and compatibility to use one or the other. I admit FireWire is cool.
Regarding the various USB modes of operation – this discussion is relevant for traditional USB implementations. I don’t rely on the USB to do any synchronization. I have a proprietary solution. What matters is that exaU2I is the host, and the PC is the slave. Maybe that’s why I did it with a PC. I don’t want to enslave Macs.
So exaU2I (the FPGA core) controls the data flow over USB. Later it may be over FireWire. The FPGA makes sure that USB data has arrived and is uncorrupted in the exaU2I memory buffer. The FPGA makes sure that the buffer never gets empty. If Windows is terribly busy, sometimes the buffer does get empty. For cases like that I have an LED light to indicate an error. A parallel FPGA process reads the memory buffer, clocks the data with one of the two low-jitter quartz oscillators and sends it out in I2S format. This process will go well if the input stream transport (USB or something fancy) is faster than the output stream.
With other words I am confident I don’t need to reconsider the USB mode of operation or the use of alternative transport because I know that I can fill up the buffer faster than it is emptied. Remember these high-school math problems: “A swimming pool is filled up by one pipe delivering X litters per second and drained out by 3 drain pipes taking out Y litters per second. Calculate how long will take before the pool gets empty.” I just solved one of these math problems.
For the benefits of the users that are interested to try the coming release of exaU2I we should focus on the use of the device. How are you going to use it guys? What DAC boards do you have?
Is anybody listening to multichannel 192 kHz recordings? That’s how I use the device. I have Fubar2000 and J. RiverMedia Center. I use an old-fashioned PC because I know how to make it to do anything. The only thing I care about is sound quality. I use 4 speakers and I mix 5.1 and 7.1 to quarto. One day I will build the remaining four speakers. I am really excited about multichannel; there are recordings out there that are mixed in 5.1 with the audiophile in mind. Stereo is not the ultimate thing for me any more. Of course I listen to stereo 44.1 kHz recordings but I don’t up-mix stereo and I don’t up-sample.
Cheers,
exa
your device as it is now is near perfect and fills a precise niche and task a lot of people here (as I) were waiting for... No problem with a well implemented USB solution for me...
I am linux only user because linux has BRUTEFIR (real time FFt convolution filter engine) and I am making a multiway (stereo) DAC (for 4 way active crossover).
I am sure a lot of people would need ALSA linux drivers : peufeu here has a device like yours but based on the Nexys2 board and linux (you should really be in contact). I am pretty sure a would be interested in buying also you board.
The alsa developper guys are reachable and open : getting them to make the driver would be easy I think.
I would buy instantly your board if it had alsa linux driver...
I am interested in only 44100hz but personnaly with 8 to 16 channels.
I would love a way to combine 2 of your boards to have 16 channel totally in sync (8 channel per speaker side) but it is probably already doable with JACK server in linux.
Playback only is perfect for me and a lot of people here.
I will use many pcm1794 dac ics and would love it if you had a board with 8 (or 16 with dual mono mode possibility) of them already soldered on it.
(A not to expensive board with the ESS 32bit top of the line in 8ch output would also be very interesting to me...) What could be interesting concerning price and performance would be a new board of yours with the ESS 8ch dac also on it.
I also favor integrated power regulation in the boards as you did in you proto board too, and for everyboards.
So personnaly only ALSA linux driver are missing... All the rest is already near perfect as it is.
Thanks in adavance for your time and dedication
I am linux only user because linux has BRUTEFIR (real time FFt convolution filter engine) and I am making a multiway (stereo) DAC (for 4 way active crossover).
I am sure a lot of people would need ALSA linux drivers : peufeu here has a device like yours but based on the Nexys2 board and linux (you should really be in contact). I am pretty sure a would be interested in buying also you board.
The alsa developper guys are reachable and open : getting them to make the driver would be easy I think.
I would buy instantly your board if it had alsa linux driver...
I am interested in only 44100hz but personnaly with 8 to 16 channels.
I would love a way to combine 2 of your boards to have 16 channel totally in sync (8 channel per speaker side) but it is probably already doable with JACK server in linux.
Playback only is perfect for me and a lot of people here.
I will use many pcm1794 dac ics and would love it if you had a board with 8 (or 16 with dual mono mode possibility) of them already soldered on it.
(A not to expensive board with the ESS 32bit top of the line in 8ch output would also be very interesting to me...) What could be interesting concerning price and performance would be a new board of yours with the ESS 8ch dac also on it.
I also favor integrated power regulation in the boards as you did in you proto board too, and for everyboards.
So personnaly only ALSA linux driver are missing... All the rest is already near perfect as it is.
Thanks in adavance for your time and dedication
Guys,
I cannot be of any help on the FireWire vs. USB discussion. There is more than one way to skin a cat. In my opinion there aren’t any technological limitations in my USB implementation. Nothing will change in the output I2S stream if I use FireWire. It is a matter of convenience and compatibility to use one or the other. I admit FireWire is cool.
Regarding the various USB modes of operation – this discussion is relevant for traditional USB implementations. I don’t rely on the USB to do any synchronization. I have a proprietary solution. What matters is that exaU2I is the host, and the PC is the slave. Maybe that’s why I did it with a PC. I don’t want to enslave Macs.
So exaU2I (the FPGA core) controls the data flow over USB. Later it may be over FireWire. The FPGA makes sure that USB data has arrived and is uncorrupted in the exaU2I memory buffer. The FPGA makes sure that the buffer never gets empty. If Windows is terribly busy, sometimes the buffer does get empty. For cases like that I have an LED light to indicate an error. A parallel FPGA process reads the memory buffer, clocks the data with one of the two low-jitter quartz oscillators and sends it out in I2S format. This process will go well if the input stream transport (USB or something fancy) is faster than the output stream.
With other words I am confident I don’t need to reconsider the USB mode of operation or the use of alternative transport because I know that I can fill up the buffer faster than it is emptied. Remember these high-school math problems: “A swimming pool is filled up by one pipe delivering X litters per second and drained out by 3 drain pipes taking out Y litters per second. Calculate how long will take before the pool gets empty.” I just solved one of these math problems.
For the benefits of the users that are interested to try the coming release of exaU2I we should focus on the use of the device. How are you going to use it guys? What DAC boards do you have?
Is anybody listening to multichannel 192 kHz recordings? That’s how I use the device. I have Fubar2000 and J. RiverMedia Center. I use an old-fashioned PC because I know how to make it to do anything. The only thing I care about is sound quality. I use 4 speakers and I mix 5.1 and 7.1 to quarto. One day I will build the remaining four speakers. I am really excited about multichannel; there are recordings out there that are mixed in 5.1 with the audiophile in mind. Stereo is not the ultimate thing for me any more. Of course I listen to stereo 44.1 kHz recordings but I don’t up-mix stereo and I don’t up-sample.
Cheers,
exa
Exa,
no need to go further into FW vs USB. I think our reaction was more about someones comment that FW is dead. I liked the FW idea particularly because I could have a very long FW line - up to 100 ft with repeater. That way I could have any PC or Mac in a different room - no need to build quiet PC. For anyone trying to say that FW cannot go longer than 15ft, I have been using it last 12 years on digital cameras when I need longer distance between, camera and computer, with repeater obviously.
My interest in using your board is for 3 or 4 way stereo speaker crossover. I will be using ESS 9012 / 9018 chips - three different boards giving me ether 6 or 8 outs. I would like to test it with AKM 4396 DACs as well. I have a lots of 96K recordings - transfers from LPs that I am curious how they will sound. I am also searching how to take out digital signal from my SACD, so that would be real pleasure to put through this new set up. I am not in surround sound, since I am enough complicated just in a stereo implementation.
Actually, some bad FW Audio implementations took the cheap route and instead of having a local crystal, they were designed to take their clock from the FW bus. This is really bad for jitter. You will find a notorious white paper on the internet describing this. Unfortunately, people cite this paper as a condemnation of all FW Audio, without understanding that it only affects cheap/bad designs. There are, most certainly, many FireWire Audio devices which have their own asynchronous clock. I don't think any of the 'bad' designs are still in production.
I just wanted to clarify that FW does not completely circumvent the potential for this problem, although it's not really a modern issue.
I think it is important to clarify that USB allows you the option of making your device the Master clock, and the PC is slaving to your audio clock. However, the definition of USB is that the PC is always the host, and your device is always a slave. This is one of the distinctions between USB and FireWire, where FireWire is an interface between peers, and either device can become a full master.Regarding the various USB modes of operation – this discussion is relevant for traditional USB implementations. I don’t rely on the USB to do any synchronization. I have a proprietary solution. What matters is that exaU2I is the host, and the PC is the slave. Maybe that’s why I did it with a PC. I don’t want to enslave Macs.
So exaU2I (the FPGA core) controls the data flow over USB. Later it may be over FireWire. The FPGA makes sure that USB data has arrived and is uncorrupted in the exaU2I memory buffer. The FPGA makes sure that the buffer never gets empty. If Windows is terribly busy, sometimes the buffer does get empty. For cases like that I have an LED light to indicate an error. A parallel FPGA process reads the memory buffer, clocks the data with one of the two low-jitter quartz oscillators and sends it out in I2S format. This process will go well if the input stream transport (USB or something fancy) is faster than the output stream.
I think that you understand this, because you mention the possibility that Windows might be terribly busy, and thus the data flow would be interrupted. But I just wanted to point out that your USB device cannot do anything at all unless the PC requests data in its role as the sole USB host. It's not a terribly important distinction, but the fact is that the exaU2I is not the host, and it does not control the packet timing. However, the exaU2I does provide the master clock for the DAC, and it does control the sample timing.
Hope this makes sense.
P.S. Although I prefer FireWire, having used it to record around 200 live music performances, I still say that a FireWire-to-I2S device (exaFW2I?) would be a completely different product than the exaU2I. While the FPGA implementation might be shared, it would require basically starting over from ground zero. I'd much rather see exaU2I released and enjoyed rather than slowing progress by starting over with FireWire.
This kit should really make the most out of some 192Khz multichannel recordings I have. But I must admit that I am even more curious about the 384Khz, 32 bit setting. I actually have a master file at this sample rate (24 bits though) and I never got to hear it, so this might be my chance
.So to answer your question, I would have two uses for this: a) high resolution multichannel playback and b) high resolution digital crossover. Maybe the usb 3.0 version will be able of doing both of these at the same time
It most likely does not support DTS or any other formats like Dolby Digital, Dolby TrueHD, DTS-HD, etc.
They would need to add decoders and pay license fees.
The best way to use this hardware is to let your computer software do the decoding. Unfortunately, a few of the best video players (Media Player Classic - Home Cinema, VLC, and 7MC) don't support ASIO drivers.
They would need to add decoders and pay license fees.
The best way to use this hardware is to let your computer software do the decoding. Unfortunately, a few of the best video players (Media Player Classic - Home Cinema, VLC, and 7MC) don't support ASIO drivers.
Then a additional "WDM" driver would be a must. A lot of people do not use their dac only for music but also for movies and television.
I agree. Or, it would be really great if Microsoft would finally support USB Audio Class 2.0.
This is correct. Decoding has to be done by the software player. Developing a WDM diver is in the to-do list. There is also another way around - ASIO output plug-ins can be developed for Media Player Classic and VLC. Plug-ins will provide the best of both worlds - top-quality sound and good user experience.
That sounds great, but I'd still try to develop a multichannel WDM driver so users can play audio/video files with Windows 7 Media Center. With plugins like Media Browser or My Movies, users have a very nice interface for playing DVDs and Blu-rays. In my family, I don't think my wife and daughters would be as enthusiastic about our HTPC if they had to navigate to use the file or folder open function with MPC or VLC and navigate to the folder to find their movies. It's a lot nicer to browse the coverart, which is laid out alphanumerically.
7MC is also great for watching and recording live TV. It's too bad it falls short for playing music. I prefer JRMC for playing my ripped CDs, DVD-As, SACD and BD files (stereo and surround; 16- and 24-bit; 44.1 to 192 kHz). If only JRMC would include a 7MC plugin that would provide Theater View in 7MC.
Last edited: