This is a bit confusing now. as I understood the proposed solution would be to connect a switch to D1 to select between the I2s and the spdif, leave the onboard switch open. I guess like this I have to terminate the spdif offboard. The onboard spdif contact would be unused.
Did I get it?
Thanks for help!
D.
Did I get it?
Thanks for help!
D.
The data sheet is correct. 
Of course!
I have an update on my observations with uber-high sample rates and asynchronous operation.
I have spent my afternoon emailing Dustin and others as well as going back over old experiments including one of my first XMOS prototypes.
I can confirm that the datasheet is 100% correct as far as it goes – but should IMO possibly be updated with a note about high sample rates.
We know it is correct for one thing because 192Khz material works just fine with a 40Mhz clock.
You have to remember that the DAC was initially spec’d up to 192Khz. and 192fs master clock is the absolute *minimum* clock speed. As you get above 192Khz you are making the ASRC, OSF, DPLL, etc work within much tighter timing margins then at 192Khz.
What I found today is that I could sometimes make things work just fine with an 80Mhz clock, but definitely not always even though 80Mhz is well above 192fs. It is very definitely more finicky at 80Mhz and I would say not really usable for 352.8 Khz and higher.
Really, if your going to be doing 352.8 or 384Khz you really just need to give the DAC more error margin to work with to be safe.
I have in front of me a Buf II with 80Mhz clock. And it plays a loop of 352.8Khz material with no issues at all from an XMOS prototype board. This is with OSF on. But when I try another USB player at 352.8khz no dice. I really can’t explain why… But if I switch to another 100Mhz DAC all is well with both sources. So it seems to be somewhat hit or miss unless you give the DAC some room to adjust for errors.
So I am glad we went to the 100Mhz clock! And I would simply suggest that anyone really wanting to do the super high sample rates asynchronously do the same (well any master clock more than 256fs and within the specs). Keep in mind this has absolutely no bearing on 192Khz material and below. I was reminded once again that while a faster master clock can be more solid, it not necessarily “better” in terms of final analog performance. This is because the final analog part of the DAC is completely tied to the master clock, and it has a range of frequencies which are ideal. This is something which ESS tested. 100Mhz is well with the good side of things.
Dustin said that there needs to be *at least* a sample before the currently playing sample plus the sample after it in the "pipe" for the ASRC to work, this is why the minimum master clock is 3*64 = 192Fs. Now when I hear pipe I think buffer. He also said that more can be better! But once again because of minimum rise times you can only take the master clock up to a point. 100Mhz is a sweet spot we identified in earlier conversations but for slightly different reasons than we are talking about now.
Now about the OSF. There is a lot to clear up here…
The OSF in the Sabre32 is 8x FIR + 8x IIR for a total of 64x (This is why is needs 64Fs bitclock) so our math was a little out of whack. I am sorry for adding to the confusion for a while. The master clock in no way needs to be 8 * bit clock to do 8X oversampling (as the ES9018 does in fast roll-off) or even 4X (slow roll off). When you disable the OSF the FIR into the IIR is gone. The IIR remains.
So in the end, there is no good way for us to know exactly *why* yet, but I think it prudent to say it is indeed a fact that 80Mhz master clock is not high enough clock frequency for reliable operation at more than 352Khz asynchronously. I can say that I get absolutely rock solid performance with 100Mhz clock. My working theory is that this is all about the pipe (think buffer) into the ASRC.
So is the datasheet wrong? I would say no, it is not “wrong” at all, but it also could note that for very high sample rates the 192fs rule may not really apply very well. You should not live life near the absolute minimum (3 samples in the pipe). My gut feeling is that the extra sample “in the pipe” at 256+fs simply makes the ASRC work more consistently at uber high sample rates. Think of it as protection against under-run. ESS shared a lot of good info with me and I am sharing as much as I feel comfortable with and keep in mind I have to theorize where they (very understandably) won’t give me to full details. I am just trying to fill the gaps in my own understanding based on what I have learned.
I am sure Dustin is a busy guy and I don’t like to waste his time. I also really like their stuff and want use more of it.
That was a lot to digest… Thanks for bearing with me.
Cheers!
Russ
Of course!I have an update on my observations with uber-high sample rates and asynchronous operation.
I have spent my afternoon emailing Dustin and others as well as going back over old experiments including one of my first XMOS prototypes.
I can confirm that the datasheet is 100% correct as far as it goes – but should IMO possibly be updated with a note about high sample rates.
We know it is correct for one thing because 192Khz material works just fine with a 40Mhz clock.
You have to remember that the DAC was initially spec’d up to 192Khz. and 192fs master clock is the absolute *minimum* clock speed. As you get above 192Khz you are making the ASRC, OSF, DPLL, etc work within much tighter timing margins then at 192Khz.
What I found today is that I could sometimes make things work just fine with an 80Mhz clock, but definitely not always even though 80Mhz is well above 192fs. It is very definitely more finicky at 80Mhz and I would say not really usable for 352.8 Khz and higher.
Really, if your going to be doing 352.8 or 384Khz you really just need to give the DAC more error margin to work with to be safe.
I have in front of me a Buf II with 80Mhz clock. And it plays a loop of 352.8Khz material with no issues at all from an XMOS prototype board. This is with OSF on. But when I try another USB player at 352.8khz no dice. I really can’t explain why… But if I switch to another 100Mhz DAC all is well with both sources. So it seems to be somewhat hit or miss unless you give the DAC some room to adjust for errors.
So I am glad we went to the 100Mhz clock! And I would simply suggest that anyone really wanting to do the super high sample rates asynchronously do the same (well any master clock more than 256fs and within the specs). Keep in mind this has absolutely no bearing on 192Khz material and below. I was reminded once again that while a faster master clock can be more solid, it not necessarily “better” in terms of final analog performance. This is because the final analog part of the DAC is completely tied to the master clock, and it has a range of frequencies which are ideal. This is something which ESS tested. 100Mhz is well with the good side of things.
Dustin said that there needs to be *at least* a sample before the currently playing sample plus the sample after it in the "pipe" for the ASRC to work, this is why the minimum master clock is 3*64 = 192Fs. Now when I hear pipe I think buffer. He also said that more can be better! But once again because of minimum rise times you can only take the master clock up to a point. 100Mhz is a sweet spot we identified in earlier conversations but for slightly different reasons than we are talking about now.
Now about the OSF. There is a lot to clear up here…
The OSF in the Sabre32 is 8x FIR + 8x IIR for a total of 64x (This is why is needs 64Fs bitclock) so our math was a little out of whack. I am sorry for adding to the confusion for a while. The master clock in no way needs to be 8 * bit clock to do 8X oversampling (as the ES9018 does in fast roll-off) or even 4X (slow roll off). When you disable the OSF the FIR into the IIR is gone. The IIR remains.
So in the end, there is no good way for us to know exactly *why* yet, but I think it prudent to say it is indeed a fact that 80Mhz master clock is not high enough clock frequency for reliable operation at more than 352Khz asynchronously. I can say that I get absolutely rock solid performance with 100Mhz clock. My working theory is that this is all about the pipe (think buffer) into the ASRC.
So is the datasheet wrong? I would say no, it is not “wrong” at all, but it also could note that for very high sample rates the 192fs rule may not really apply very well. You should not live life near the absolute minimum (3 samples in the pipe). My gut feeling is that the extra sample “in the pipe” at 256+fs simply makes the ASRC work more consistently at uber high sample rates. Think of it as protection against under-run. ESS shared a lot of good info with me and I am sharing as much as I feel comfortable with and keep in mind I have to theorize where they (very understandably) won’t give me to full details. I am just trying to fill the gaps in my own understanding based on what I have learned.
I am sure Dustin is a busy guy and I don’t like to waste his time. I also really like their stuff and want use more of it.
That was a lot to digest… Thanks for bearing with me.
Cheers!
Russ
Last edited:
It should have none at all as long as the clock is truly in synch with the bit clock. What I mean is, that the master clock would need to be the master of both the source and the DAC.
I have been using a 256fs master clock with my XMOS experiments so far.
Based on my experiment of playing 2L DXD sources on AK4399, I'd like to say just one thing.
When we play a DXD file for the testing, we should select genuine 352.8 kHz/24 bit sources. 2L DXD sources are genuine. If you use upsampled sources, the continuous hiss noise may disappear even in an underclocked condition.
I think it's better for us to prepare a sweep sine test tone of DXD of which frequency ranging from 20 Hz to 176.4 kHz and to observe its output signal using an oscilloscope. If the OSF is running on any underclock condition, the output will collapse in the high frequency range.
I really hope that your product version performs as the prototype does. The model would provide us a kind of good reference of clean I2S output signals.
What about the dropout-problem? Any final insights/solutions?
What about the dropout-problem? Any final insights and solutions?
I searched the web as well as this thread, but there seems not to be a final answer. Like with many users, S/PDIF in my setup is carefully designed with a transformer for decoupling. Because the the complete Buffalo as well as the power supplies ar built into my CD player, there are no dropouts using the player itself as a source. With all other sources, DVD/DAT/Macbook, coax or optical, I get dropouts and they can be easily triggered by switching the lights in my apartment on and off. Again, all sources are decoupled with a transformer, also the CD-Player. Because the Player had originally no S/PDIF output, it feeds the Buffalo II via a DIT4192 transmitter, player and transmitter are synchronized with a Tentclock, so I assume, the player is the most stable source. As far as I remember, the Input of the BuffaloII is also buffered by default , so this setup should meet high standards.
I never had dropout-problems of any kind with my previous DAC, a Parasound 1500.
I think, I read somewhere that the unstable SPDIF-input of the Buffalo II is a design - flaw from the Sabre DAC-chip, can anyone confirm that?
Are there any workarounds? (Further buffering, working with 5Vttl-level etc.)
All the best,
Salar
What about the dropout-problem? Any final insights and solutions?
I searched the web as well as this thread, but there seems not to be a final answer. Like with many users, S/PDIF in my setup is carefully designed with a transformer for decoupling. Because the the complete Buffalo as well as the power supplies ar built into my CD player, there are no dropouts using the player itself as a source. With all other sources, DVD/DAT/Macbook, coax or optical, I get dropouts and they can be easily triggered by switching the lights in my apartment on and off. Again, all sources are decoupled with a transformer, also the CD-Player. Because the Player had originally no S/PDIF output, it feeds the Buffalo II via a DIT4192 transmitter, player and transmitter are synchronized with a Tentclock, so I assume, the player is the most stable source. As far as I remember, the Input of the BuffaloII is also buffered by default , so this setup should meet high standards.
I never had dropout-problems of any kind with my previous DAC, a Parasound 1500.
I think, I read somewhere that the unstable SPDIF-input of the Buffalo II is a design - flaw from the Sabre DAC-chip, can anyone confirm that?
Are there any workarounds? (Further buffering, working with 5Vttl-level etc.)
All the best,
Salar
Salar...
Sounds like a grounding problem inside your CDP in regards to the B-II.
I never had any problems with dropouts from the SPDIF input of the B-II using it as designed with the ground floating from the AC ground, but by attaching the DAC to an existing CDP, you may be connecting the DAC ground to the AC ground-just something to explore...
Sounds like a grounding problem inside your CDP in regards to the B-II.
I never had any problems with dropouts from the SPDIF input of the B-II using it as designed with the ground floating from the AC ground, but by attaching the DAC to an existing CDP, you may be connecting the DAC ground to the AC ground-just something to explore...
Hi Barrows,
no, the player´s connection works fine (btw, the players ground an the dac´s ground are completely seperated, isolated and also independently powered. Imagine them as two seperated units being mounted in one chassis, with an isolated subchassis for the dac and it´s power supplies)
I have the problem using the DAC the "usual way" with other sources. Some users experience the same problem as well. Switching a light on/off in your room can trigger a dropout.
All the best,
Salar
no, the player´s connection works fine (btw, the players ground an the dac´s ground are completely seperated, isolated and also independently powered. Imagine them as two seperated units being mounted in one chassis, with an isolated subchassis for the dac and it´s power supplies)
I have the problem using the DAC the "usual way" with other sources. Some users experience the same problem as well. Switching a light on/off in your room can trigger a dropout.
All the best,
Salar
Last edited:
Russ, could the upcoming S/PDIF 4:1 MUX/Receiver Module for BII be combined with a sidecar to switch between spdif and I2s input for BII, if sidecar is appropriately wired? Also could one wire a sidecar in a way that it will switch between 2 I2s inputs for BII?
Thanks!
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.