I am very familiar with the issue, and it ultimately caused me to sell my Pontus II. I now use an admittedly much more expensive Aqua La Scala DAC, but would likely have continued with the Pontus were it not for that issue and the way that it has been handled by Denafrips.
This has now been a known issue for at least a couple of years, and no, as far as I know, there is no software/firmware fix. So I believe that the company made a calculated decision to engage in damage control, rather than offering a hardware fix, which would have been expensive, assuming that they have the knowledge to execute such a fix.
There was also what I consider to be an effort to obfuscate, or deflect blame, by floating the suggestion that it was only happening with certain transports. I had the issue with a Moon 260DT, which is a high-class machine, and in any case, the Pontus is responsible for the problem, as it should obviously work smoothly with all transports.
|
Alvin at Vinshine has mentioned a firmware update in one of his most recent videos.
As suggested above in my initial post, I do not believe that any firmware fix has resolved the problem. It may be possible that it has helped in some cases, but I am certain that if the problem had been fully resolved, Denafrips would be shouting it from the rooftops!
Given the length of time that this has been a known issue, I really do not understand how anyone could be optimistic that it might be fully resolved by other than a hardware fix.
|
@designsfx
Alvin originally told me that the issue was "likely caused by the FIFO buffer overrun".
The first attempted firmware fix was released almost one year ago.
|
@designsfx
Thanks. I have mentioned this a number of times previously, but Alvin, Denafrips' representative in Singapore, was always very communicative and helpful. However, the company itself has, in my view, handled this situation poorly, and the likelihood of a firmware solution at this late stage seems extremely small.
I was also a bit put off by the company's choice to continue to represent at least some of their DAC models as having NOS capability, when it was, and possibly still is not the case.
To be fair, I was broadly happy with the sound and build-quality of the Pontus, but with so many other interesting options in the market, I was happy to take a small loss on re-sale, and move along.
The La Scala sounds superb, though I recognize that some would find it to be lacking in features that are found in some other DACs. They are expensive, but I am confident that in terms of both build and SQ, I would not be likely to find anything much better, and probably at any price.
The other reason that I went with Aqua is that their elegant modular design would allow for fairly simple upgrades in the future, should I be tempted.
|
A couple of related notes. While it is possible that the problem has finally been resolved, it was never apparent in the experience of all users, only (I would estimate) a relatively small percentage. So the fact that some users of the newest version have yet to encounter any problem, while encouraging, is far from being definitive.
Secondly, as I have mentioned previously, it would be odd for Denafrips to have found a (likely hardware) fix for the issue, yet make no mention of the fact if it was installed in this new version. Why would they not proudly – and loudly – announce a successful resolution?
The only reason that I can think of would be because it would alert unaware customers to the fact that the previous generations were vulnerable to the problem, and Denafrips does not want to engage in any expensive recall action.
One other interesting note. As I have also mentioned previously, Denafrips chose to basically ignore the fact that they advertised at least some of their previous DACs as having NOS capability, when that was false. Much like the skipping issue, I believe that the company ran an internal cost benefit analysis, and decided to gamble that most owners would either remain ignorant of the false advertising, or would not care much, as any sound differences were likely very small.
I mention the above because this appears in the marketing for the Pontus 12th:
Pontus II 12th is a true NOS DAC.
Now, that is obviously good news for those who have purchased, or will in the future purchase one of these units. But I would argue that it also confirms precisely what I have described, namely that the previous versions were not "true" NOS capable.
That the company was willing to falsely advertise at least some of its products, even after they were publicly exposed as not being NOS capable, is in my view very damning, and that behavior would give me pause in purchasing products from Denafrips in the future.
|
I have been playing my Pontus II with the new FPGA firmware update for about a week now and I can confirm that the random pops/ticks I was experiencing are now absent. This mirrors my experience with upgrading the firmware on my Ares II. So it seems the issue was in fact software based.
I am skeptical of that conclusion, as if it were true, there is no reason that the problem could not have been fully resolved. Instead, we get this:
- Reduced the effect of Buffer overrun/underrun due to the Source’s Clock and the DAC’s Clock differences
"Reduced", not eliminated. What this suggests, and I would say clearly, is that it is in fact a hardware problem, which they are attempting to mitigate with a software patch.
Perhaps the approach will prove effective in reducing the audible artifacts to a very low level. But as I have pointed out numerous times previously, there is no reason that such a problem should exist in a relatively expensive, otherwise high-quality DAC. In other words, it is either a design flaw, or corners were cut on the related hardware.
|
@atp001
I’m no engineer, but again, everything about this saga thus far suggests that it was/is fundamentally a hardware problem, and that it has yet to be fully resolved.
Again, Denfrips said recently that the firmware:
- Reduced the effect of Buffer overrun/underrun due to the Source’s Clock and the DAC’s Clock differences
which is a not so tacit admission that it is a hardware problem, as further underscored by the Cisco definition.
Given that, at least to my knowledge, this problem does not occur in the vast majority, if not all DACs produced by other high-end manufacturers, the obvious implication is that there is a hardware/clock problem with the Denefrips design that is simply not found elsewhere.
Put another way, if every other manufacturer of high-end DACs can say with confidence that such buffer overruns are not an issue, while Denfrips remains unable to do so, is it credible to argue that they alone are unable to develop good enough, associated software?
|
@atp001
With respect to the topic of this post and the issue I personally experienced, the firmware appears to have corrected the problem. Thus logically, it was a software related issue.
Has it done so for every user that experienced issues, and irrespective of the source? That's a rhetorical question, as obviously no one knows the answer to that question. So no, I do not agree that it is logical to extrapolate from your single, anecdotal experience, that it was therefore a software issue.
Even if the software patch were to prove 100% effective in eliminating the problem, it doesn't mean that there isn't an underlying hardware problem. And again, if it was a pure software issue, how could it possibly have taken so long to resolve, and why would Denefrips still be hedging (i.e. "reduced")?
I would argue that the available evidence continues to strongly suggest that it is a hardware issue, and that efforts have been made to mitigate the problem through a much less expensive approach than a recall and hardware fix.
As for issues relating to the quality of the sound produced by Denfarips DACs, I have made no disparaging comments beyond the narrow topic that we are discussing.
|
In September of 2021, Alvin told me that the problem was "likely caused by the FIFO buffer overrun".
Here is an explanation of an overrun from the Cisco website support pages (bold emphasis mine):
Q. What are overruns on a serial interface?
A. Overruns appear in the output of the show interface Serial 0 command when the serial receiver hardware is unable to hand received data to a hardware buffer because the input rate exceeds the receiver’s ability to handle the data.
This occurs due to a limitation of the hardware. Overruns occur when the internal First In, First Out (FIFO) buffer of the chip is full, but is still tries to handle incoming traffic. The serial controller chip has limited internal FIFO.
Some chips, for example, have only 256 bytes of buffer space. Data from the network is received into the buffer, whereupon the chip attempts to move the data from the buffer to the router’s shared memory for the CPU to process. If the chip is not able to move the data from its internal FIFO buffer into shared memory faster than the rate at which data is received on the interface, then the internal FIFO buffer is full, incoming data is dropped, and the overrun counter is incremented.
|
Thanks @jaytor – I appreciate your technical insights. I tend to believe that it was likely a (Denafrips) clock issue, but whatever the exact cause, I hope that the latest firmware has resolved the issue for owners of the affected DACs.
|
@whipsaw - You can call it a hardware problem if you want, but IMO, it was (is) a rational approach to solving the problem of jitter reduction of source-clocked digital data.
@jaytor If it was not a hardware problem, then how would you explain why other manufacturers of higher-end DACs have not encountered such problems? Jitter reduction is essentially a "settled issue", even in much less expensive DACs.
My understanding, though I could be wrong, is that the issue was not reported by users of the Terminator DACs. If that was the case, and it was a software issue, then why would it not have been a simple matter to resolve?
Finally, as you have a technical background, does this Cisco explanation of FIFO overruns not apply here? And if not, can you explain why?
Overruns appear in the output of the show interface Serial 0 command when the serial receiver hardware is unable to hand received data to a hardware buffer because the input rate exceeds the receiver's ability to handle the data.
This occurs due to a limitation of the hardware. Overruns occur when the internal First In, First Out (FIFO) buffer of the chip is full, but is still tries to handle incoming traffic. The serial controller chip has limited internal FIFO.
|
