I do want to know the exact meaning of "the best default".
I guess that everyone knows the use of "the best default" and wants the use of "the lowest" moreover.
A certain source in Japan told me that the best default was simply equivalent to "medium-low". I do not interpret my findings like this. I believe that "the best default" is apparently different from the "medium-low".
I guess that everyone knows the use of "the best default" and wants the use of "the lowest" moreover.
A certain source in Japan told me that the best default was simply equivalent to "medium-low". I do not interpret my findings like this. I believe that "the best default" is apparently different from the "medium-low".
You could simply set up the registers depending on what you want:
(Results of testing with my implementation of the Sabre32 and in my setup)
1. The Best fidelity and forget about DPLL.
2. Varying fidelity and adjusting the DPLL accordingly.
3. The Best fidelity and the ability to use all settings including "no" bandwidth.
As I could not find any audible difference that I could quantify between 1 and 3, and due to choice 3 was the last tested I have now used choice 3 with the bandwidth set to 000 "no" bandwidth.
I will change this to "the best default" today and leave it there as I do not expect any audible differences.
None of my findings are automatically valid for any other Sabre32 based DAC´s due to there are only one common factor - the ES9018 chip.
Due to I have included a optional Buffalo II input mapping in my control code I have now tested some functions in Buffalo II mode and have verified that my current code will not work on / with a Buffalo II without implementation of alternate conditional code for some functions to work with Buffalo II.
The alternate code are needed to support the different physical internal setup of the Sabre32 and thus different physical use / performance of the Sabre32 internal hardware...
Apart from the code the differences from a Buffalo II are:
1. Different physical connections of the Sabre32.
2. Different hardware between the Sabre32 and I2S / SPDIF inputs.
3. Very different power supplies and regulators.
The JFET regulators may have 40dB (or more) less noise.
4. Different clock and thus jitter and speeds - 98.304MHz vs 80MHz etc..
5. Completely different analog output hardware and topology.
6. Several out-of-spec issues that alters the performance of the Sabre32.
I will soon visit the owner of Norway´s most tweaked and "high-end" Buffalo II DAC with all possible tweaks with regard to power supplies - IVY etc.. etc.. for a comparison...
That is quite a claim....
At least the owner believes that to be true....
BUFFALO II
That was his initial build and later there have been upgrades - the latest was the Trident regulators...
I have no problem with moderating "most tweaked" to "possibly most tweaked" or "heavily tweaked" and the original statement referred to Norway only
Do you mean you still get sound with 000? I get no sound at all with that setting.
you guys must be a little hard up there for modders of the buff, looks to me to be a reasonably well realized, but totally 100% stock buffalo II and IVY in the pics, even all the transformers are stock and the IVY appears to be all kit parts too.
nothing wrong with that, but thats a big claim (although I dont know how many owners there are in Norway) there would have to be some serious changes to everything to match up with many I have seen
My understanding for RayCtech's explanation is like this;
x128 BW Notation Number implicated
0___000 No________0
0___001 Lowest___1 <- We want this!
0___010 Low_______2
0___011 Med-Low___4
0___100 Medium____8
0___101 Med-High_16
0___110 High_____32
0___111 Highest__64
1___000 ________128<- RayCtech obtained?
1___001 ________256
1___010 ________512
1___011 _______1024
1___100 _______2048
1___101 _______4096
1___110 _______8192
1___111 _____ 16384
Bunpei, this (your scheme) originated from my reply to "glt" regarding how to get sound with the "000" setting? My reply to "glt" have nothing to do with what is / can be obtained or anything else.
Oh, your 'the second option to "1" ' does not mean "x128". Is it confidential?
Bunpei,
as I was able to use the 001 lowest setting before I completely re-wrote the control code I will when time permits add a register screen dump to the old code to verify the actual register values that was effective with this setting.
The bw_128x was not involved as it is only in the new code I have added the possibility to change that setting for test purposes...
The results of the register dumps will be interesting as I still do not have any 100% proof to why I did not have any UNLOCK issues.
as I was able to use the 001 lowest setting before I completely re-wrote the control code I will when time permits add a register screen dump to the old code to verify the actual register values that was effective with this setting.
The bw_128x was not involved as it is only in the new code I have added the possibility to change that setting for test purposes...
The results of the register dumps will be interesting as I still do not have any 100% proof to why I did not have any UNLOCK issues.
Do you mean that your code is "Write Only" to registers and lacks "Read" for verification after those write operations?
Bunpei and glt,
I used to get "glitches" in the audio output when switching on or off as an example a lamp.
Have you or others related those mains noise spikes/pulses to the UNLOCK issue?
I did not check what the noise spikes/pulses triggered in the Sabre32 due to the cause was identified as mains noise spikes/pulses and I intended to cure the cause...
After I implemented the JFET regulators the problem with "glitches" due to mains noise spikes/pulses was improved.
And after a redesign of both the JFET regulators topology, removal of my shunt regulators and some outof spec tweaking of the Sabre32 I managed to get rid of the "glitches" in the audio due to mains noise spikes/pulses.
Now in conjunction with the testing of the new code the mains voltages have been 5 - 10% lower due to the cold weather here and the overhead in the main regulator are marginal due to I implemented a triple level regulation.
I will first off all increase the unregulated voltage and verify if this changes or not changes the DPLL UNLOCK issue..
I used to get "glitches" in the audio output when switching on or off as an example a lamp.
Have you or others related those mains noise spikes/pulses to the UNLOCK issue?
I did not check what the noise spikes/pulses triggered in the Sabre32 due to the cause was identified as mains noise spikes/pulses and I intended to cure the cause...
After I implemented the JFET regulators the problem with "glitches" due to mains noise spikes/pulses was improved.
And after a redesign of both the JFET regulators topology, removal of my shunt regulators and some outof spec tweaking of the Sabre32 I managed to get rid of the "glitches" in the audio due to mains noise spikes/pulses.
Now in conjunction with the testing of the new code the mains voltages have been 5 - 10% lower due to the cold weather here and the overhead in the main regulator are marginal due to I implemented a triple level regulation.
I will first off all increase the unregulated voltage and verify if this changes or not changes the DPLL UNLOCK issue..
Bunpei, if you can't trust writing to the register, then you can't trust reading from it either
Joking aside, I've never felt the need to read back the contents of a register (granted, I only have experience with WM8741 and Sabre32)
No, have never encountered a "lock" issue with power glitches. But I have a Monster Cable Power Conditioner in front (I know, "Monster Cable", but it was cheap
)That was partially the fact for the old code and the reason to both the complete re-write and the reason I will add the dump utility to the old code to 100% verify what settings that was in action - not only registers written to but also to verify if the Sabre32 changes any other registers as a result and also to verify if the default values was/are as documented.
Good idea. That is a good reason to read back the registers. If you are using Arduino, you can just write some test code and dump all the registers right after power-on to your PC screen...
I think I will do that to compare with the datasheet