ESS Sabre Reference DAC (8-channel)

OK, I think I might know what your reffering to about "wandering images" Is it the stereo "imagining" or the "sound stage"? If this is the case, then I would attack it like this.

Use the same clock for all 8 dacs, both bit clock and mclk. If you do that, then my buest guess is you would be fine. Of course, it would be up to a system level implementation to build and verify this.

Sounds like a fun project.

Dustin
 
dusfor99 said:
OK, I think I might know what your referring to about "wandering images" Is it the stereo "imagining" or the "sound stage"? If this is the case, then I would attack it like this.

Use the same clock for all 8 dacs, both bit clock and mclk. If you do that, then my best guess is you would be fine. Of course, it would be up to a system level implementation to build and verify this.

Sounds like a fun project.

Dustin


One can easily make the 3 Buffalo all use a common master clock / bit clock. That is what I would do.

Cheers!
Riss
 
Bgt said:
Russ, is there also a possibility like the Opus to have 2 dacs and use 1 for the left channel out and the other for the right channel out.
Thanx, Bert


The SABRE chip right now does not support a mono mode for PCM and SPDIF directly. You would have to do some work to convert the stereo PCM/SPDIF to mono to use it like you would the Opus. For DSD input you can simply supply the same channel to both digital inputs on the Buffalo.

Cheers!
Russ
 
dusfor99 said:
OK, I think I might know what your reffering to about "wandering images" Is it the stereo "imagining" or the "sound stage"? If this is the case, then I would attack it like this.

Use the same clock for all 8 dacs, both bit clock and mclk. If you do that, then my buest guess is you would be fine. Of course, it would be up to a system level implementation to build and verify this.

Sounds like a fun project.

Dustin

Hi Dustin,

WRT 'images', correct I was referring to localisation of sound sources
within a 5.1 (or other) surround playback.

If we look at separate spdif feeds to 3 x stereo dacs then the data
related jitter for each stereo feed will be different. As such the
internal ASRC low pass filter of each separate dac will have a slightly
different workload. This may cause variance between the 3 x
separate (stereo) dac OP's phase relationship.

As you state above, having same bclk and mclk should solve it.

As Russ states, no problems doing this if the dacs are mounted in
same box but I was thinking of the case where using 3 x separate
stereo boxes.

Might be something to think about for the future, home theatre
is becoming a huge market. :up:

cheers

Terry
 
Hi Terry,

I do hope we can learn more about this possible effect. It would be good to know if we can eliminate it as an issue of concern.

In my case, I would just pipe the PCM in direct to the three DACs in one chassis. You could do this SDIF2 style with the PCM stream. You would only need 5 lines into the DAC. LRCK,BCK,D1,D2,D3. Those could be carried over properly terminated 75 ohm coax if driven at the source by a suitable driver. That's precisely what I am working on. :)

At the DACs you simply share the same (40 or 80mhz in my case) master clock for all three DACs. This can be done on the buffalo board by simply running piece of wire vertically through the stack of three DACS.

I don't think I would bother with conversion of the PCM to SPDIF especially if you can keep the coax lines reasonably short.

Cheers!
Russ
 
Honestly, I just never assuming people would want to buy 1 of these DAC per channel, I thought wiring 4 up was enough and that is really why it cannot do it (easily) Of course with the skill level of many on this site, you can basically do waht Russ is reffereing to and demux the data before presenting to the DAC. One other this to cinsider is that the Sabre has to Address select lines meaning a total of 4 can be put on the same I2C bus. Most likely though, you could parallel these on the same bus and if the clocks were all the same, I bet it would still work ok. I would be very interested to see someone use 8 of these to make some form of 7.1 super reciever or something. All sounds like big fun.

Keep in mind that these comments and requests are all being watched over and I appreciate the feedback.

Thanks

Dustin
 
dusfor99 said:
Honestly, I just never assuming people would want to buy 1 of these DAC per channel, I thought wiring 4 up was enough and that is really why it cannot do it (easily) Of course with the skill level of many on this site, you can basically do waht Russ is reffereing to and demux the data before presenting to the DAC. One other this to cinsider is that the Sabre has to Address select lines meaning a total of 4 can be put on the same I2C bus. Most likely though, you could parallel these on the same bus and if the clocks were all the same, I bet it would still work ok. I would be very interested to see someone use 8 of these to make some form of 7.1 super reciever or something. All sounds like big fun.

