Denafrips Pontus II Clicks Or Static?

There have been some who have reported clicks or static occasionally with their Denafrips Pontus II DAC units.  And there is a test measurement review of the Pontus II 12th on the golden sound website talking about the following:

"When DACs oversample, they can sometimes encounter a situation where the reconstructed/interpolated waveform goes above 0dBfs (the maximum possible digital value)."

"The Pontus 2 is susceptible to intersample overs, and unfortunately, in a particularly bad way."

"The Pontus 2 does not clip, but instead when a sample value reaches above the maximum, it ‘wraps around’ to the minimum negative value, causing a huge sudden transient which will be very audible and may appear as crackling/popping."

Has anyone with a Pontus II encountered this anomaly when playing CDs?  If so, can you elaborate about that?  I am aware that the Pontus II can be firmware upgraded, so if this is an occasional issue, it could be eliminated with an upgrade.





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.

Now, regarding other aspects of the sound quality that you are speculating about, the Ares II and Pontus II have received almost unanimous acclaim for their sound quality.  If the new firmware improves (at least objectively) on that sound, then I'm happy for it.


I suppose I was lucky in that I communicated my issue with Vinshine just as they were preparing to announce the new firmware update.  So I got early access.  If the sound has improved in any other way, I have not noticed. 

@atp001 - how long did the upload/update take? People who have updated their Ares ii heard a big improvement in sound quality. Did you experience that with your Ares ii upgrade or was it similar to the Pontus upgrade and no major audible improvement? Thanks for taking the time to answer all my questions. 


I did get a sense that the sound improved on the Ares II with the new firmware (separation, imaging).  Was that due to expectation bias, I cannot say.  Unfortunately my sound memory is poor.


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.