Well yes in a way. What it show is that the I2S input method is more susceptible to DPLL unlocking because of the way it clocks in data. There is no *real* bitclock for SPDIF.
SPDIF is less impacted so because of the way it is marked.
Also the SPDIF line is much more immune to all types of outside or GND loop/bounce noise because of the type of terminated transmission line it is.
If I may continue the dialog...
From a pure technical perspective I would think that with respect the jitter, SPDIF=I2S because the are all derived from a single clock. (even though it is almost universally believed that I2S is better than spdif) (and because of that belief, I always want to tap the I2S lines
)
The sabre white paper says that both spdif and I2S present the data to the DSP is the same exact manner:
"The I2S and DSD are clocked data streams, they do not
require the method used by the SPDIF interface, but they
result in the same thing: similar to the output of the SPDIF
decoder, at a certain asynchronous time, they present to the
downstream processor the new bit or word from the interface."
The white paper also says that there is no clock recovery in the spdif and therefore there is no reclocking of the spdif signal. So whatever jitter is in the spdif lines is passed with the time stamps to the DSP
I don't think termination matters and other noise sources especially in my case as both I2S and SPDIF wires are the same length, are TTL level and feed the same pin D1.
We also know that DPLL will loose lock in the presence of jitter, and increasing bandwidth will pass more jitter downstream.
All of this leads one to believe that:
Either there is something in the ESS DAC that cleans the spdif signal (and they don't tell us about) or I2S has more jitter which is very hard to believe/understand.
From a pure technical perspective I would think that with respect the jitter, SPDIF=I2S because the are all derived from a single clock. (even though it is almost universally believed that I2S is better than spdif) (and because of that belief, I always want to tap the I2S lines
)The sabre white paper says that both spdif and I2S present the data to the DSP is the same exact manner:
"The I2S and DSD are clocked data streams, they do not
require the method used by the SPDIF interface, but they
result in the same thing: similar to the output of the SPDIF
decoder, at a certain asynchronous time, they present to the
downstream processor the new bit or word from the interface."
The white paper also says that there is no clock recovery in the spdif and therefore there is no reclocking of the spdif signal. So whatever jitter is in the spdif lines is passed with the time stamps to the DSP
I don't think termination matters and other noise sources especially in my case as both I2S and SPDIF wires are the same length, are TTL level and feed the same pin D1.
We also know that DPLL will loose lock in the presence of jitter, and increasing bandwidth will pass more jitter downstream.
All of this leads one to believe that:
Either there is something in the ESS DAC that cleans the spdif signal (and they don't tell us about) or I2S has more jitter which is very hard to believe/understand.
You have to think of the purpose of the protocol. Better for what? And Why?
For data? For clock recovery?
SPDIF is only evil if you a depending on it to carry a clock. When you don't it really is no worse then any PCM method except that it is limited to 24bits.
You have a couple of assumptions there that I can say for certain are incorrect.
Still a lot of this is too deep to really cover well here and I suggest instead you ask ESS if you require specific information from them, or a good book on transmission lines regarding termination,loops, and noise.
I would be the first to admit that I suspect ESS may be doing something under the covers we don't know. Who knows maybe they alter the actual DPLL window slightly when SPDIF is detected. I really have no way of knowing.
The bottom line is, if your going to use I2S you probably want to adjust the window a bit.
I am testing some new firmware to do that automatically.Russ,
Appreciate the dialog. And Merry Christmas!
I am not that serious to be calling ESS. Besides, the first question they'll ask me is "who are you?". If they give free samples like the others, I'd probably call
Still, the only reason I pursue I2S is the almost universal belief that it is better than spdif, In the case of the Sabre DAC which does not do use the clock info, then it should be at least equal to spdif.
In any case, with respect to Buffalo, lowest DPLL is probably the best way to choose your interface because it passes less jitter downstream.
BTW,
I just did another experiment with the Musiland:
The device has two ways to generate the sample rate: "precise" which requires tandem use of the two DCMs and "fast" requiring just one of the two DMCs (fast is off from the ideal frequency but still within spdif spec).
Based on the jitter specification for the Spartan FPGA one would think tandem use of the two clock managers will create more jitter as they add jitter on the incoming clock, yet with "fast" (only one DCM) I need the increase the bandwidth of the DPLL further.... So the DPLL seem to be more sensitive to the actual rate than the jitter... Hmmm...
Appreciate the dialog. And Merry Christmas!
I am not that serious to be calling ESS. Besides, the first question they'll ask me is "who are you?"
. If they give free samples like the others, I'd probably call Still, the only reason I pursue I2S is the almost universal belief that it is better than spdif, In the case of the Sabre DAC which does not do use the clock info, then it should be at least equal to spdif.
In any case, with respect to Buffalo, lowest DPLL is probably the best way to choose your interface because it passes less jitter downstream.
BTW,
I just did another experiment with the Musiland:
The device has two ways to generate the sample rate: "precise" which requires tandem use of the two DCMs and "fast" requiring just one of the two DMCs (fast is off from the ideal frequency but still within spdif spec).
Based on the jitter specification for the Spartan FPGA one would think tandem use of the two clock managers will create more jitter as they add jitter on the incoming clock, yet with "fast" (only one DCM) I need the increase the bandwidth of the DPLL further.... So the DPLL seem to be more sensitive to the actual rate than the jitter... Hmmm...
Last edited:
And a very Merry Christmas to you as well.
It is a good dialog. I am just saying I don't really have all the answers.
I think my next firmware approach will be to always try to lock at the the lowest DPLL and if the DAC reports a lock errors then to ease it until it does not.
You could also give this a shot. It would be pretty fun.
Cheers!
Russ
It is a good dialog. I am just saying I don't really have all the answers.
I think my next firmware approach will be to always try to lock at the the lowest DPLL and if the DAC reports a lock errors then to ease it until it does not.
You could also give this a shot. It would be pretty fun.
Cheers!
Russ
And a very Merry Christmas to you as well.
It is a good dialog. I am just saying I don't really have all the answers.
I think my next firmware approach will be to always try to lock at the the lowest DPLL and if the DAC reports a lock errors then to ease it until it does not.
You could also give this a shot. It would be pretty fun.
Cheers!
Russ
Hmmm, I think that would be a bit tricky. The lock errors get sparser as the bandwidth is increased; you'd have to decide on some time threshold. Me? I have knob
Dear Russ, I'm one of those waiting a Buffalo board from first batch expedition scheduled the 2nd Jan 2011. I’ve red about a new firmware that will correct drop out using I2S connection from USB interface. Since I’d like to meet my Teralink X2 USB with the Buffalo via I2S, I’d like to know if the latest Buffalo board we will receive will sport this new feature.
Thanks a lot
Regards
Gianluca
Thanks a lot
Regards
Gianluca
Thanks to input wiring info that Russ provided and the datasheet I realized that my register definition for the input sources was wrong. I shall do some experiments and report back on the locking problem.
The input wiring of the Buffalo does not work with the reg14 default settings. It is somewhat "peculiar" but as Russ pointed out in the other thread, the input wiring was chosen to automatically support spdif, i2s and dsd without any hw or sw changes.
If I may suggest a future enhancement, pin 4,7 or 8 can be wired to separate pins to allow some muxing capability with s/w control. switching between DSD and SPDIF comes to mind...
The input wiring of the Buffalo does not work with the reg14 default settings. It is somewhat "peculiar" but as Russ pointed out in the other thread, the input wiring was chosen to automatically support spdif, i2s and dsd without any hw or sw changes.
If I may suggest a future enhancement, pin 4,7 or 8 can be wired to separate pins to allow some muxing capability with s/w control. switching between DSD and SPDIF comes to mind...
We actually thought about that very early on. But it was decided that we would limit the input options of the Buffalo to simplify wiring and firmware(and the number of switches people my need to set etc). That is why we decided not to worry about on-board MUXing.
That said now that the datasheet is more widely available we are considering lots of new ideas. It does people no good to have a really flexible DAC board and no datasheet to use it.
We are listening.
Last edited:
...
That said now that the datasheet is more widely available we are considering lots of new ideas. It does people no good to have a really flexible DAC board and no datasheet to use it.
We are listening.
OK, with tridents you "throw away" >$20 worth of caps and regulators. Why not have a separate all shunt power board and a DAC board with more flexible I/Os or even a two chip board sharing one oscillator?
PS, I think I meant to say pin 3 instead of pin 4
That's all perspective.
Remember that that vast percentage of Bufallo II users don't use Trident. It is an add-on. The concept with Buffalo II is that it is a complete and ready to use DAC as it is with a lot of options still open to the user, such output stage and power supplies etc. That is what has made it so successful. Adding Tridents is sort of like getting custom paint for your car. What a shame to waste all that perfectly good paint at the factory!
Bufallo II was never intended for edge cases nor tweakers. It is really meant for delivering superb quality and value at a reasonable price while giving the average builder a great chance at success.
About two DACs on one board, sharing master clocks is not generally a good idea, because of input capacitance and long routes. Also it really limits flexibility because most really only need one. If you really want two you can just use two DACs.
As for supplies and such, keep your eyes open on that front. We have some interesting things in the works. I think Buffalo users are going to be really excited. At least I am.
Cheers!
Russ
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.