There are two aspects to consider:
1) The player: It should when encoding DoP ensure that gapless stream is presented to the DoP decoder. This can easily be done by employing look-ahead and a FIFO.
2) The decoder (generally as USB interface etc): It should *never* allow unconverted DoP PCM frames to pass through. It should use a FIFO to analyze the frames and truncate and then refill the frames with silence until DSD samples are actually sent. When transitioning back to PCM the interface should pad the FIFO with silence samples prior to playing the actual stream.
Even better is just to avoid DoP altogether - there is simply no need for it.
1) The player: It should when encoding DoP ensure that gapless stream is presented to the DoP decoder. This can easily be done by employing look-ahead and a FIFO.
2) The decoder (generally as USB interface etc): It should *never* allow unconverted DoP PCM frames to pass through. It should use a FIFO to analyze the frames and truncate and then refill the frames with silence until DSD samples are actually sent. When transitioning back to PCM the interface should pad the FIFO with silence samples prior to playing the actual stream.
Even better is just to avoid DoP altogether - there is simply no need for it.
In my search for truth 🙂, I dropped a note to Andreas Koch of Playback Design because he is one of the main overseers of the DoP specification.
Here is his response:
"The issue you are describing is most likely not caused by the ESS chip, but rather by the implementation of DoP which is always outside of the DAC chip. It is something I am quite familiar with as I have implemented various DoP receivers for almost all the software players (Mac, Windows and Linux). They all generate substantial clicks when the output of the DAC is not muted properly.
The solution is always for the DoP implementation in the DAC to generate the proper mute signal to the DAC chip. I hear about this issue constantly and, honestly, I am a bit surprised at the lack of care by some of the designers and manufacturers."
So it looks like I need to bug Joro on this. Thanks for everyone's assistance in understanding the root problem.
Here is his response:
"The issue you are describing is most likely not caused by the ESS chip, but rather by the implementation of DoP which is always outside of the DAC chip. It is something I am quite familiar with as I have implemented various DoP receivers for almost all the software players (Mac, Windows and Linux). They all generate substantial clicks when the output of the DAC is not muted properly.
The solution is always for the DoP implementation in the DAC to generate the proper mute signal to the DAC chip. I hear about this issue constantly and, honestly, I am a bit surprised at the lack of care by some of the designers and manufacturers."
So it looks like I need to bug Joro on this. Thanks for everyone's assistance in understanding the root problem.
Muting the DAC between tracks etc is simply masking the the fact that you are sending it noise. 🙂 While that may work - it's really not ideal.
Hi, I just came along this thread.
I use jriver as an audio player, and it specifically has a setting to insert a silent passage after tracks to prevent these pops with DoP-playback.
So, maybe this would be a solution for some....
Regards,
Florian
I use jriver as an audio player, and it specifically has a setting to insert a silent passage after tracks to prevent these pops with DoP-playback.
So, maybe this would be a solution for some....
Regards,
Florian
- Status
- Not open for further replies.