DIYHiFi.org

For the sake of audio
It is currently Sat May 18, 2013 2:43 pm

All times are UTC




Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: ESS Sabre DAC Opinions?
PostPosted: Fri Apr 18, 2008 3:49 pm 
Offline
User avatar

Joined: Mon May 01, 2006 11:44 pm
Posts: 186
Location: Kansas City, MO
This seems to be big news over at the other place. Do you guys know what a "hyperstream modulator" is? Is this all bun, or is there some meat here? Curious minds want to know. I read the "white paper", but am still clueless.

_________________
He's not hi-fi, he's my stereo.
DIY projects:
http://www.ezdiyaudio.com


Top
 Profile  
 
PostPosted: Thu Apr 24, 2008 12:39 am 
Offline
User avatar

Joined: Fri Oct 20, 2006 11:04 pm
Posts: 406
I am in the process of laying my hands on one of those.


Top
 Profile  
 
PostPosted: Thu Apr 24, 2008 1:43 am 
Offline
User avatar

Joined: Mon May 01, 2006 11:44 pm
Posts: 186
Location: Kansas City, MO
peufeu wrote:
I am in the process of laying my hands on one of those.


Peufeu, you are clearly a smart dude. Do you have any idea about the following (all taken from a press release):

Quote:
A patented multibit Hyperstream modulator with dynamic matching using 48bit accumulator and 28bit data path allows true reproduction of audio as it is mastered at the recording studio.


or

Quote:
Another patent-pending time-domain jitter eliminator enables unmatched audio clarity free from clock jitter common in digital audio systems.


or

Quote:
In addition, the Sabre Reference integrates an all-digital SPDIF receiver and supports multi-channel digital audio in PCM or DSD formats.


Are some SPDIF receivers not all-digital? How is the receiver section different from CS8416 for example?

_________________
He's not hi-fi, he's my stereo.
DIY projects:
http://www.ezdiyaudio.com


Top
 Profile  
 
PostPosted: Thu Apr 24, 2008 7:58 am 
Offline
User avatar

Joined: Fri Feb 17, 2006 10:36 am
Posts: 190
Location: Silicon Valley, CA
Call me skeptically hopeful. The DAC may live up to the published performance specs, and probably it sounds very good in a careful implementation, but the marketing claims are clearly lacking 'truth in advertising'. 'Jitter free'? Yeah, and I've got a bridge to sell you....

A little reality check:

Reading through their white paper... the first thing that's obvious is that they're applying ASRC to all incoming data, in order to put it into the clock domain of a local XO. This means that any meaningful comparison should be done against a 'competitor DAC' which is also receiving it's data through an ASRC to bring the data into it's local clean-clock domain.

Still, this by definition cannot be 100% jitter-free, as at some point, the incoming data is arriving at some rate, determined by the source, and thus has to be buffered into the output clock domain, with a tracking mechanism to avoid buffer overflow or underrun... the rolloff frequency for the buffer tracking is naturally a function of buffer size, and by extension, latency through the buffer. So they're up against the exact same wall as all the other ASRCs on the market - AD1896, SRC4192, etc. - at an acceptable latency, jitter rejection can only be achieved above a certain frequency. Below that, the rate conversion ratio must track the relative drift between the the source and output clock domains... In the process, LF jitter from the source becomes hard-coded into the 'non-jittered' output data values. No way around it, the source and output are inextricably linked unless you're willing to accept an audio drop-out while the buffers reset, and loss of lip-sync if the audio goes along with a video stream. My money says the ESS chip's ASRC jitter rejection performance is in the same ballpark as the aforementioned ASRC chips, as that is what can technically be achieved given similar practical design constraints.

The jitter on their DAC side will of course be a function of how good their XO is, and how cleanly the resulting clock is delivered to the internals of the DAC IC. There's certainly no such thing as 'jitter free'. LOL

So there's your bun. Let's talk about the meat, then:

They do claim that their actual rate conversion algorithm is something different from the polyphase filters used in most ASRCs, and that it results in greater accuracy of the output data (-175dB DNR vs -144dB for the AD1896, if memory serves). This, I can believe, as it is certainly known that there are both excellent and very poor ASRC rate-conversion algorithms out there - it is definitely possible to do better than today's real-time chips if the rate conversion is done offline using a PC. No reason a better implementation can't be done for real-time conversion, either, given enough DSP horsepower. So if there's a reason for their ASRC to be better, I think the rate conversion algorithm would be it. I am rather curious what they're doing, if not polyphase filtering. One of these days I'll have to look up their patent.

More bun...

They have an interesting (nothing more than interesting, certainly not better from a performance standpoint, but cheaper and easier, yes) method for SPDIF input decoding, which looks to me like a good way to make a cheap SPDIF receiver, by simply avoiding most of the analog stuff that other SPDIF receivers use (mainly, the PLL). They probably transfer data into the buffer as whole sample words, which avoids the need to capture the timing of every edge. Their implementation also suggests to me that they are strictly dependent on the use of the ASRC (which I presume cannot be bypassed as a result). Not a big deal if it's a good ASRC, but it is one more processing step in the signal chain.

Finally, a slice of cheese and a pickle:

The sigma-delta techniques they're using are also clearly different, and looks promising. It sounds like they're on the right track with regard to how transients are handled. But, I still have to wonder, is any sigma-delta DAC ever going to produce dynamic (transient) output as clean as a good 'ol multibit DAC? Careful dithering applied to a good multibit DAC still seems like the best way to go. Too bad multi-bit silicon is expensive, and dying a slow, painful death.

_________________
- Chad.
__________________________

"Fashion is mistaken for good design; moral fashion is mistaken for good." -- Paul Graham


Top
 Profile  
 
PostPosted: Thu Apr 24, 2008 11:21 am 
Offline
User avatar

Joined: Mon May 01, 2006 11:44 pm
Posts: 186
Location: Kansas City, MO
Chad, thanks for taking the time to write that post! :clapping: Would you say the performance is then limited by the XO and output stage?

_________________
He's not hi-fi, he's my stereo.
DIY projects:
http://www.ezdiyaudio.com


Top
 Profile  
 
PostPosted: Thu Apr 24, 2008 1:38 pm 
Offline

Joined: Mon Sep 25, 2006 2:43 pm
Posts: 15
Quote:
One of these days I'll have to look up their patent.


http://patft.uspto.gov/netacgi/nph-Pars ... PN/7330138

_________________
Choose kindness.


Top
 Profile  
 
PostPosted: Thu Apr 24, 2008 3:10 pm 
Offline

Joined: Mon Sep 25, 2006 2:43 pm
Posts: 15
Better link: http://www.pat2pdf.org/patents/pat7330138.pdf

_________________
Choose kindness.


Top
 Profile  
 
PostPosted: Thu Apr 24, 2008 3:41 pm 
Offline
User avatar

Joined: Mon May 01, 2006 11:44 pm
Posts: 186
Location: Kansas City, MO
BrianDonegan wrote:


Ooh, lots of fun reading. Thanks! :good:

_________________
He's not hi-fi, he's my stereo.
DIY projects:
http://www.ezdiyaudio.com


Top
 Profile  
 
PostPosted: Fri Apr 25, 2008 5:00 am 
Offline

Joined: Wed Feb 13, 2008 5:24 am
Posts: 8
hifizen wrote:
Call me skeptically hopeful. The DAC may live up to the published performance specs, and probably it sounds very good in a careful implementation, but the marketing claims are clearly lacking 'truth in advertising'. 'Jitter free'? Yeah, and I've got a bridge to sell you....

A little reality check:

Reading through their white paper... the first thing that's obvious is that they're applying ASRC to all incoming data, in order to put it into the clock domain of a local XO. This means that any meaningful comparison should be done against a 'competitor DAC' which is also receiving it's data through an ASRC to bring the data into it's local clean-clock domain.

Still, this by definition cannot be 100% jitter-free, as at some point, the incoming data is arriving at some rate, determined by the source, and thus has to be buffered into the output clock domain, with a tracking mechanism to avoid buffer overflow or underrun... the rolloff frequency for the buffer tracking is naturally a function of buffer size, and by extension, latency through the buffer. So they're up against the exact same wall as all the other ASRCs on the market - AD1896, SRC4192, etc. - at an acceptable latency, jitter rejection can only be achieved above a certain frequency. Below that, the rate conversion ratio must track the relative drift between the the source and output clock domains... In the process, LF jitter from the source becomes hard-coded into the 'non-jittered' output data values. No way around it, the source and output are inextricably linked unless you're willing to accept an audio drop-out while the buffers reset, and loss of lip-sync if the audio goes along with a video stream. My money says the ESS chip's ASRC jitter rejection performance is in the same ballpark as the aforementioned ASRC chips, as that is what can technically be achieved given similar practical design constraints.

The jitter on their DAC side will of course be a function of how good their XO is, and how cleanly the resulting clock is delivered to the internals of the DAC IC. There's certainly no such thing as 'jitter free'. LOL

So there's your bun. Let's talk about the meat, then:

They do claim that their actual rate conversion algorithm is something different from the polyphase filters used in most ASRCs, and that it results in greater accuracy of the output data (-175dB DNR vs -144dB for the AD1896, if memory serves). This, I can believe, as it is certainly known that there are both excellent and very poor ASRC rate-conversion algorithms out there - it is definitely possible to do better than today's real-time chips if the rate conversion is done offline using a PC. No reason a better implementation can't be done for real-time conversion, either, given enough DSP horsepower. So if there's a reason for their ASRC to be better, I think the rate conversion algorithm would be it. I am rather curious what they're doing, if not polyphase filtering. One of these days I'll have to look up their patent.

More bun...

They have an interesting (nothing more than interesting, certainly not better from a performance standpoint, but cheaper and easier, yes) method for SPDIF input decoding, which looks to me like a good way to make a cheap SPDIF receiver, by simply avoiding most of the analog stuff that other SPDIF receivers use (mainly, the PLL). They probably transfer data into the buffer as whole sample words, which avoids the need to capture the timing of every edge. Their implementation also suggests to me that they are strictly dependent on the use of the ASRC (which I presume cannot be bypassed as a result). Not a big deal if it's a good ASRC, but it is one more processing step in the signal chain.

Finally, a slice of cheese and a pickle:

The sigma-delta techniques they're using are also clearly different, and looks promising. It sounds like they're on the right track with regard to how transients are handled. But, I still have to wonder, is any sigma-delta DAC ever going to produce dynamic (transient) output as clean as a good 'ol multibit DAC? Careful dithering applied to a good multibit DAC still seems like the best way to go. Too bad multi-bit silicon is expensive, and dying a slow, painful death.


Hi Chad,

Glad to see the interest in the part. I do have a bit of insight into some of the ways the chip works.

I just wanted to point of a couple things, just for the sake of clarity. Obviously I cant say Exactly how we did the ASRC other than that which is written into the patent. But basically it doesn't use any buffering or FIFO method. THe latency throught the whole chip is 833uS at 44.1kHz sample rate, including the ASRC blob. The ASRC does have to lock onto the input rate, I just did it with a bandwidth of 0.1Hz.

You are right about the SPDIF, when using that input mode, you MUST use the ASRC, when using the DSD or PCM inputs the ASRC is optional and can be bypassed altogether.

The DAC used a 6/7/8 ot 9 bit noise shaped modulation before going into a DEM scheme. So I guess it is a multibit DAC in that regard.

I am happy to answer any questions that I am "allowed" to, basically, what that means is I cant go into too much detail more than what the patents diclose. Anyways, hope you get a chance to critique the DAC.

Thanks

Dustin


Top
 Profile  
 
PostPosted: Thu May 01, 2008 3:24 pm 
Offline
User avatar

Joined: Tue Jan 31, 2006 4:16 pm
Posts: 567
Location: Zinzinnati, Ohio
Gang,

First thanks Dustin for contributing here. Guys this is Dustin's chip he's the one on the patent.

I have the eval board here and have been working on the device for a couple of months. First off and hat's off to Dustin the S/N on this critter is off the charts. I am getting about 134dB on my Prism dScope!!!!!!

I have been working on a dac module for the Crimson using the Sabre. At first I was just going to use opamps and voltage mode output but my tests kinda kill the S/N ration when using it that way (below 120dB) and I hate opamps so I am going to look at some other avenue's for a discrete differential to single ended output. Down to 8 transistors at this point.

The supplies on the part are pretty forgiving. I have been working the last 3 months on regulators with Jocko, CG and Charlies help I think I have some pretty good ideas for making this a stellar design.

Since the Crimson is based on the TAS1020B each module has to have ASYNC USB clocks in this case 22.5792 and 24.576 which become MCLK into both the Sabre and the TAS1020B. The module also then has the output analog section and all the regulators.

The size of the module requires a 4 layer board. I use top and bottom for signals and the power plane has discrete traces for the 1.2V, 3.3v digital and 3.3v analog sections. There is a ground plane and all of this stuff is smd including the discrete regulators.

I may try a stab at a discrete voltage output first as that might be the way to go. Something like 2SK170's and stuff...

Ahhhhh it's so hard to proto this kinda stuff without board level examples.

Also guys the jitter attenuation on this part is killer!

Good work Dustin!
Thanks
Gordon

_________________
Gordon
Chief Scientist
Wavelength Audio


Top
 Profile  
 
PostPosted: Thu May 01, 2008 4:41 pm 
Offline
User avatar

Joined: Fri Oct 20, 2006 11:04 pm
Posts: 406
dusfor99 wrote:
Glad to see the interest in the part. I do have a bit of insight into some of the ways the chip works.


Hm, isn't that some kind of understatement ????
I'm impatient to hear it, in any case. Unfortunately this will happen after the current project (FPGA+Ethernet...) has digital audio to output.

Oh yeah, and what about that differential clock input ?


Top
 Profile  
 
PostPosted: Fri May 02, 2008 8:06 am 
Offline
User avatar

Joined: Fri Feb 17, 2006 10:36 am
Posts: 190
Location: Silicon Valley, CA
BrianDonegan wrote:


Thanks Brian, I'll take a look...

_________________
- Chad.
__________________________

"Fashion is mistaken for good design; moral fashion is mistaken for good." -- Paul Graham


Top
 Profile  
 
PostPosted: Fri May 02, 2008 9:07 am 
Offline
User avatar

Joined: Fri Feb 17, 2006 10:36 am
Posts: 190
Location: Silicon Valley, CA
dusfor99 wrote:
...The ASRC does have to lock onto the input rate, I just did it with a bandwidth of 0.1Hz...


Ahh, I see what I had overlooked in my initial assessment - the AD1896 and others are intended for pro audio applications, and are designed to accept and track a widely varying input rate. Thus, in order to meet their conditions of avoiding data starvation or overflow, the rate-ratio filtering in those parts has a corner frequency of roughly 3Hz in the slow mode, much higher in the 'fast' mode. Jitter rejection (aka stability of the rate ratio used for the actual conversion) is at about -55dB @ 100Hz for the AD1896 in it's favorable 'slow' mode. I'd expect roughly a 25-30dB advantage in jitter rejection by setting the corner frequency down to 0.1Hz. The second factor I overlooked was that polyphase filtering requires a bunch of samples to work on, whereas it appears the Sabre DAC's interpolation scheme does not require more than two samples to operate on.

So, the lower corner frequency looks good to me... definitely an improvement over the existing chips.

I am mildly concerned with the interpolation scheme of the ASRC itself, however. Please forgive me if I'm off base here, as I've only had a quick look at the patent so far, perused the diagrams, but haven't yet read the full text (it's late, going to bed soon...). But, it looks to me somewhat like the interpolation scheme is a simple zero-order hold, with linear interpolation for the first output sample immediately after a change in input sample. The linear interpolation is chosen on the basis of a phase comparison between the input and output clocks (presumably this is what gets low-pass filtered), so that it is known when, relative to the output clock, the input changed value. This should, as the patent describes, correct for the difference in area, and therefore correct the error due to differing timing of the output clock. But, it seems to me that this is not really a 'pure' upsampling, in the manner that a FIR-based conversion is.

It's hard to describe this without a diagram, but that is to say, the output waveform will not trace the curvature of the band-limited analog waveform represented by the input data stream. Instead, it will track the stair-step waveform of the input data itself, with little corrections for the missing area at each step. So the output data (assuming it is always a higher frequency, as indicated in the patent), now has some high-frequency content introduced by the zero-order hold. By comparison, a polyphase filter / sin(x)/x interpolation will not introduce any frequency content above the bandwidth of the polyphase filter. So, in order to remove these high frequency artifacts, and achieve the original objective of upsampling (lower-order analog reconstruction filters after the DAC), it seems to me that the post-ASRC data should go through a FIR sin(x)/x filter to remove those interpolation artifacts, before the data goes to the DAC modulators. Also, the accuracy of the error corrections at each step are dependent upon the resolution of the input vs. output phase measurement, so that may be a limiting factor in the performance of this ASRC (as it is for the polyphase FIR method as well), but I'm assuming the chip designer(s) understood this and took it into account.

So, I'm interested to know, is the ASRC mechanism followed by a sin(x)/x FIR brickwall filter, which will remove any out-of band artifacts introduced by the ASRC (and presumably also upsample further to a higher sample rate)? If not, it seems moot to upsample all the way to the final sample rate using this ASRC.

_________________
- Chad.
__________________________

"Fashion is mistaken for good design; moral fashion is mistaken for good." -- Paul Graham


Top
 Profile  
 
PostPosted: Fri May 02, 2008 4:37 pm 
Offline
User avatar

Joined: Fri Feb 17, 2006 10:36 am
Posts: 190
Location: Silicon Valley, CA
Well, OK I did notice now that that there is an oversampling filter before the ASRC in the ES9008 block diagram. So, that should imply that the ASRC's high frequency artifacts should be shifted higher in frequency than the base sample rate... up to whatever the oversampled sample rate is, going into the ASRC. Hopefully that is far enough out into the ultrasonic range not to be a problem... in all probability swamped by the HF content of the sigma-delta modulators.

BTW - Thanks Dustin for posting your comments ... always great to have a direct line to the engineer who can answer the detailed technical questions with authority.

I would like to see some performance data for the oversampling filters (before the ASRC)... frequency response (detail of passband ripple, cutoff transition, stopband attenuation). Is it possible to bypass the oversampling filter at the input as well, and just use an external oversampling filter to send, say, 8X or 4X oversampled data direct to the ASRC / DAC section?

Starting to like this DAC a lot... :)

_________________
- Chad.
__________________________

"Fashion is mistaken for good design; moral fashion is mistaken for good." -- Paul Graham


Top
 Profile  
 
PostPosted: Sun May 04, 2008 5:32 pm 
Offline

Joined: Wed Feb 13, 2008 5:24 am
Posts: 8
Hi Chad,



Currently there is no way to directly bypass the OS filter and pump 4x or 8x data into the ASRC section. A "hack" would be to use whats called "slow rolloff" mode which doesn't have the stopband attenuation of the sharp rolloff, but its has muxh muxh less inband ripple. You could then use your own blend of OS filter from a DSP or FPGA and fire the data to the data at a rate of up to about 350kHz. (It may go faster on most chips, but the slowests ones should be able to do this rate)

About the ASRC, your right, it only needs the sample before, the sample after and the phase error of the clocks to know how to correct for the ASYNC rates. What I haven't spent any time on is comparing this ASRC method to others, acutally, I only found out how others worked after this one was being sampled and people wanted to know whats different about it from the other methods. I guess the best thing to do would be to get a test board off the distributor, or even the guys as Twisted Pair have a design going. Of course for the enthusiants, you may even want your own board and that would be good too.

Thanks

Dustin


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group