Keep in mind that these comments and requests are all being watched over and I appreciate the feedback.

Thanks

Dustin

Hi Dustin,

I have some questions and answers as a result of working with a product not intended for DIY and hope you send me an email.

Raymond
 
dusfor99 said:
Honestly, I just never assuming people would want to buy 1 of these DAC per channel.....

Keep in mind that these comments and requests are all being watched over and I appreciate the feedback.


Hi Dustin,

Are we saying that ESS potentially might use the technology in the DAC to build one that does mono with similar specs?

Some of peoples recent questions look like people are actually asking about Time Division Multiplexing of a 7.1 Home Cinema signal and how they can get the 8 digital mono audio channel data and run it into 8 of your DAC to get the best out of it (simply because there is no mono version of the Sabre DAC that could be used in something like this). Maybe I am mistaken on that, but it's what I read between the lines.

I like the purist/audiophile/audio-nut idea - that each digital mono signal is decoded by a dedicated mono DAC, or a differential topology - but then I am more audio nut than audio engineer. The more pragmatic me tells me it really isn't necessary with this DAC, because the extra cost of such a design would far outweigh any performance gain since such improvement is unlikely to be audible.

I think the people asking about mono might be thinking there is something to gain in the discrete mono approach. I am not so sure.
For one, the decoding paths are all shorter in a single chip, rather than using a physically large area for 8 channels to all be separately decoded by one or more mono DAC chips and associated components, increased points of failure in the design, a chip acts less like an aerial antenna than a large circuit board (usually).

One of the reasons people may be asking, is that I think the general skill level on this site is more from experience with stereo or mono PCM DACs like the PCM1794 and similar offerings from Wolfson and Crystal Semi. I think most of us lack the expertise with multichannel decoding and Time Division Multiplexing and how all these separate digital signals of a variety of digital audio formats (DTS, DD, DTS-Neo, etc) are these days combined with a video signal in HDMI and have HDCP thrown in on top, making the typical DIY audio person a bit out of their depth. Your DAC is aimed a multichannel which is the current and future trend, but so are HDMI signals (which we are locked into using for HD audio out of things like PS3, Bluray players, and upscaling DVD players) - although we all want to be able to strip the audio out of an HDMI input and process it to the same degree that some of us have achieved with PCM stereo signals - particularly when typical retail multichannel decoding is typically not as good (sonically) as high end hifi decoding of stereo replay. People like me look to getting audio performance of the highest calibre out of multichannel systems in an effort to not require a separate high-end stereo replay system. We all want one box under the TV/projector that does "the business" for home cinema, but also the very top end of stereo replay for all our CDs and SACDs. Unfortunately, XLR, RCA and Toslink are dead and no good for HD audio in the home of which HDMI is the new king. We must all learn how to interface with that and get what we want from it. I feel people are asking how to demux signals to get 8 discrete digital mono signals they can then work with as they did before in the stereo replay realm, and then hoping to use your/ESS DAC on each mono channel. I am not sure this is how any of us DIYers should be thinking.

Does this make sense?
 
I2S question

Hi Russ:

A few questions, if you don't mind.

I'm tapping I2S from a Juli@ sound card and have 4 lines (data, bit clock, word clock, master clock). I drive a Perpetual Technology P-3A DAC and this works fine.

Q - If I bought a Buffalo DAC, how would I use this synchronous master clock?

Your schematic seems to indicate only data, bit clock and word clock inputs. I suppose the crystal is the master, but it is asynchronous. Any comments

Also, I worked on the thread a while ago tapping spdif from the SMCWAA-G EZStream device, and I see that you did the same.

Q - Did you ever verify bit-perfect output from the SMCWAA-G ?

I know this is a tangential subject, sorry.
 
Re: I2S question

wackyterbacky said:
Hi Russ:

A few questions, if you don't mind.

