No I2S inputs, why?
Also using FIFO is also problem as you don't really know exactly the output sample position (unless the FPGA somehow reports it to ASIO). Is the FIFO interface an 8-bit wide - using FTDI USB-parallel FIFO module perhaps? Alternatively you could use dual-ported SRAM on FPGA. Will the USB-FPGA protocol be open source? Also how about the FPGA configuration (Verilog/VHDL)?
Which FPGA brand you are using btw (Xilinx / Altera / some other)?
Also some people have suggested a crossover application, could you just implement some biquads in FPGA, they have usually some amount of 18x18 bit hardware multipliers, and you could configure them via USB? Also you could implement the lip synch delay likewise.
Also regarding the I2S connector I would like to see a connector which doesn't have built-in antennas - I mean the connector used is not suited well for handling high frequency signals. It would be better to use something like HDMI connectors (http://www.psaudio.com/ps/products/description/perfectwave-i2s?cat=) or at least standard IDC flat cable connectors designed for high speed (maybe with LVDS).
Last edited:
You could handle this sort of feature in computer software on the USB host far cheaper than a custom board. But if you want to design a circuit board between the USB-to-I2C with this feature then have fun! There isn't a precise chip for delay, except perhaps a FIFO, but even that would require support circuitry.
I would like to comment on the various questions about the choice of technology and features of exaU2I. This device is designed to solve the “missing link” issue for mastering-grade multichannel playback from a computer. Our approach is minimalistic. We believe that when it comes to faithful reproduction of sound, less is more. Our quest was to remove any optional features and limitations caused by conventional technologies and consumer standards. We aimed to create a baseline product that is completely transparent. Users can implement any additional processing using external software and hardware.
This product will appeal only to people that are not satisfied with the ‘statu quo” and are looking for alternative solutions. After all, to achieve different results you must do something different.
Our choice of driver technology and proprietary hardware implementation perfectly serves the design goals for the project. In our experience this environment produced the best results. We realize that using the Windows operating system and a less known driver interface will narrow the market for the initial release of exaU2I.
The discussion on this thread has been very helpful in identifying the needs and priorities for future versions of the product. OS X drivers are the top development priority.
This product will appeal only to people that are not satisfied with the ‘statu quo” and are looking for alternative solutions. After all, to achieve different results you must do something different.
Our choice of driver technology and proprietary hardware implementation perfectly serves the design goals for the project. In our experience this environment produced the best results. We realize that using the Windows operating system and a less known driver interface will narrow the market for the initial release of exaU2I.
The discussion on this thread has been very helpful in identifying the needs and priorities for future versions of the product. OS X drivers are the top development priority.
The FPGA core code and the ASIO driver will not be open source. For the initial release there will be no provisions to reprogram the FPGA with custom functions. Implementation of delays is on the to-do list. I wouldn’t worry about the antennas. Our simulations and real-life measurements show that this connector is fine. I agree, it doesn’t look professional. Earlier in this thread we discussed a high-end alternative. We will also make the board available without the connector. exaU2I should be used only with short internal cables – less than 10cm.
I tought ASIO drivers are going to bypass all these layers (like volume settings). If there is no chip for I2S delay then i need to use a DSP to do the trick.
There exists dedicated I2S lipsync delays. Small chips meaning difficult to solder and need a microcontroller anyway for adjusting the delay. Well there are some which doesn't need I2C control like this:
http://focus.ti.com/lit/ds/symlink/tpa5052.pdf
Exa, here is one aspect that I am confused about.
In the system there should be only one master clock. If we look into one possible configuration, where there is an exa board and three two channel DACs ( ESS 9012 or 9018) all on separate boards, what and how to deal with master clock? You explained earlier that your board will only allow to be configured as master unit, than what to do with DACs? Should they be all set as slaves, even though master clock always should be on DAC board? Does that mean that clocks should be omitted from DAC boards and than master clock distributed from the exa board? If that is the case should clock signal be buffered? Would your board allow for that since it demands to be master?
Does anyone knows if ESS chips allows to be switched from master to slave since they have a proprietary jitter reduction where signal entering chip is reclocked. If switched from master to slave would that eliminate the benefit that chip offers in low jitter performance?
I know, many questions, but I believe anyone using exa board will need to deal with this even if you are using ESS chip (or any other multichannel chip) in the 8 channel mode so all is on one board. I think my question applies there as well.
Your answers greatly appreciated
In the system there should be only one master clock. If we look into one possible configuration, where there is an exa board and three two channel DACs ( ESS 9012 or 9018) all on separate boards, what and how to deal with master clock? You explained earlier that your board will only allow to be configured as master unit, than what to do with DACs? Should they be all set as slaves, even though master clock always should be on DAC board? Does that mean that clocks should be omitted from DAC boards and than master clock distributed from the exa board? If that is the case should clock signal be buffered? Would your board allow for that since it demands to be master?
Does anyone knows if ESS chips allows to be switched from master to slave since they have a proprietary jitter reduction where signal entering chip is reclocked. If switched from master to slave would that eliminate the benefit that chip offers in low jitter performance?
I know, many questions, but I believe anyone using exa board will need to deal with this even if you are using ESS chip (or any other multichannel chip) in the 8 channel mode so all is on one board. I think my question applies there as well.
Your answers greatly appreciated
there are other ways to eliminate distance, i have no desire or the ability to design y own product. i have already registered interest in exa, but there are still roadblocks to the ideal and this thread is about feedback to ake full version as good as it can be. so some way of mounting directly above would be best
OK, sorry Exa, in order to respond to Qusp I looked back to one of your previous responses and actually find out that you already have answered to someone else with similar question.
Qusp, thank you for the prompt answers, but as you could see from Exa's response for now his board has to be master. I remembered that answer and that is why I posted question under assumption that exa's board is in the master mode. For anyone else looking for master distribution, I know that Acko is developing master clock distribution board. That would be needed in the scenario of running three DAC boards.
I believe exa's board will be very successfull and it will generate a great deal of interest. Next logical step will be incorporating DAC chips on the same board. Hopefully four chips in two channel mode like, ESS 9012/9018 for high end version, or ESS 9018 in eight channel mode for low end version.
You can run as many ES9018 boards you like without any I2S issues.
The bit and word clock from the exaU2I are the only clocks that matters.
It is the word clock that latches the data into the ES9018.
The only issue that could cause problems are if you control all ES9018 boards from one I2C master, and then only if you write to registers in all ES9018 in parallel with the identical I2C address on all the ES9018 boards.
For I2S there are no problems.
Thank you RayCtech. If I do understand you well, with exa board and one DAC per two channels, this really is not going to be an issue, since every DAC will have its own I2S line?
yes thats correct he did say that, i'm aware of the earlier response, but i have private information to the contrary with a few caveats, in its current form its not a straight forward thing because exa has 2 clocks. i probably shouldnt post more here though, perhaps exa will chime in.
also sabre dacs only can choose from a maximum of 2 i2c addresses with onboard mcu, there needs to be an external controller to facilitate more dacs to be controlled, however if crossover is implemented via software before titan, or within titan itself there will be no issue as they do not need to talk to each other
also sabre dacs only can choose from a maximum of 2 i2c addresses with onboard mcu, there needs to be an external controller to facilitate more dacs to be controlled, however if crossover is implemented via software before titan, or within titan itself there will be no issue as they do not need to talk to each other