By the way, I am just aware of and wondering that we have one AES/EBU digital "OUT" in DAC8PRO which always gives CH-1 + CH-2 digital signal; if we would connect this AES/EBU OUT into AES/EBU IN of the second DAC8PRO, then the two DAC8PROs would be automatically in sync, or not?
I will also PM to Pavel of OKTO for this inquiry....
I confirm this is going to work for syncing two units set to receive audio data over USB. The unit set to "Pure USB" mode will become a "master" unit, providing its clock to the other one, set to "USB/AES" mode, which will accommodate its frequency of data requests to the USB host in a way to be fully in sync with the signal received over its AES/EBU input. We have yet to test how a USB host running Windows will cope with two units and whether Thesycon, ASIO4ALL or both drivers will need to be used.
Funny, mine hasn't even shipped yet, and I ordered the Stereo on launch day (April 8th).
Be prepared for a seriously long wait..
The first batch of the dac8 Stereos has been shipped 2 weeks ago, more are shipping this week and the production rate should stabilize and only increase from now on. There was something we needed to take care of in regards the Raspberry integration. Thank you for your patience.
The only annoyance so far is the pop I get whenever I hit stop on a playing track when bitstreaming DSD music (DoP). This doesn't occur with PCM music. I also did not have this problem with the RME ADI-2 DAC.
@Okto Research Any thoughts as to what might be going on?
We know about the issue and we are working on a fix. It is a software one, so we should be able to address it with a firmware update package that our software developers are working on.
Hi. Thank you for my dream DAC!
So what you are saying is that the dac8 does not need that info? XMOS & DAC chips processes 24/16 bit the same? Nothing special for 24? Since the DAC does not detect the info it must process the same.
All the data is processed as 32-bit internally and neither XMOS nor DAC chip is aware of part of the sample bits being padded with zeros.
"Far from reliable", is probably stretching it. Can you/anyone name ANY device that passes wrong info? And with AES? And MCH? Many devices, including my entire system relies on that info. The Vanity reclocks native signal. It detects that info in order to know how to reclock. Many DAC's do have bitrate. I guess it's a design decision for an off chance it might be wrong. Anyway, thanks for clearing that up.
During our testing, we came across multiple consumer, SPDIF devices that either did not provide the information about bit depth at all or it didn't reflect the actual data. We are going to have a look at this in the future in order to make the dac8 able to display the AES/EBU / SPDIF bit depth information when it is available and when the DAC is able to verify that it is correct.
Speaking of design, why no Clock input? All Pro DAC's have 'em. I imagine pro people would be way, way more interested in this product then us mere mortals. Now they wont/can't buy. Effects everyone because now DAW's (The source of our sources) will use substandard devices. So the universe would gain if Pro's/DAW's use this device.
BTW: This forum only tested clock with single device, but what about DAW's with 20+ devices with analog stages. Also, my Pro Trinnov (assuming many others) allows for a secondary audio, the unprocessed audio, Trinnov calls it wet vs dry. Anyway, all that's gotta be synced.
Congratulations! Well done. Give yourself a raise. (Of coarse clock input would give you around 900% raise...)
As answered in one of the subsequent posts, the AES/EBU or SPDIF signal already contains the clock. More than that, the AES/EBU or SPDIF frequency is equal to 2x the bit rate (or 128x sample rate), which (even though it has the biphase-mark coded audio data on it) makes it much easier for the receiver (and less prone to errors - jitter) to recover the bit clock from than from a slow word clock supplied through a separate connector. The dac8 PRO uses a combination of a very good receiver chip and Sabre's jitter eliminator in order to achieve the specified performance, even when using its AES/EBU inputs (regardless of whether AES/EBU or SPDIF signal is being fed to them). SPDIF and AES/EBU are, unlike UAC2 USB, synchronous protocols, so a significant timing error would lead to immediate loss of sync or audible sample drops.
I am afraid that there is a strong similarity between the idea of clocking in the pro audio and luxurious cables in the consumer audio. Trying to keep DACs fed with AES/EBU signal in sync using an external word clock kind of reminds trying to improve sound quality with directional cables placed on elevators.
Pavel, Okto Research