Thread: H390 DSD/DoP *POP*

Short Version:

It appears that the DAC in my new H390 may not correctly implement preventative recommendations on page 2 of the DoP standard, resulting in an audible, and not inconsequential, "POP" sound when starting and stopping DSD64 and DSD128 playback. DSD256 playback is just fine. But the "pop" is not befitting an high end product.

Long Version:

I connected a new H390 to my Windows PC running JRiver Media Center 27. I am successfully running DSD over DOP (over USB). However, I have discovered an annoying anomaly. As you know, the H390 has a built in DAC and only accepts DSD (up to 4x) in DOP format.

When Playing DSD64 and DSD128 files, when I begin playing from a stopped condition in Media Center, there is an audible "pop" when play starts. When play is in progress, the H390 display correctly indicates that "DSD64" or "DSD128." When I pause (as opposed to "stop") and resume, there is no pop, and there is no interruption to the display correctly indicating the DSD rate. However, if I stop (as opposed to "pause") playback at Media Center, the display stops indicating "DSDxx" and instead indicates either "176.4kHz" or "352.8kHz," depending on the DSD rate that was playing before stopping playback. It is as if the H390 "forgot" that it was previously playing a DSD file and now "thinks" that playback is PCM. Or, put another way, under these conditions, the momentary misidentification by the H390 DAC of a DSD stream is audible.

In contrast, playback of DSD256 files seems to work flawlessly. There is no audible pop when beginning playback from a stopped condition, and when I stop playback, the display continues to display the correct DSDxx rate.

I have read the DoP standard, of which JRiver was one of the authors, so presumably, DoP is implemented correctly in JRiver Media Center. If I was to guess, the H390 DoP implementation is resulting in exactly the problem which the standard warns of on page 2, at least for DSD64 and DSD128 playback:

"The 8 most significant bits are used for the DSD marker and alternate with each sample between
0x05 and 0xFA. Each channel within a sample contains the same marker. This has been chosen
to minimize the click that might be experienced when the receiving hardware misinterpretes the
data as PCM when it really is DSD. If this should happen it would create a tone around 88kHz
and roughly -34db, nothing harmful and something that most D/A converters would suppress to
some degree before it even reaches the loudspeaker. It should be pointed out that hardware
manufacturers and software developers alike can easily use common safeguards to prevent such
cases of erroneous format switching and that they may only be limited to times during
development of hardware and software. It is their responsibility to prevent misinterpreted cases
and to test their products thoroughly before release. Misinterpretation of PCM data as DSD may
create less predictable clicks."

I notified Hegel of this issue, and they replied promptly. They suggested that I upgrade the firmware on the unit, which I did but made no difference. They also point out that I am the first to raise this issue, and they have sold several thousand H390's in almost 2 years. Also, they are forwarding this issue to their development team, but they warned that much of their facility is closed due to COVID-19 restrictions, so any possible resolution on their end is likely to take some time, longer then I can wait. They apologized. I am already into the 30-day window that my Hegel dealer offers for which I can return the item for a full refund. So, I have decided to take Hegel on their word, that a solution, IF they decide one is warranted, will take longer than 30 days. So, I'll probably just return the unit at my earliest convenience, and move on to the alternate product that I have already identified.

My Editorial:

This audible anomaly is unsatisfactory. I have not encountered this problem with any other DSD-ccapable DAC's, spanning from "entry-level" to what some may consider high end. But, they do not implement DoP and instead require an ASIO driver of one kind or another on the host Windows PC. This appears to be a much more reliable solution and indicates that there is technical and stability risk in adding the additional DoP protocol layer. Even if Hegel were to fix this issue, it remains a software/firmware element that could be subject to corruption in subsequent firmware releases, possibly with additional protracted periods of resolution. I am sure that most of you here have experienced, at one time or another, a software feature on whatever product that was functional and that a subsequent version release "broke." Existence of this added protocol layer of DoP adds this risk to this product. Since Hegel permitted this error to escape into the field, I do not have confidence in thoroughness of regression testing of subsequent releases, and I think that I shall avoid this uncertainty and return the H390.

JRiver was configured correctly, and the "play silence" option for DoP made no difference. I have returned the H390 for a refund, and the dealer was excellent. Before purchasing this unit, the relatively unusual DoP protocol in the specification aroused my suspicion, and I asked Hegel to do interoperability testing with JRiver before I made the purchase, to possibly save me and my dealer, and even Hegel, a lot of trouble. They declined, politely. I could not do this test at the dealer, because their facility is closed to the public due to the pandemic, but they offered me a 30-day return guarantee. After I bought the unit and reported this issue to Hegel, they declined to perform further testing and were not even curious about my circumstance, indicating that several thousand unit had been sold with no complaints. Hegel Technical Support indicated that the issue had been forwarded to the developers, however, but if the solution was on their end, they would not be able to implement it before my 30-day return window had closed. So, I returned the unit.