Although in the anouncement of this version I told "No changes in SQ to be expected", this now appears to be far from the truth ...
Thanks to your feedback it got me thinking what actually could be happening at those places where now Q1 can be slided further down than before (and that's how important your feedback is !);
To me it already occurred earlier that with the same DAC, the USB connection did not allow Q1 to be as far down as with the SPDIF connection. I never talked much about it, because it was beyond my comprehension why.
Today, similar to your experiences, I too now (since 0.9m-1) can use the USB connection with Q1 at -4. But why ?
As a sidenote, but possibily as important, I wondered how people could not go further down than, say, 12, with a "normally looking" connection, whereas others can go to -4.
Also, in all cases where the boundary is crossed, people report real distortion like corrupted data. With my USB connection no difference.
Now, at the ever so long looking for the culprit in "Engine #3 did not start ..." I found another "issue" in my software, which in combination with now obtained better knowledge of things because of all the debugging - leads me to think about something "wrong", or to anticipate on anyway :
I am fairly sure that a DACs buffer can be overrun with a few bytes without it complaining. This is difficult to explain, but is related to the communication of the DAC with the outer world, and her telling about her buffer being empty to a certain extend, which
implies to what extend the buffer can be refilled - hence data can be added;
Although I can't reason it out for 100%, it must be so that "conversion means" - one type opposed to the other - destroy the proper communication. Think of one particular sound sample causing the DAC to tell it reached a certain "buffer empty" state, that sample representing 0.000002 seconds, but the communication (by speed of light by itself) can be more or less direct because of less or more conversions (conversions : e.g. from USB to SPDIF, the other way around, etc.). Now, if
something isn't working 100% properly this can cause buffer underruns (meaning : the buffer really gets empty and then sound stops). Btw, in effect this works out as sound stopping for only "some" number of samples, because the process as a whole will refill the buffer anyway when this happens, but it is the speed of light and the induced latency (oh yeah) of the software making this duration more or less samples.
Where in the above the underrun principle was taken as the example to make things clear, there's also the overrun I talked about earlier;
When, say, one sample too many is given to the buffer, it will ... no, might be lost. And this is what I talked about in the beginning of this post;
Looking at the Fireface, there's an official "safety buffer". I always wondered why, because it should not be needed when everything works ok ...
As I learned now (well, as how I perceive this now), this is about the DAC telling to re-fill the buffer with a certain amount of samples, but when -because of whatever (time) reasons - this is not correct, the DAC could communicate a few samples too many (to fill the buffer), and with the Fireface those arrive in the safety buffer, the hardware (Fireface) being able to deal with that anyway. Now watch this :
The debugging told me that where the Fireface allows to set the buffer to "a" number of samples (like 48, 64, 96 etc.) this is really respected by the Fireface at telling for how much to refill the buffer. And I mean, exactly. Stupidly enough, my DAC is not the Fireface ... it is behind the Fireface, connected via SPDIF ... Thus, where XXHighEnd communicates with the Fireface (read : the soundcard), the Fireface takes care of the communication with the Audio DAC. Read : when XXHighEnd is told to give 48 samples, within that implied time (which is 1ms) the buffer in the Fireface to feed the real DAC should not get empty.
With this connection (Fireface -> SPDIF -> Audio DAC) it is out of any control whether that succeeds or not, and really nobody would know how good or bad it goes. It largely depends on the Audio DAC ...
But now use the USB connection, with this same DAC;
Now XXHighEnd directly communicates with the DAC, although now the "fuzzy" USB is in between. Where the Fireface has a Safety Buffer to overcome anomalies (for overrun) the Audio DAC might have not. Or it just has ...
The latter can be about
implementations of the DAC as a whole. Mind you, there's a DAC chip, and there's everything around it. The "around it" determines whether Q1 will give you anomalies at lower levels.
For those who are completely lost by now (not your fault) ... from the issue I found in the software, just creating the anomalies (soft cracking), compared with that now being solved and at least one user still reporting the anomalies, I can derive that those who still have the anomalies with 0.9m-1 must be dealing with something wrong around their PC->DAC communication. Generally (well, with my current knowledge of it) think of something being too slow to cope with the latency XXHighEnd can work with, hence that the latency of hardware products (like SPDIF->USB conversion) is higher than that of the software.
Lastly, note that before this day we always talked about "your system might be different for the workout of Q1" ... Today, I don't think this is true anymore. Today, too many people end up at the same Q1 level to be treated as coincidence. Now, if this is taken for being true, those who can't reach that level, hence have the best SQ at a higher level (but only incurred by otherwise loosing samples etc. !), must have something wrong(ish).
*If* this all is true, this is very convenient, because it means that I can concentrate on the single best sounding combination of settings, and they should workout the same for all of you.
Additionally I can tell that the Q1 = -4 is far, far from what the software is capable of, and at some stage the hardware response (latency) will come into play for everyone, that being different (for crossing boundaries) for everyone with different DACs, cables, etc.
Peter
Edit :
PS : Let me add that of course any comparison of software with hardware (like in chips) it moot. But do not forget : a DAC just runs on software too; though highly efficient, at some stage that might be less "fast" as the xxGHz processor from the PC ...
