Denafrips Pontus II Clicks Or Static?

I'm waiting for the file to apply the firmware to my Pontus II.

I have owned this DACs for over 3 weeks and have not experienced any pops or clicks while streaming music. I'm in-between owning a CD transport. However, like my Ares II (SOLD), I've experienced a split-second 'drop-out' or minute skip in the music. It's so small, that its over before you realize. Never in more than one place in a single song, and always at the beginning of a track. And lately, it hasn't occurred at all in a week of (75-100 hours) listening. I just hope this glitch goes away for all of Us. 

I have an Ares 2 and a Pontus 2.  The only time I’ve had static or popping sounds was with the Ares 2 connected to a Bluesound Node N130 via USB.  Using coax was fine.  I then swapped out the Node for an iFi Zen Stream via USB and never had a problem after that.  Using that same setup with Pontus 2 and never had an issue.

I updated the firmware on both DACs today and it was very easy. Used a MacBook Pro and had no issues.  The instructions were very clear and easy to follow.

Both DACs sound a little better to my ears after the update.  Was definitely worth doing.

@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. I'm sorry you experienced problems with your DAC.

With their implementation as I understand it (and I am a digital electronics engineer), there is no "definitive" fix if the source and DAC have significantly different clock frequencies. I suspect this new firmware either increases the amount of RAM allocated to the FIFO, changes the algorithm used to reset the FIFO pointers (e.g. between every song), or both. This won't fix all possible cases, but it will likely reduce the percentage of users that experience the problem from an already small number to near zero.

I don't know why Denafrips chose to wait as long as they did to issue a fix. It could be that other more significant changes were required to the firmware to allocate more RAM for the FIFO, or it could be that they just felt it was affecting so few users that they had other priorities. 

At any rate, hopefully this will fix the problem for the users that FIFO overflow/underflow was affecting. 

I'm quite happy with the sound from my T+, but I'm looking forward to being able to try out this new update. I've never experienced any skipping/glitching issues, but I have always used my T+ with a USB connection to my streamer (through a Gaia). 

@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.

@whipsaw - I am making some assumptions here on the exact implementation of Denafrips' designs, since they have never really published a detailed description.

As I understand it, the input data is clocked into the FIFO using the source device's clock (embedded in the SPDIF signal), and clocked out of the FIFO using the DAC's internal clock.

If the clocks are different enough in frequency, eventually the FIFO will overflow (if the source device's clock is faster) or underflow (if the source clock is slower). So, yes, CISCO's explanation is basically correct.

I'm not an expert on modern DAC implementation, but I believe that many DACs (particularly lower priced DACs) use a phase-locked loop to adjust the DAC's clock frequency to match the source clock. They may also use a FIFO so the PLL can be slow responding to minimize jitter. But a PLL will still not be as stable and jitter free as a fixed crystal oscillator (particularly an temperature controlled oscillator).

I suspect the reason that the problem was less common (or non-existent) with the Terminator and T+ is that the clock used in these DACs is higher quality (more accurate) than the clocks used in the lower priced models, and these DACs probably also tend to be used with higher quality sources (which have more accurate clocks). I have not heard that the FIFO implementation is any different, although it's possible that larger FIFOs were used. 

I also suspect that many higher end DACs use a similar approach to Denafrips and just did a better job with the FIFO management (perhaps using the same approach that Denafrips is now using).