|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
147.145.40.44
I just found this forum here and have been reading everything, I finally have a little free time so I'm going to make my BIG post on the subject.First off I've been playing around with my own DAC implementations for quite sometime and have a pretty good feel for whats going on, and even have some plausible theories for what I hear. About 6 months ago I started looking into the USB audio interface issues and how they fit into what I have learned so far.
What I have found agrees with what Thomas has been saying. I've come up with two main points for getting the best sound. Of course this is not ALL that is required, you still have to do all the normal stuff like extremely good power supplies, very low jitter clocks etc, that stuff doesn't go away. If a certain implementation doesn't have these it doesn't mean its going to automatically sound awfull, just that its not achiveing its full potential.
The main precepts are:
If you want the best USB audio you have to go with the asynchronous mode.
Anything that includes S/PDIF in the chain is going to be compromised.
Unforunately there are VERY few implementations that do this, and I'm not quite sure why.
The reasons for these two have already been stated here recently so I won't go into a lot of detail, just the quick over view.
Any implementation using synchrounous or even adaptive mode HAS to have a clock generated by some form of PLL, this is always going to be worse than running the DAC directly off a really good clock. As audiengr has found using a really good clock to feed the PLL circuit can help significantly, but it can never be as good as no PLL at all.
The perils of S/PDIF are well understood, but its not just the "cable" and connector thats a problem. Even feeding a good S/PDIF signal to a receiver on the same chip STILL has a PLL in the path. Even with a reclocker after the receiver its not at its best. A while back I built a DAC with a Tent clock driving the DAC with a reclocker and FIFO and STILL had audible effects from the S/PDIF. As long as the PLL is on the same board or box the correlated jitter from the PLL manages to work its way to the DAC, usually as noise in the power supply (that especially includes the ground). Its incredibly difficult to get rid of this stuff.
So what that means is we need a system that uses async mode and directly outputs I2S signals to a DAC that is clocked by an ultra low jitter clock. The TAS1020 chip does exactly that. The problem with this chip is that its not simple to use. At its heart is a 8052 MCU, at powerup it reads in the code for its operation from an external EEPROM. Almost all the implementations using the 1020 use the synchronous mode, my guess is that is what is in the "sample" code distributed by TI, so most implementations just do simple tweaks to the code or maybe even use it as is.
In order to use async mode and I2S some programming is going to have to be done. The datasheet from TI is woefully absent in any real useful information on programming this chip. I presume they have something they send to "developers" otherwise nobody could ever get this thing to work at all. I haven't bought the evaluation board, but maybe it comes with the details and thats how you are supposed to get them. Does anybody know where the details on programming this chip are located?
Gordon, If you've managed to read this far, I'd be very interested to know how you achieved this with your design. I certainly don't want you to post any code you've written, thats your IP for sure, but if you wouldn't mind I'd love to know what chip you used and where you got the detailed information on programming it. You don't have to answer if you don't want to.
On a completely different subject I'd like to make a few observations on digital filters.
I've been looking into the subject of digital filers and CD playback for a long time. For a living I work on very complex custom chips and have worked with some experts in DSP matters. From looking at what other chip makers and high end companies have done we came to the conclusion that nobody has yet done a CD digital filter correctly. Every implementation we looked at was a significant compromise. Different implementations have different compromises which do effect the sound.
It turns out that in order to implement the digital filter correctly takes a huge amount of resources (which is why all designs were compromises). It turns out that it CAN be done right in the size chips that I work with, but it would cost a fair amount of money. The chips would be too expensive for someone like TI to make, the market for the expensive chips would be way too small and the high end companies that would be willing to spend the per piece price can't afford the engineering and setup charges such a chip would take. The approach that some high end companies have taken, using DSP processors, doesn't give nearly enough horsepower either.
I think the above is a primary reason why NONOS has caught on so much. Its not that a digital filter is bad, its that all implementation you can get out there don't do it right. Getting rid of the filter altogether sounds better. I also don't think that the oversampling per say is really a big issue, but that almost all oversampling DACs include digital filters so whenever you hear an oversampling DAC you are also hearing the compromised digital filter.
Some of the recent very good oversampling DACs have a mode that turns off the digital filter, I propose that we should make some implemetations using these DACs with the filter turned off before we throw out the oversampling DACs altogether. Unfortunately the filterless modes are not easy to implement! For some reason when you put the DAC in filterless mode you can't use the regular I2S input stream, you need to use a different protocol and pins on the DAC!!!
Given all the above, a really good thing to try would be a USB DAC using the 1020 in async mode, programmed so it provides this other interface and feed it to one of these new DACs in filterless mode, then use a transformer output stage which does a good job of the remaining filtering necessary. I think this would be a really exceptional device.
Thats probably way more than enough for one message so I'll quit now.
Follow Ups:
"From looking at what other chip makers and high end companies have done we came to the conclusion that nobody has yet done a CD digital filter correctly. Every implementation we looked at was a significant compromise. Different implementations have different compromises which do effect the sound. "What then are the typical limitations and compromises you have seen?
What do you feel are the basic requirements for a reconstruction filter done right?
John,I agree with all your statements. I do not use the 1020, but did consider it as I have designed some hardware using the 8052. I really hate these microcontrollers Intel did not do the best job for these.
I really do not think the 8052 has the capacity to do the digital filters. If you want that you might want to try the Cypress chip that has a 16 bit dsp engine and 2.0 frame work. But really why do filters at all. The accumulator even in the best DSP's loses information. Then there the conversion from either high bit fixed or floating point to what ever the output is. This is the reason NONOS has caught on... all the ones with digital or analog filtering is flawed.
If you feel the filter is necessary, then you may want to cascade on a DSP for that or even a BB PCM filter.
Any good dac will give you the ability to use I2S from some sort of option. Or you can use a PAL or something to convert it.
John, maybe a good start would be the EVM from Ti. I linked it below...
Another thing... USB TO SPDIF... I think this too be better than SPDIF out of a transport for the following reasons:
1) Transport does not re-read on errors
2) USB controllers where designed for USB audio and have good buffering.
3) SPDIF receiver is not trying to hit a moving target such as the transport reading the center of the disk or the outside of the disk. The clock is pretty much dead on all the time even in isosync mode.Thanks
Gordon
J. Gordon Rankin
Thanks for this, John. Extremely well thought-out and articulated. It matches what I've heard so far and (possibly) explains why most of the oversampling machines I've heard so far leave me cold. In your assessment, do you know of any USB DACs that have taken the *right* approach to this problem? I'd be very curious to know if there are any options that are available to "the common man".Thanks,
Kudos to you for your research and response. And thanks to Thomas and dburna for their insight.I really like NONOS DACs, but I have to agree, I think the problem with standard DACs probably lies with the implementations of digital filters.
In the VRS, we tried every type of software oversampling and upsampling, and we always preferred the sound without. The music always sounded slightly more etched and mechanical using them. While the VRS does not use a NOS Dac, we reduce any resampling of the signal we can.
IMHO, if you can stay away from SPDIF interfaces of any kind, you better serve the music. SPDIF really changes the sound of music for the worse. In fact many CD players use SPDIF internally and it is one of the causes of CD sound. The fact that the USB DACs that are out there now also use SPDIF is why we don't currently recommend them.
Ethernet as a transport mechanism is flawless, if you are moving whole files. The minute you begin to use it to stream files, the data becomes susceptible to timing errors. However, the Ethernet streaming devices that we have heard are markedly better than SPDIF devices in sonics, and we theorize that less jitter is generated. However, some Ethernet streaming devices use SPDIF in the path, and they generally sound worse (two sources of jitter?).
The bottom line in our theory is that anytime you stream music data to a device, be it USB, SPDIF (internally or externally) or Ethernet, you compromise the signal integrity. That is why our systems are built around analog outputs for most customers. The only way to transport music data cleanly is with a master clock sync, as the professional world does (and our digital outs do), but consumer DACs rarely offer this.
Master clocks are an expensive proposition but are really not needed for a simple playback chain.As long as you can use a completely independent clock at the last step of the conversion then I don't see any argument of why an USB or Ethernet solution can not achieve equivalent quality.
As long as you synchronously empty a buffer with this last clock that is being kept filled by asynchronously pulling data over USB or Ethernet then all jitter experienced on the way to this last buffer does not matter. You are effectivley making this last clock the master clock in your setup.
Would you agree with that reasoning?Cheers
Thomas, what you are proposing does seem superior to the state of the commercial products I am familiar with. However, my ears are my final judge, and I have not heard an implementation such as you have described.Are you saying that the Apple Airport works this way?
Very interesting. My understanding was that almost all Ethernet connected media receivers work this way. All the boxes that use the DLNA profile of UPnP-AV pull the data down to the reciever via asynchronous HTTP downloads. Examples areRoku Soundbridge, Fosagte Omnifi, DLINK DSM-320, ...
In fact while I don't know how the Apple receiver is implemented I don't know of any Ethernet receiver that is not working this way.
Do you have an example of a commercial product that works differently?
Cheers
Also, if these Ethernet receivers have sonic "disabilities," I'd like to know that as well. For instance, will any of them accept FLAC, Apple Lossless, etc?On an unrelated note, are there any NONOS DAC's (USB or otherwise) that support higher than 16/44? If a chipset can support 24/96, is that only via upsampling?
Thanks, -dB
Both the Roku and the Slim Devices units stream flac. What it actually does is convert the flac file to wav at the server (your host computer) and stream the wav.
This is an interesting idea. Thomaspf, don't think that I'm wedded to USB as an alternative. Have you looked into these options (Roku, Fosgate, DLink, others?)? Are there any options that would simply stream 'digital out' in some lossless format to a conventional DAC? If so, would they provide a truly audiophile solution, or do these options continue to have S/PDIF or other jitter-related problems? Frankly, an Ethernet solution that would enable me to work with a conventional DAC would be the optimal solution....at least until a major technology shift.If any of these boxes presents a truly comparable audio potential (in your opinion), please let me know.
I have seen a couple of those but I never opened them up. I have not seen a really high end model but given the list of DLNA companies I suppose that is just a matter of time.These units all have built-in DACs and then also S/PDIF outputs. You can probably mod the local DAC and analog outputs really well and even built a very good digital output. However, all the problems surrounding S/PDIF on the receiving side within your DAC will stay with you.
Cheers
This post is made possible by the generous support of people like you and our sponsors: