The configuration is perfect.
There are player DSP plug-ins that can be used to adjust per-channel volume. There is no graphic interface because there is no volume control capability within exaU2I. I don't think that bit-perfect interface should have volume control functionality. I can see how this is inconvenient.
Thank you for the reply. It sounds good to me. No volume is not a big deal since I could adjust individual ratio between channels within crossover application. Acctually no GUI is even better, one window less and one less part to tweek.
I really like your choice for ASIO because it is stable, and simply works. Particularly what you mentioned, changing the sample rate in Windows without ASIO is such an aqward process.
No idea what you mean with "It is not an issue if ES9018 is used".
The Sabre (at least my Buffallo II) picks up jitter and lets you know how much it picked up. I know this is not exactly that what marketing claims.
It would be really helpful if the ASIO driver supported more than one exaU2I unit. This would allow for multichannel fully active DSP crossover setup.
Something like 3x 3-way fronts, 2x 2-way surrounds and sub or two needs 14 to 15 physical outputs. Two of the boards running off the same clock under one driver would be really cool.
Something like 3x 3-way fronts, 2x 2-way surrounds and sub or two needs 14 to 15 physical outputs. Two of the boards running off the same clock under one driver would be really cool.
Thank you, but I know what IEEE.1394 or "FireWire" was meant for. I don't deny it has its strenghts. I thought Apple already removed it from their Macbook Pros, just like they did the PC-card. Now I'm not gonna bet they'll keep it on the next rev... Maybe on the 17" only, like for PC card.
I also know most problems were caused by bad chips. But implementation in Windows was bad too. And it still is, even in Seven. Just a week ago... We made a music production unit, and for that we added 1394 ports. Had to buy 3 cards until we found one that would please both the devices, the motherboard and the system. A few bugs still remain...
You mention RME, but their Fireface interfaces exist for years... the newer ones add USB to Firewire (or are just plain USB).
My opinion is that IEEE.1394 was a good idea that never had really good support. Apple computers quite of managed to get it well, though.
Designing for FW is IMO asking for trouble. And IME we're not talking about 3$ more.... Unless you sell really a lot of these, and for years (and it will still cost a lot more than a 3$ extra).
Now this is not the subject of this topic.Back on.
Last edited:
The ESS dac data input are clocked by the word clock and the "master" clock on the exa device will not be used by the ESS Sabre32 DACs.
On a ES9022 or ES9023 you "could" use the "master" clock, but it would be running at only the half speed of what the ES9022 or ES9023 needs to have some headroom for the jitter removal circuit.
Last edited:
Look up I2S on Wikipedia. It shows Master Clock, Word Clock, Bit Clock, and Data (also Return Data). Some DAC chips do not need Master Clock, but I'm fairly certain they all must pay attention to the Word and Bit clocks or they'd produce nonsense.
The LR clock works at the sample frequency and basically says 'when this clock is on the data at the moment is for the left channel (or right channel I'm not sure which) and visa versa.
The Data stream carries a stream of 1's and 0's, this contains the information of the digital signal that is to be converted into analogue.
The Bit clock is the clock used to time and decode the data stream and usually operates at 64x fs. In other words the bit clock is high, check data stream for it's polarity, okay, it's a 0. Bit clock goes low, look again at the data stream, okay its another zero. Without the bit clock doing the timing and dictating when the data stream should be checked, the DAC wouldn't know the difference between the first zero and the second zero.
In the same sense without the LR clock the DAC wouldn't know if the data incoming is for the left or the right channel.
Those three clocks have to be synchronous.
The master clock isn't strictly required to decode any data. Converter chips however, most of the time, require the master clock for the functioning of internal operations, such as digital filters. In a lot of chips the master clock does not have to be synchronous with the other three clocks either, although it usually is, as the other three clocks are usually generated by clock division of the master clock. The master clock can run at many different speeds and ADC/DAC converters specify the limits to which they can work. 256x fs is a nominal figure for the master clock as most ADC/DAC converters can operate from 32khz >192 from it.
The master clock obviously runs the fastest and if you're going to buy an expensive Tentclock/Kwakclock thingymabob, it is to this frequency that you will purchase.
I think that's about it. Someone correct me if I've missed something all these years
The Data stream carries a stream of 1's and 0's, this contains the information of the digital signal that is to be converted into analogue.
The Bit clock is the clock used to time and decode the data stream and usually operates at 64x fs. In other words the bit clock is high, check data stream for it's polarity, okay, it's a 0. Bit clock goes low, look again at the data stream, okay its another zero. Without the bit clock doing the timing and dictating when the data stream should be checked, the DAC wouldn't know the difference between the first zero and the second zero.
In the same sense without the LR clock the DAC wouldn't know if the data incoming is for the left or the right channel.
Those three clocks have to be synchronous.
The master clock isn't strictly required to decode any data. Converter chips however, most of the time, require the master clock for the functioning of internal operations, such as digital filters. In a lot of chips the master clock does not have to be synchronous with the other three clocks either, although it usually is, as the other three clocks are usually generated by clock division of the master clock. The master clock can run at many different speeds and ADC/DAC converters specify the limits to which they can work. 256x fs is a nominal figure for the master clock as most ADC/DAC converters can operate from 32khz >192 from it.
The master clock obviously runs the fastest and if you're going to buy an expensive Tentclock/Kwakclock thingymabob, it is to this frequency that you will purchase.
I think that's about it. Someone correct me if I've missed something all these years
Overall, I think you did a decent summary. But putting on my pedantic hat, I'd be highly surprised if the Bit Clock is both active high *and* active low. Most likely, it's going to sample the data line on the rising edge *or* the falling edge of the Bit Clock, but not both. DDR memory works on both clock transitions, but most clocked data systems only look for one specific transition.
Thanks for your explanations, much appreciated!
Following from this, it means that the master clocks (for 44Khz and 48Khz domains) on the FPGA board is used to derive the wordclock (or bit clock, that is). The bit clock is then fed to the dac.
The difference is that the ESS 9018 will do ASRC on it while using its own oscillator, while more common DAC architectures, such as AD1955 or AK4396 will rely solely on the data coming from the fpga.
An ideal procedure then, would be to have the two master oscillators on the DAC board, let the DAC derive the bit clock and feed the entire system (fpga, pc, etc). Is this correct?
Following from this, it means that the master clocks (for 44Khz and 48Khz domains) on the FPGA board is used to derive the wordclock (or bit clock, that is). The bit clock is then fed to the dac.
The difference is that the ESS 9018 will do ASRC on it while using its own oscillator, while more common DAC architectures, such as AD1955 or AK4396 will rely solely on the data coming from the fpga.
An ideal procedure then, would be to have the two master oscillators on the DAC board, let the DAC derive the bit clock and feed the entire system (fpga, pc, etc). Is this correct?
Last edited:
Assuming that the DAC board has a better clock circuit, then: yes. But it's entirely possible for the USB-to-I2S board to have a clock that is just as good, in which case neither is ideal. It could easily turn out to be "six of one, half dozen of the other" - i.e. - exactly the same.
As Dan Lavry's white paper explains, there's no way that an external clock can be 'better' than a properly-designed internal clock. Since the ideal design would have the USB-to-I2S board and the DAC board sharing a chassis, a clock on either board would basically be 'internal.'
The only detail this summary overlooks is whatever there would be significant degradation between the two boards due to the I2S connector. If Ayre can make this work with a simple ribbon cable, then I don't see how bad it could be. It would be interesting to know whether Ayre places the master clock on the DAC board or the I2S source board.
In other words, the point I am trying to make here is that internal connections do not invite the same kinds of noise and degradation as external cable interconnects. It's not so easy that you can ignore the problem, because even internal connections can be ruined by careless design, but the potential problems are not nearly as huge for internal connections as they are for external cables.
P.S. One consideration is that if the DAC board has a pair of 44.1x and 48x clocks, then some kind of signaling has to be provided between the I2S board and the DAC board to make the switch between sample rates. This alone could require an entirely separate connection in addition to the I2S interconnect. In other words, it's far simpler to have the USB-to-I2S generate the master clocks, because there is where you have a more generic control communication link. With the DAC board slaving to the incoming I2S signals, nothing more is needed to connect the boards. In contrast, any additional clock control communication between boards could introduce ground loops and digital noise.
These comments are all taken from a fairly high level viewpoint, without considering specific chips.
Thank you everybody for the excellent contributions to the discussion. I wouldn’t have been able to explain some of the points as well as you have.
I would also like to thank you for the overwhelming response on the waiting list - www.exadevices.com. Unfortunately I left many of your emails unanswered; there isn’t enough time to write to all of you individually. Your questions will be answered on the website after the release of exaU2I.
I would also like to thank you for the overwhelming response on the waiting list - www.exadevices.com. Unfortunately I left many of your emails unanswered; there isn’t enough time to write to all of you individually. Your questions will be answered on the website after the release of exaU2I.
I'd like to recommend that those who are interested in I2S read this specification document,
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf