ESS Sabre Reference DAC (8-channel)

fmak said:


-----------------------------------------------------------------------------------

I am not sure Pics will help as the source is a satellite receiver with the AK4351. The following may help you make an assessment.

AK4351 LRCK 48 kHz 1.6Vdc bias; BICK around 2.8 MHz 1.6Vdc; SDATA typical eye pattern signal 1.6Vdc; MCLK 12.2896 MHz around 1Vdc.

I coupled these to the Twisted Pear board LRCK, BCLK, DIn with and without blocking cap, MCLK and all I get is noise from the AK analog output and silence from the 8804 spdif output. For some reason my external dac indicates lock on at quad speed (??). The WM PCM input terminals have similar dc biases with no signal input and therefore I assumed that it was ok to couple. Anyway there has been no damage.

Would apprecaite your help

Either I have made a mistake or there is a timing issue?

Fred

Did you make sure you have the transceiver setup for the correct PCM format? Is it I2s, LJ, RJ? 24 bit 16bit?

Please reply in the support forum.
 
peufeu said:
No, I don't know what's in the Saber board, but I would like to find out. When my DAC test platform is done I definitely plan to include the Sabre in the list of its victims.

Also about the price of this Audiopraise gizmo : I would calculate amortization of 1 month of designer time over the number of sold gizmos ; if they sell 50 the price is justified, if they sell 1000, well...

Question for Dustin :

So, the Sabre has an ASRC in it.
What happens if I use the same clock in the data input and in the low jitter clock input ?

Clarification :

Suppose I have a source of digital audio data which can either run on its own clock or accept an external clock (this can be a transport, soundcard, whatever).

I input the digital audio data from this source in the Sabre.

Now, if I make the source use the DAC's internal clock (the one the Sabre uses for its low-jitter circuits), the ASRC becomes useless then.

So, what does the Sabre do ? Does it still use the ASRC, or does it just use a FIFO ?


1 month? Man I wish I could do it that fast.

If you use the same clock, then your right the ASRC is renedered useless by definition. It simply doesn't do any corrections to the datastream. There is no "FIFO" in this asrc.

Thanks

Dustin
 
to peufeu:
Just stop me if I'm wrong, but even if you clock the source from the clean clock inside the DAC, you may still get jitter: how well does the source clocks its output from the incoming clock? And there may still be a little bit of jitter from the cable or fiber used.

So ASRC may not be very usefull, but may help reduce any residual jitter?

I asked myself a similar question: what if I want to use a wordclock. Looks like a waste or time with this DAC.

Anyway, the device I have in mind will have WC input and output (from the TC dice chip) so why not wire it...
Just finished reading the 350 pages datasheet of this chip. Not everything is clear... Why can't everybody write as good datasheets as Analog Devices or Wolfson :'( .

I just asked ESS for the datasheet as it doesn't appears to be online anymore. I hope it will be well done :)
 
A DS marked "confidental advance information" I managed to get, with some hints in this thread, somewhere. Same for the demo board schematic...

The DS ist not that complete as one wants it to be... thus the many additional breadcrumbs from the designer in this thread...

To Russ and all the other contributers to this project: Two thumbs up! This thingie really seems to be the DAC of choice, could become a DIYA reference project.

- Klaus
 
NeoY2k said:
to peufeu:
Just stop me if I'm wrong, but even if you clock the source from the clean clock inside the DAC, you may still get jitter: how well does the source clocks its output from the incoming clock? And there may still be a little bit of jitter from the cable or fiber used.

Ah, well, of course, anything that is recovered from SPDIF is full of jitter anyway. That's why you reclock with a few D latches (on multibit DACs) or you feed the DAC a clean clock on its MCK (for sigma delta's).

Note that a clean clock can be a XO in the DAC to which the transport is slaved, or a cleanly recovered clock from SPDIF, a la Tent (analog PLL), or with a digital PLL. As long as the clock and the data source are synchronous, you don't need an ASRC... so I'm wondering what the ESS DAC would do in such a situation, still use the ASRC or not ?
 
peufeu said:
. so I'm wondering what the ESS DAC would do in such a situation, still use the ASRC or not ?

I think that's been established, ASRC would be there, but would not be doing much to correct things if they are already correct.

Interestingly, there is a register to disable "jitter correction" but I am not sure exactly what this implies for the data.

Cheers!
Russ
 
KSTR said:
To Russ and all the other contributers to this project: Two thumbs up! This thingie really seems to be the DAC of choice, could become a DIYA reference project.

- Klaus

Thanks Klaus,

I have been listening to Buffalo for many hours now. I can say I would not be surprised the Sabre chip was to be the new benchmark DAC.

I have to say I would have never imagined this chip coming from ESS, but Dustin and Co.have a real winner on their hands.

My hope is that it becomes a bit more available to DIY folks. That is that they can buy say one or two chips, not just qty >= 5.

Cheers!
Russ
 
For WMS:

Hi + thanks for your posts. I'm extremely interested in a passive I/V transformer coupled output stage for the Buffalo. I'd be grateful if you could keep us (well, me at least) posted on your findings with a schematic and component values when available.

Very much appreciated, Steve
 
Peufeu: I'm not that sure that recovering a MCLK from a wordclock derivated from the DAC to clock the transport will give better results that having a cleanly clocked source and let the Sabre do the reclocking. PLLs are so far from perfect... (even 4th order ones).

Anyway, as I'll use a Dice chip, i'll have wordclock in/out and masterclock in/out, so I'll be able to experiment quite a lot. But the Dice board will be quite hard I think...

I have to start by designing my own eval board for it (1500$ the eval board is a joke. I'll make a simple board and connectors for wrapping stuff around it).

But the DAC board is for within two weeks!

- The DAC board itself, with regulators for the digital and the analog part. i2s and i2c on a connector.

I still have questions on ground planes decoupling between AGND and DGND.

- The XO board (with it's own regulators, just plugs near the DAC).

- The power supply board

- The IV board (plugs at the end of the DAC board) with it's own regulators for each channel, and relays for switching outputs between 8 channels mode and 2 channels mode.

This gives me high connectivity and easy debugging (and higher PCB costs, sic). Just: I know wires have to be kept short from the output of the dac to the IV stage, is it still ok to have plugs or relays on it?

Thank you
Nicolas
 
Russ White said:


I think that's been established, ASRC would be there, but would not be doing much to correct things if they are already correct.

Interestingly, there is a register to disable "jitter correction" but I am not sure exactly what this implies for the data.

Cheers!
Russ


"disable jitter rejection" will simply shut the correction engine off and therefore should ONLY ever be used with a synchronus (phase alligned, not just the same frequency derived from another source) mclk. So basically, it will revert to the same way every other DAC out there does it if you dont like the asynchronus way Martin/I proprosed. If you still want to try the Sabre but already feel you have a extremely well done transport with low phase noise clock then this option might be for you. I would be very interested to see someone do this and compare the sound. ie, comapre the sound of

1. Sabre in snynchronus mde, with very high end transport with low jitter mclk.

2. Crappy transport full of jitter, then let the Sabre do its thing.


From a mathematical point of view, the Sabre will start to attenuate the jitter at around 0.1Hz or so, so I would like to see this comparison done.


Thanks

Dustin



Ohh, by the way, I saw someone asked if you can monoblock. You can do this, and then tie all 8 cahnnels together into 1 I/V stage, however it would require some exturnal coding to get the same data on both channels in the I2S/LJ/RJ serial source. THere is no option to set a register in teh chip to wire it all together. You guys just keep thinking of using it in ways I didn't Which is really good. ;)
 
I would be very interested to see someone do this and compare the sound. ie, comapre the sound of

1. Sabre in snynchronus mode, with very high end transport with low jitter mclk.

2. Crappy transport full of jitter, then let the Sabre do its thing.

Of course you realize that case 1 is not possible if SPDIF is used ?
The options that are OK in my book are :

Option A - Low jitter Master clock in DAC, feeding DAC directly, source slaved to this clock.
I have slaved :

- a CD player (worked well but the player died, I had overlooked the fact that CD723 if not receiving a clock will bug, smash repeatedly the lens into the disc 10 times per second, and shortly expire, well no big loss, it sucked anyway),

- an RME soundcard (worked a lot better, since you can use Amarok and store 1000 CDs as FLAC on RAID5, so convenient). This one was extremely easy, I encoded a silent SPDIF containing only the Master Clock, fed this to the RME, the "Lock" LED lights on the soundcard, and that's it, it's synchronous. Looking on the scope, it's very easy to see, trigger the scope on WordClock coming out of the SPDIF receiver and display WC on one trace, Master clock on the other, plug the clock link in the soundcard, and both traces freeze. CS8412 working in double-buffer mode means you have no worries about clock phase.

- an Ethernet FPGA module with packetized audio transfer from a Linux PC, using UDP, works well, receives clock from DAC, outputs I²S. Version 2 is in the works. The nice thing is, you have 100 Mbps at your disposal, channels, sample rate and bits per sample are your choice. Wether you process signals in the PC or the FPGA, your choice.

Option B - Receive SPDIF from transport, use a local VCXO to derive clock, using a suitable low-jitter PLL scheme. Analog PLLs are tricky, AFAIK only Tent succeeded. Digital PLLs with a FIFO and a uc seem to be easier. V2 of the FPGA module will have that feature.

A clock that has been SPDIF-encoded, or a clock that has travelled in a feet of flat cable with data signals and a shared ground, will not give good sound quality. LVDS over twisted pair could make it work, but why bother ? Either be incompatible and put the clock in the DAC, or be compatible and use a proper clock recovery (ie VCXO PLL).

Now, if the Sabre has an ASRC that is as good as it seems to be, things could get simplified, just give the Sabre a good clock and let it handle the rest.

I would like to test that.

I am making a modular DAC platform with the FPGA module (with Ethernet, SDRAM, and lots of IO), a baseboard with lots of digital audio IO (SPDIF, ADAT, wordclock, etc, clock in, clock out, optical, twisted pair, etc), a module with the local clock (XO or VCXO) and associated logic, and then plug-ins for DACs, IV and outputs. I took excruciating care of the layout and sensitive signal paths. The hardest part was the FPGA module, the PCBs will be sent for fabrication this week, after that, in a couple months it should be wrapped up.

This will be an open project, I want several people to participate in development (JACK driver, foobar driver, filters, GUI, etc) and in evaluation (listening to various DACs and exchanging modules, etc). I would like to include the Sabre in there, too.
 
Disabled Account
Joined 2008
dpaws said:
For WMS:

Hi + thanks for your posts. I'm extremely interested in a passive I/V transformer coupled output stage for the Buffalo. I'd be grateful if you could keep us (well, me at least) posted on your findings with a schematic and component values when available.

Very much appreciated, Steve


That would be very useful for me!
Thanks WMS and Steve.

hirez69
 
4real said:
Okay. That's actually not extremely low. Is there a reason for this? Other high-end dac's having such a deed stopband have far less bandpass ripple. How about pre-echo?


By pre-echo I assume you mean the begining the the impulse responce of the filter before the main "lobe" I guess it could be called. The impulse responce is almost symmetrical due to the fact the there is an FIR and IIR filters in the path. The reason for only 0.005dB is that I wanted 120dB image rejection, and with the amount of taps in the filter, that is what you get.


Thanks

Dustin
 
dusfor99 said:

Ohh, by the way, I saw someone asked if you can monoblock. You can do this, and then tie all 8 cahnnels together into 1 I/V stage, however it would require some exturnal coding to get the same data on both channels in the I2S/LJ/RJ serial source. THere is no option to set a register in teh chip to wire it all together. You guys just keep thinking of using it in ways I didn't Which is really good. ;)

Indeed, althought it may be a small number outside of DIYland, there is likely interest in interfacing the output of a DF such as the PMD-100 or PMD-200. The thought of HDCD feeding the Sabre is a facet of what got my attention. In fact, the way this thread has many of us salivating, you would think there are some fleshy curves somewhere, but that is OT, and I don't operating theta. The PMD-100 would need glue logic either HW or SW to interleave it's output, but the PMD-200 appears to have an interleaved output mode available when in SW mode, and could interface 24/176 or 24/192 directly to the Sabre in it's current incarnation.

What may be a slightly larger piece of the market share is high end dual mono. Maybe that would carry some weight with the friendly suits across the aisle in Sales and Marketing.

Regardless, when you bump a rev on the chip to add input auto select in standalone mode, would you consider also adding a mono input mode to the mix...? I know that may be a bit much, as it not likely that could be done metal mask only, but the suggestion had to be placed.

Cheers,

WMS