I'm tapping I2S from a Juli@ sound card and have 4 lines (data, bit clock, word clock, master clock). I drive a Perpetual Technology P-3A DAC and this works fine.

Q1 - If I bought a Buffalo DAC, how would I use this synchronous master clock?

Q2 - Your schematic seems to indicate only data, bit clock and word clock inputs. I suppose the crystal is the master, but it is asynchronous. Any comments

Also, I worked on the thread a while ago tapping spdif from the SMCWAA-G EZStream device, and I see that you did the same.

Q3 - Did you ever verify bit-perfect output from the SMCWAA-G ?

I know this is a tangential subject, sorry.

Hi, no worries. :)

Q1: If you want the benefits of the jitter reduction of the Sabre then you need to just omit your master clock from the sound card. Otherwise you disable the XO (pin 1 to gnd) and use the two pads (GND and MCK) on the chip side of the XO.

Q2: There are two pads next to the XO for using an external master clock if you like.

Q3: Well, I know it does not upsample. All I tested was that 44.1khz in = 44.khz out. At some point I may do further testing on it.

Cheers!
Russ
 
dusfor99 said:
Honestly, I just never assuming people would want to buy 1 of these DAC per channel, I thought wiring 4 up was enough and that is really why it cannot do it (easily) Of course with the skill level of many on this site, you can basically do waht Russ is reffereing to and demux the data before presenting to the DAC. One other this to cinsider is that the Sabre has to Address select lines meaning a total of 4 can be put on the same I2C bus. Most likely though, you could parallel these on the same bus and if the clocks were all the same, I bet it would still work ok. I would be very interested to see someone use 8 of these to make some form of 7.1 super reciever or something. All sounds like big fun.

Keep in mind that these comments and requests are all being watched over and I appreciate the feedback.

Thanks

Dustin

Hi Dustin,

I have some questions and answers as a result of working with a product not intended for DIY and hope you send me an email.

Raymond
 
Re: Dual mono anyone?

Russ White said:
OK, if anyone really wants to try it, searching the forum I found this circuit which should work if you really want to do a dual mono DAC. :)

http://www.diyaudio.com/forums/showthread.php?postid=1296575#post1296575

I have not tested it, but it looks interesting, and not too complex.

Cheers!
Russ



Hmm. I don't see how it works right.

Yes, it looks interesting but I'm not going to try it.

He is using 4x 8-bit shift registers to save the 32 bits of either the left or right. The shift register remembers the 32 bits of sample data and repeats it, so you get the same data for left and right in the data stream.

You would need a duplicate of the circuit for the other channel. OK so far. Now we are up to 8x of the 8-bit shift register chips.

But for I2S, the 32 bits of the right channel comes first and then 32 bits of the left. So the circuit for the doubled up right channel will be 32 bits ahead of the circuit for the doubled up left channel.

So, you would need another 32 bit shift register to delay the right channel and restore the proper timing. Now we are up to 12x of the 8-bit shift register chips.

Or am I missing something? that's always possible :D
 
Russ White said:
Actually apparently its been tested and works. :) I have no need of it, so I really don't care right now. :D

I have no plans to do a dual mono DAC either. I'm just concerned that someone would use two of these circuits and find out later that the left channel is delayed by 11.3 microseconds. (at 44.1K)

At first, it might sound like it works OK, but I think the delay would really mess up the soundstage. :D

I would want to look at a timing diagram of this before I designed it into a circuit board.

Actually, the circuit looks like it would work as posted if you just wanted to get mono of either one of the channels and discard the other channel.

I don't know why...
 
rossl said:
Actually, the circuit looks like it would work as posted if you just wanted to get mono of either one of the channels and discard the other channel.

I don't know why...

You would use one per channel. If your gonna do dual mono might as well go all the way right down to the demux. :)

Ok, so which is it? ;) You say you think it works or it won't. :) LOL, you've lost me. If you have a doubt ask the author for a timing diagram or an explanation. Its his circuit. :) I only linked to the interesting thread to show people that it is plausible.

Also on the same thread there are similar circuits. A few of them should work just fine.

:EDIT:BTW It seems others shared your doubts about the clock shift, but it seemed to become clear later in the thread.:EDIT:



Cheers!
Russ