Your statement is somewhat unclear.
Are you saying that the highest quality can only be achieved with SPDIF?
Or, are you saying that SPDIF can only approach the highest quality if properly implemented?
The former would be incredibly difficult to prove.
IMO, SPDIF presents the single largest challenge when aspiring for the highest quality. Similarly, by avoiding SPDIF, the highest quality is much easier to achieve. The same goes for similar technologies such as TOSLINK and AES3.
Hi. I wonder if this module can work with this PCM > PWM amplifier?
miniAMP | miniDSP
This amplifier takes i2s and uses TAS5704 for amplificaiton.
This way, we can even bypass the DA conversion
miniAMP | miniDSP
This amplifier takes i2s and uses TAS5704 for amplificaiton.
This way, we can even bypass the DA conversion
What I'm saying is that SPDIF or whatever interface, assuming bitperfect
delivery of bits, should become irrelevant if the receiving end would do a good job.
There are just a very few devices out there e.g. Apogee Big Ben, which seem to be able to handle that challenge quite good.
I tweaked my SB Touch SPDIF output & my receiver input & PS and I'm pretty happy happy with the result. My former USB+I2S reclocker interface wouldn't beat that.
SPDIF is known not to be the best interface. Still I consider it the most flexible.
Honestly - I don't want to end up with proprietary ASIO Windows only USB drivers anymore. If USB then standard USB drivers ( these support asynchronous USB) on
all platforms should do. I don't want to be tied to a certain OS because of the soundcard driver. This is absolutely unacceptable to me.
What you describe is only true if you ignore time. When I transfer a DAT recording to my computer, SPDIF is perfectly fine, and there isn't even any advantage to switching to AES3 in that case. I'm merely copying bits to a file. However, playback of audio in real time requires synchronization of the source media and the playback DAC clock. Just because SPDIF allows this to happen without incident 99.9% of the time does not mean that it works 100% of the time. In other words, you always run the risk of repeating or losing a sample unless you delay the playback by a substantial number of samples. i.e., You can design your DAC to follow the SPDIF clock and suffer from jitter, or you can reclock the data and suffer in other ways.
Throwing around a renowned name like Big Ben has absolutely nothing to do with what we are discussing here. Apogee's Big Ben is a master clock source. It does not convert audio bits into analog signals, i.e., Big Ben is not a DAC. Big Ben cannot handle the challenge of synchronizing the media source to the DAC unless you have a transport with an external clock input, and those are quite rare unless you want to hack your own. The problem is that such a solution, although possible, is overly expensive and involves three devices (master clock, media transport with external clocking, DAC with external clocking) when you really only need two (media transport and DAC with bidirectional communication).
I prefer the simpler, less expensive solution. It's always easier to engineer the better solution when the design itself is as simple as possible, and so long as the design does not unnecessarily introduce problems that need additional engineering to solve.
If you are happy, then perhaps the jitter noise is inaudible in your situation. Jitter noise is not always inaudible, but the good news is that it can be avoided simply by avoiding SPDIF and similar unidirectional communications.
I have no idea what kind of USB+I2S reclocker you were using, but perhaps it was based on unidirectional clocking from the media transport, in which case it would have suffered the same issues as SPDIF. Take note that reclocking is entirely unnecessary when the media transport slaves to the DAC clock.
I will agree that SPDIF is widespread, convenient, and at least some part of your system should probably have an SPDIF input for compatibility with outdated gear. However, given the options today, my primary listening path will not involve SPDIF or TOSLINK or AES3. As more people demand an end to easily avoided jitter, SPDIF will perhaps become less of a need.
On this point I entirely agree. While I have due respect for exaU2I and the USB-to-I2S project, it's not for me, either.
Simply put, the choice of the FTDI USB chip makes an official implementation of a USB-Audio driver impossible, and thus I consider the design flawed for my use. As a hardware designer and firmware developer, I would have recommended choosing the Cypress SX2 or FX2LP chips. The Cypress chips are fully programmable, and could implement the USB-Audio specification. There are also other programmable options. The FTDI Chip cannot implement the USB-Audio specification, and therefore it is doomed to custom drivers on Windows, Linux, and OSX.
Many hardware designers cite the lack of USB-Audio support on Windows as the reason for choosing a non-standard implementation, and claim that the support in OSX does not represent a big enough market. But it just doesn't make sense, IMO, to go to the trouble of developing proprietary ASIO drivers when a proprietary USB-Audio driver would make the overall hardware design compatible with more systems.
1. Time
In the pro-audio world latency matters. It's irrelevant for
home audio.
And most of the devices (incl. EXA) buffer and delay anyhow.
You'll also find buffers in e.g. NAIM DACs, PS Audio stuff asf.
Not to forget all these streaming clients which buffer 20-30s or
more.
The majority of interface providers fail on decoupling input
originated distortions (noise/jitter).
Even the majority of super expensive asynch USB DACs won't make it.
2. Apogee BB
It's also a reclocker. And it works quite good on SPDIF. I havn't said
that I'd buy it. I listened to it and it left a nice impression on me.
The Appogee was feeding an Antelope Zodiac Gold btw. Not the suposedly worst commercial DAC out there.
3. SPDIF or USB
Doesn't matter what I tried. I could not find any device which decouples
propery from the PC side. Let me know if there's an interface out there.
I used to use an USB-reclocker from EC-Designs btw.
It's a myth that asynchronous USB is the holy grail of slaving/decoupling a transport.
Slightest variations on the PC will have an impact on the output. You can find tons of info and experiences about it on AA and elsewhere.
4. Jitter levels achieved
No idea. I'm not a manufacturer. I can't afford that kind of lab gear.
I was desperately looking for somebody who'd be willing to take some measurements on my SB Touch Toolbox optimizations.
I even talked to some "professionals" about it. I can tell you. I still havn't found anybody supporting a "community effort".
Cheers
In the pro-audio world latency matters. It's irrelevant for
home audio.
And most of the devices (incl. EXA) buffer and delay anyhow.
You'll also find buffers in e.g. NAIM DACs, PS Audio stuff asf.
Not to forget all these streaming clients which buffer 20-30s or
more.
The majority of interface providers fail on decoupling input
originated distortions (noise/jitter).
Even the majority of super expensive asynch USB DACs won't make it.
2. Apogee BB
It's also a reclocker. And it works quite good on SPDIF. I havn't said
that I'd buy it. I listened to it and it left a nice impression on me.
The Appogee was feeding an Antelope Zodiac Gold btw. Not the suposedly worst commercial DAC out there.
3. SPDIF or USB
Doesn't matter what I tried. I could not find any device which decouples
propery from the PC side. Let me know if there's an interface out there.
I used to use an USB-reclocker from EC-Designs btw.
It's a myth that asynchronous USB is the holy grail of slaving/decoupling a transport.
Slightest variations on the PC will have an impact on the output. You can find tons of info and experiences about it on AA and elsewhere.
4. Jitter levels achieved
No idea. I'm not a manufacturer. I can't afford that kind of lab gear.
I was desperately looking for somebody who'd be willing to take some measurements on my SB Touch Toolbox optimizations.
I even talked to some "professionals" about it. I can tell you. I still havn't found anybody supporting a "community effort".
Cheers
It's very interesting! It reminds me of Koon's TAS5706 Class-D amplifier.
http://koonlab.com/TAS5706/TAS5706.html
For me, the amplifier seems to accept I2S output signals from exaU2I
without problems. I can't guarantee it, however.
When we handles I2S interface, we should consider;
1. Signal Level
+3.3 V, +5 V or LVDS differential?
In this case, +3.3 V. OK.
2. BCLK
32*fs, 64*fs or fs dependent?
In this case, 64*fs?
3. MCLK
256*fs, 512*fs or fs dependent?
Autodetect or register setting mandatory?
As for 2. and 3., the amplifier seems to autodetect clock frequencies.
There will be no problems.
One concern is there is no volume function in exaU2I nor miniAMP.
You need to use digital volume function in your player program on PC.
Bunpei,
May I kindly ask you to allow me to handle the support questions for exaU2I myself?
As a vendor offering a competing device obviously you have a conflict of interest when you post here. I've been restraining myself from using the SD card player discussion thread as a platform for publicity for exaU2I. These forums are created for the benefit of the genuine DIY users and we as vendors have the responsibility to respect each-other's boundaries.
There should be no problem to use any device that has a standard I2S input. Please check the Terminal Functions section on the DIY Guide on our website: www.exadevices.com > exaU2I > D.I.Y. Guide.
Best regards,
exa065
soundcheck, you are missing the point about "time" in rsdio's answer. It is not about Latency. It is about Jitter.
Oh, I'm sorry. I will withdraw from this thread.
I just wanted to promote 352.8 kHz/24 bit play and the use of I2S and to help people not to get involved in known problems.
You are a commercial vendor while ours is just a diy project as a hobby.
I misunderstood that this thread is left for diy people and you have already created another thread in a verdor area.
I'm sorry again.
Last edited:
I was just wondering if anyone uses exa device as a crossover for multiway stereo? If yes, than what software are you using / planning to use? I am currently using Allocator which is really great software, but requires input / output loop and I am not sure how that would work with exa device. Allocator uses ASIO drivers, does exceptional job but requires to export signal from output to input, and in my case that is SPIDIF in out loop. So maybe the question is if there is a possibility to create loop with exa device? If not, is it possible to create it on the software level?
Last edited:
Personally, of all the computer DAC hardware that I own, FireWire interfaces are preferred. I own a few USB DACs, but they were all purchased for comparison and are not really used in critical listening setups.
But, again, if you are using a USB-reclocker then you are misunderstanding the proper solution. Reclocking is different technology than having the DAC run as master clock. USB-Audio offers too many options, I suppose, because this should not be so confusing.
As for FireWire, I am interested in designing a proper FireWire DAC, perhaps with I2S output for maximum DIY options. Unfortunately, where USB offers free documentation, cheap chips, free software libraries, and more community experience; FireWire documentation is more expensive than building your own board, chips typically cost a little more, software libraries seem to be nonexistent, and I do not know of anyone in the DIY community who has developed a FireWire solution.
I suppose there's no guarantee that FireWire would automatically perform better than USB, but the commercial products that I have compared definitely put FireWire at the top. At the very least, I would like to see DIY options using FireWire technology, especially with brand new FireWire products being announced this year such as: Sonic State - News WNAMM11: FireWire DSP Accelerators For UAD-2, UAD-2 Satellite DUO and QUAD allow plug in and play operation on Macs - no PCIe card required
That is not the only option. A product such as one of the Goldpoint level controls would allow you to run your DAC at full bit-depth quality, and then reduce the volume with precision, low-noise attenuators. See Goldpoint Level Controls
Also, if you want digitally-controlled volume instead of a manual control, then the exaU2I is the wrong place for the technology. Even if the exaU2I incorporated a digital volume function, it would be equivalent to using your player program volume. That's because the exaU2I is ahead of the DAC in the digital domain only, but quality attenuation should be placed after the DAC in the analog domain. In other words, if you need digital-controlled volume, then you should select an I2S DAC board that offers that feature, and then connect it to the exaU2I.
Granted, the one weak link is how to communicate between the PC and the digital potentiometer circuit, since the exaU2I only passes audio samples and not control messages. A full USB-Audio implementation would allow the PC to control volume via Audio Control Parameter Block USB messages, out-of-band from the audio stream. But this would require a totally different product design.
I could not agree more than what you explained particularly when it comes to volume control. It is certainly very simple digital implementation of volume on the DAC like Sabre and makes life much easier for anyone with multichannel set ups, but it could never compare to analog version of the same. The price for analog version is much higher than digital version, but quality is there, particularly when you have to dramatically turn your volume down.
Also, FW is the best, but unfortunately as you described not for DIY. Do you have any knowledge if LightPipe / Thunderbolt is going to be friendlier when it comes to DIY? FW is from Apple, and later belongs to Intel, so maybe that will give some more room for DIY?
Maybe we can start another thread for DIY FW.
FireWire itself is Apple's branding of IEEE 1394, it is not exclusively 'from' them or Intel. Sony and Texas Instruments also have compatible brand names for the same technology. Texas Instruments makes IEEE 1394a chips such as the TSB41AB2 and TSB12LV32 available without Apple's involvement.
I would be highly suspicious of the feasibility of building a LightPipe / Thunderbolt audio interface in the DIY world before anyone has launched a successful product in the commercial world. It would be much cheaper to leverage existing, proven technology that is a few generations old, and where the chip market has at least some competition on price and established engineering experience. FireWire 400 is capable of at least 54 bidirectional audio channels, or 108 channels at 96 kHz. Existing commercial product implementations have 48 channels at 192 kHz, so there is certainly no need to look to new interfaces that are any faster than FireWire 800, which should support 48 channels at 384 kHz.
Yes I do agree with all points, but I think, it is just a matter of time to see all kinds of implementations since LP/Thund. is so wide. The beauty in it is that it will carry all previous technologies such as FW, USB, ePCI.... you name it all through the same pipe. So how I see it, all previous technologies will continue to exists and will be just piped all together through the same device, which will also enable Apple to make smaller and smaller units that will be offloading tasks to an external device. We will be plugging monitor, FW device and USB through the same unit that will carry it back to the main machine. That way as you explained all of the development could continue for existing technologies.
Sorry exa, for the interruption with sort of unrelated disscussion, but I am positive I will be plugging exa device to a LP/Thunderbolt pretty soon.
