• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Buffalo II

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
It has the ability to generate a clock yes, but it is *only* that generated clock that is ill and in the case of the ESS DAC it is not used at all. In any way. :)

SPDIF does not even really "have a clock", but you can derive a clock from it. That is the heart of the issue where standard receivers are used.

No clock extraction (which usually requires some type of PLL) is done at all in the case of ESS method.

The data is just data which is queued, and gets stuffed into a buffer. Much the same way that asynchronous USB works.

SPDIF once you are not running through a PLL to obtain a clock is just like any other 1 wire protocol.


Seems like you are taking ESS's marketing literally about their little trick for S/PDIF. Now matter what they call it, or how they do it, it's still a reclocking scheme. Bottom line is the data still has to be lined up and converted by the DAC at exact timing intervals to prevent jitter. And since S/PDIF data flow can't be controlled, the clock has to be adjusted to prevent overflow or underrun of the data. This creates more jitter.
 
Well...

No matter how "immune" the ESS 9018 is to incoming jitter, it is clearly not entirely immune. Any change I make to a transport, or SPDIF cable is clearly audible in the output of my B-II. Just like it always has been with any DAC of my experience, notwithstanding all claims of "jitter immunity" made by many manufacturers.
It seems the more resolving the DAC/System, the more clear it becomes to me that jitter is audible, even at very, very low levels.
 
It has the ability to generate a clock yes, but it is *only* that generated clock that is ill and in the case of the ESS DAC it is not used at all. In any way. :)

SPDIF does not even really "have a clock", but you can derive a clock from it. That is the heart of the issue where standard receivers are used.

No clock extraction (which usually requires some type of PLL) is done at all in the case of ESS method.

The data is just data which is queued, and gets stuffed into a buffer. Much the same way that asynchronous USB works.

SPDIF once you are not running through a PLL to obtain a clock is just like any other 1 wire protocol.
And how can it differentiate zeros from ones without knowing the pattern that separates bits (clock)? Before storing it on the buffer, it needs to know exactly each zero and one in the exact order for storing it, until the DAC needs that data.
How does it manage to do that?



Then the noise is likely not from your wiring. More likely from the source.

The DPLL is really finicky about phase noise. You can widen the DPLL window but then you are passing in some of that phase noise down stream.
Will the TPA Transport be a good solution noise-wise? I am sure you guys are developing a quite state of the art device, so keep it going!

Regards,
Regi
 
Regi...

Russ has made some very confident sounding statements about the forthcoming USB interface board. I trust that he is working very hard to make this interface a state of the art solution, with very little compromise in its design.
I am very much looking forward to trying the new interface when it is available, as I expect it will raise the performance of the B-II up another notch. (and I am already experiencing great computer audio perfromance with my B-II, via a Wavelink USB-SPDIF converter).
 
I think its wrong to assume that any perceived differences you might hear between sources are all about jitter. That is really rejecting quite a lot else that could be going on. You need to consider much more here. There are a lot of places that things can be mucked up or enhanced depending on your tastes that have nothing at all to do with jitter.

And please don't mistake what I am saying for something its not. I never said any DAC was completely immune to any particular effect. :cool:
 
Last edited:
And how can it differentiate zeros from ones without knowing the pattern that separates bits (clock)? Before storing it on the buffer, it needs to know exactly each zero and one in the exact order for storing it, until the DAC needs that data.
How does it manage to do that? i

I will give you 2 clues.

1) Bi-phase marking make differentiating 0's and 1's easy without any "bit clock".
2) Search for some comments by Dustin on this forum. He actually did a great bit of explaining how its done.
 
Last edited:
This can be deduced with common sense. With Async USB or Firewire the DAC can stop the dataflow. With S/PDIF you can't. So whether you strip the clock out of the data or not, the data keeps coming at the speed of the S/PDIF clock and this is why S/PDIF will always have more jitter.

From what I've heard, as good as the ESS DAC may be, even Dustin Forman, the Sabre DAC designer, believes this.
 
Yeah...

I think its wrong to assume that any perceived differences you might hear between sources are all about jitter. That is really rejecting quite a lot else that could be going on. You need to consider much more here. There are a lot of places that things can be mucked up or enhanced depending on your tastes that have nothing at all to do with jitter.

And please don't mistake what I am saying for something its not. I never said any DAC was completely immune to any particular effect. :cool:

I sort of know what you are saying, but, it is hard to really understand what else there might be affecting the sound when we have "bit perfect" data, and jitter: what else is there in the digital realm, this is what confuses me. Once we get into the DAC chip, and its oversampling/filters, etc, there are all kinds of effects to the sound, but just in data transfer, it is hard to understand what is going on beyond the bits and jitter.
I know you do not ascribe to the "jitter immune" rhetoric.
If you have a moment, I would love to hear some ideas from you as to what other factors might effect the sonics of data transfer to the DAC chip besides the bits and jitter. Are you thinking there are artifacts (unrelated to the data) in the digital signal that will be converted into noise/distortion products by the DAC?
 
I think there is no accounting for perception in its many wonderful and mysterious forms. :)

But lets talk about decoding for a minute. You don't have to control the SPDIF flow to accurately receive it and then quantify it. You are thinking far to linearly. :)

I have been playing with a very similar technique to receive SPDIF using XMOS. If you have a fast clock and a few samples worth of buffer, it is not a problem at all.
 
Really, I am not an ESS apologist, and I won't be put in that position. It is their baby I will let them extol its virtues. :D If you think they have something to prove you should take it up with them. :)

For my part I have some really good SPDIF sources, and some really bad ones that I test with.

The bad ones always sound bad and even require DPLL changes to work. Some of the good ones sound awesome on the ESS DAC but really not so great on a more conventional DAC. Why? Well because if you take the clock recovery out of the equation all that is left is good music. For many DACs this is not an option unless you ASRC. But it going to be hard to do ASRC as well as ESS has here. :)

To me the differences between I2S and SPDIF input are so minimal that there is no sense in arguing over them. The beautiful thing is, you have a choice!

Hmmm, and we have not even touched on DSD. Which I really like BTW.
 
I'm waiting for this guys! I hope Russ will develop Linux/ALSA drivers for such a device, this would be a great.

Pietro




Russ has made some very confident sounding statements about the forthcoming USB interface board. I trust that he is working very hard to make this interface a state of the art solution, with very little compromise in its design.
I am very much looking forward to trying the new interface when it is available, as I expect it will raise the performance of the B-II up another notch. (and I am already experiencing great computer audio perfromance with my B-II, via a Wavelink USB-SPDIF converter).
 
Hi Russ,

I was one of the lucky and fast one to buy the Buffalo in the last run. To be quick I just put the Buffalo modules in the order, but I would like to ask you if it is possible to add more items before the shipment.

Additionally, I am very interested in your development of the USB module. Do you have an idea of how big the module will be and if it will need a separate power supply, so I can leave enough space in the chassis.

Thanks,

Davide
 
No there is no VREF on the Buffalo II nor the ES9018. It is always referenced to AVCC.

If you use any resistor the DAC will not really be in current mode and performance will suffer. Yes even 5 ohms.

If you want you could create you own AVCC/2 voltage for you I/V stage. That is up to you.

You can also simply connect your resistor directly to GND there is no problem in doing this.

All of the inputs and outputs are clearly marked.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.