IVX,
Just my 2 pennies as someone who has > 100K units in the field...
The 4500uF exceeds the USB standard and will cause many of the power supplies to turn off the device because of the inrush current. Pretty sure the USB standard is < 100uF. Sure 4500uF will yield smoother results lower noise and so forth. There are ways around that without going crazy on loading the power supply with more capacitance.
Your going to have a number of returns, because people don't read instructions they use the device and someone or probably several people will plug non-balanced into your device and short out one of the channels. This is why most companies are going to the 4mm or the 2.5mm jacks for balanced and then offer the 3.5mm for standard SE output.
One thing about the ESS dacs that most people don't realize is the output of those is not truly current based. Sure really nice opamps will give you really nice results but will they sound as good as say using a resistor as the IV? While the 9039 has closer to current output than the 9038, I still would not consider it a current output dac.
Just remember one thing... who is going to know the difference from 115dB and 130dB? Heck even 96dB and 130dB ok maybe.
Cheers!
Gordon
Just my 2 pennies as someone who has > 100K units in the field...
The 4500uF exceeds the USB standard and will cause many of the power supplies to turn off the device because of the inrush current. Pretty sure the USB standard is < 100uF. Sure 4500uF will yield smoother results lower noise and so forth. There are ways around that without going crazy on loading the power supply with more capacitance.
Your going to have a number of returns, because people don't read instructions they use the device and someone or probably several people will plug non-balanced into your device and short out one of the channels. This is why most companies are going to the 4mm or the 2.5mm jacks for balanced and then offer the 3.5mm for standard SE output.
One thing about the ESS dacs that most people don't realize is the output of those is not truly current based. Sure really nice opamps will give you really nice results but will they sound as good as say using a resistor as the IV? While the 9039 has closer to current output than the 9038, I still would not consider it a current output dac.
Just remember one thing... who is going to know the difference from 115dB and 130dB? Heck even 96dB and 130dB ok maybe.
Cheers!
Gordon
Regarding the table which also appears in the product description, is there a typo for the sixth line? -125.8 dB for the R channel with 24 MHz clock looks like an outlier.
Do I understand correctly that Proto III used dual 9038Q2M and 9039S uses just one? So if you were to go back to dual chips for the Cosmos DAC, you could achieve sligthly lower noise than 9039S has?
Do I understand correctly that Proto III used dual 9038Q2M and 9039S uses just one? So if you were to go back to dual chips for the Cosmos DAC, you could achieve sligthly lower noise than 9039S has?
no, as I said "proto-III on dual ES9039Q2M", but you know I can't make something trivial as Wavelength teaches me. I'm not really pro, but rather an advanced DIYer by my spirit, and like many DIYers, I'm a perfectionist for 80-90%. However, I worked a long time for OEM/ODM, and in peak months we shipped 200K units, so you can imagine my smile when I read the post above )) So, I decided to use only one I/V composite instead of two and sum that next. I tried that trick in the proto II to "short" 4 outputs of ES9039Pro, and it was very clean without wasting 8 opamps. The same trick doesn't work well with ES9039Q2M, I got too much hi-ord harmonics.
PS: Regarding -125.8db you are right again, it is my typo.
PS: Regarding -125.8db you are right again, it is my typo.
Last edited:
When I started writing Async stuff in 2003 I thought this is great all the problems of SPDIF and jitter are going to go away. Yeah Right!
After 20+ years with TEK USB Analyzers and multiple protocol analyzers and so forth I can tell you nothing is really compliant. The right side of a laptop or the left, front back USB, how many and type of internal hubs and what is hanging off of them is a consideration.
Actual I looked it up and it's 10uF not 100uF. Slow start is only available on some USB3.... and that's if they implement it.
Look you done a lot of work here. But as I talk to CG about this earlier today. It's like the 70's are coming back around again. Back in the 70's massive feedback and super low THD were a thing, but sonically most of the stuff sucked. If your out to please Amir with stats then your golden. If you want to make music I would consider lowering the specs, lowering the feedback and listening some more. Plus most mobile devices would turn you off if your advertising 150ma draw. Most phones won't go above 100ma which I understand is an issue with HS USB, but they are thinking battery not performance.
Thanks,
Gordon
I have used all kinds of USB powered sound interfaces such as QA400 and Motu M4 and never encountered an issue with USB ports. I also own Ivan's 9038DG3 and 9038D which have similar buffer capacitances but somewhat lower current draw. I have used them on a phone but mostly on Windows tablets where they work fine.
I don't see what's wrong with plenty of NFB. As Bruno explains in his F-word paper, there is a region where NFB will emphasize higher order harmonics. The answer to this is more NFB. Some high feedback designs from the 70s pushed LF feedback but had a low first pole, insufficent input stage current, nonlinear VAS, 2EF output stage. That meant that above 1 kHz they didn't have enough feedback to cover up the nonlinearities. I also remember designs from the 90s and 00s that in order to avoid that situation did dumb things such as using a capacitive load on the VAS instead of miller compensation (Yamaha AX 592 and Onkyo TX-NR 3008 come to mind). The Yamaha even have a degenerated input stage.
I don't see what's wrong with plenty of NFB. As Bruno explains in his F-word paper, there is a region where NFB will emphasize higher order harmonics. The answer to this is more NFB. Some high feedback designs from the 70s pushed LF feedback but had a low first pole, insufficent input stage current, nonlinear VAS, 2EF output stage. That meant that above 1 kHz they didn't have enough feedback to cover up the nonlinearities. I also remember designs from the 90s and 00s that in order to avoid that situation did dumb things such as using a capacitive load on the VAS instead of miller compensation (Yamaha AX 592 and Onkyo TX-NR 3008 come to mind). The Yamaha even have a degenerated input stage.
capslock, because of softstart in each of my devices, DACs, ADC, APU, and Scaler. All will not run without a softstrt circuit(p-mos based) due to a few thousand of LOW-ESR caps onboard. Even the fact that all phones can handle >.5A(ipads 2.1A, iphones 1A) at 5V USB rail can't help, inrush anyway higher.
Last time I checked, USB2 spec was at least 100uF on the host side of Vbus and less than 10uF on the device side before and during enumeration. The idea is that this ratio guarantees than Vbus momentary drop at plug-in inrush is less than 10%, keeping Vbus > 4.5V at all times.
Guys,
I have the TEK compliance and evaluation setup for USB (diff probe and software) here at the office as well as 2 protocol analyzers. Believe me especially in HS with high sample rates your getting USB errors and since Isosynchronous is not error correcting this can be a problem.
I have been asked to test more than 50 USB cables from $5 to $5K, I have some real dogs. So here is the problem and one of the reasons why HS USB sucks. So a DAC is primarily getting data from the host so BANG BANG BANG... then an IN request the cable, DEVICE and HOST must now turn around. Some of these cables have really low capacitance and yet they have terrible overhang. That's when the last transmitted signal is still present when the next preamble comes down and that packet is screwed.
The other problem is when you have a large packet, say DSD or 32/384 and that packed comes down and the device trains on the preamble, but by the end the clock is off enough that the samples at the end are not read correctly.
How do I know this, well the TEK was good at that, it didn't add up the BCC errors. They gave me the dev kit but who has the time to explore that much code to figure out how to keep track of errors? not me....
Anyway so I set this up:
HOST (MacBook Pro i9x6 32GB can bootcamp into WIN10)<==USB=>|Protocol Anyalyzer + TEK|<==>DAC--I2S |Prism I2S monitor|==>Stereo Out
Using known WAV files (they are easy, flat and I can save off the I2S and compare them) I can also look at the data at the protocol level.
HS has issues, it should have been full duplex from the start there would be less errors. FS not so much unless you have really crappy cables.
If you believe everything is perfect I will remind you of what my good friend Ed Robertson (Barenaked Ladies) said... Anyone who says they are perfect is lying.
I have the TEK compliance and evaluation setup for USB (diff probe and software) here at the office as well as 2 protocol analyzers. Believe me especially in HS with high sample rates your getting USB errors and since Isosynchronous is not error correcting this can be a problem.
I have been asked to test more than 50 USB cables from $5 to $5K, I have some real dogs. So here is the problem and one of the reasons why HS USB sucks. So a DAC is primarily getting data from the host so BANG BANG BANG... then an IN request the cable, DEVICE and HOST must now turn around. Some of these cables have really low capacitance and yet they have terrible overhang. That's when the last transmitted signal is still present when the next preamble comes down and that packet is screwed.
The other problem is when you have a large packet, say DSD or 32/384 and that packed comes down and the device trains on the preamble, but by the end the clock is off enough that the samples at the end are not read correctly.
How do I know this, well the TEK was good at that, it didn't add up the BCC errors. They gave me the dev kit but who has the time to explore that much code to figure out how to keep track of errors? not me....
Anyway so I set this up:
HOST (MacBook Pro i9x6 32GB can bootcamp into WIN10)<==USB=>|Protocol Anyalyzer + TEK|<==>DAC--I2S |Prism I2S monitor|==>Stereo Out
Using known WAV files (they are easy, flat and I can save off the I2S and compare them) I can also look at the data at the protocol level.
HS has issues, it should have been full duplex from the start there would be less errors. FS not so much unless you have really crappy cables.
If you believe everything is perfect I will remind you of what my good friend Ed Robertson (Barenaked Ladies) said... Anyone who says they are perfect is lying.
Attachments
Zung,
Here is a typical screen shot of the TEK finding a BCC error in a HS high sample rate array of 24bit samples. Sorry there is no way to group the data which makes it a bit of a pain when it's grouped in 16bit chunks like this.
Also if you don't think isolation is important here is an example of a well respected dac when I sent the JTEST down. Purple not isolated, Red isolated High Speed. CG and I have done a lot of isolation work. USB in general especially with USB powered devices like dacs and interfaces really need as much isolation as possible.
When we are talking cables another problem other than data is switching noise. Laptops are always better because of FCC regs but if you have ever tested computers for FCC the ports are typically like facets for noise. If the cable can keep that noise from getting to the device instead of pushing that noise towards the device, then the sound quality will be better.
Here is a typical screen shot of the TEK finding a BCC error in a HS high sample rate array of 24bit samples. Sorry there is no way to group the data which makes it a bit of a pain when it's grouped in 16bit chunks like this.
Also if you don't think isolation is important here is an example of a well respected dac when I sent the JTEST down. Purple not isolated, Red isolated High Speed. CG and I have done a lot of isolation work. USB in general especially with USB powered devices like dacs and interfaces really need as much isolation as possible.
When we are talking cables another problem other than data is switching noise. Laptops are always better because of FCC regs but if you have ever tested computers for FCC the ports are typically like facets for noise. If the cable can keep that noise from getting to the device instead of pushing that noise towards the device, then the sound quality will be better.
It's the switching noise on the mains, more CPU usuage, more noise which gets into the panel and so forth. Batteries will make it work better but even then I think the cable is transmitting more noise. Lower CPU usage = lower noise = better sound quality. This goes for circuit design as well.
Attachments
I tried USB spdif interface loopback 24/192k, it is extremely close to its theoretical limit 23.8 ENOB i.e. USB->spdif_out->spdif_in->USB chain literally ideal to me.
I can send/receive a file as well, but I see no reason at all.
PS: 2 different USB cables 10" and 60"($1-2 of each) in length have the same result.
I can send/receive a file as well, but I see no reason at all.
PS: 2 different USB cables 10" and 60"($1-2 of each) in length have the same result.
Last edited:
Solution to avoid any USB data loss on isosynchronous data transfer is to use optical USB cables. They are affordable and support USB 2.0/USB 3.2-10 Gbps. Ground isolation is not provided but I can't find any problem with that.
https://www.diyaudio.com/community/...able-for-dac-bitperfect-at-any-length.405629/
My understanding of the USB audio protocols (which may be wrong) is that the DAC buffers the data so if an individual packet is lost, it can request it to be resent?
Unfortunately, isosynchronous data transfer used for DACs doesn’t provide resending packet on error. ECC will keep errors low, but when error is irecoverable, packet is dropped with no resend. There must be multiple packets loss to hear anything.
My own subjective listening tests with standard USB cables up to 12m length (yes, way beyond specifications) has shown that on digital transmission, packet loss doesn’t introduce any gradual sound quality change, rather mere clicking or popping sounds, like when stylus hits a scratch on LP.
My own subjective listening tests with standard USB cables up to 12m length (yes, way beyond specifications) has shown that on digital transmission, packet loss doesn’t introduce any gradual sound quality change, rather mere clicking or popping sounds, like when stylus hits a scratch on LP.
The RME ASIO driver for ADI-2 Pro etc monitors and displays CRC errors for USB... in many years of usage I've never encountered any CRC errors, using bog standard cable, USB hubs and isolators in between.
I've also done hardcore stability tests, using digital loopback in the RME and playing a sine with REW and peak hold on in the RTA, any glitch would have been captured but they don't happen -- at least not from the USB transfer as such. If the sample rate is very high and maximum overlap is used, then REW does occasionally glitch when it doesn't get enough CPU share. General system load is sure a factor, as is general USB bus load on the used bus, at some point.
Me neither. I have done hour long bit perfect USB-I2S-USB digital loopback recordings even at 768k/32 with generic USB cables, though shorter than 2m.