Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kmmcd]

I just connected a new H390 to my PC running Media Center 27. I am successfully running DSD over DOP (over USB). However, I have discovered an annoying anomaly, and I don't know on which end of the USB cable that the issue originates. 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 and resume, there is no pop, and there is no interruption to the display correctly indicating the DSD rate. However, if I stop 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 laying a DSD files and now "thinks" that playback is PCM.

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.

If I was to guess, either Media Center is not correctly maintaining correct flags in the data stream, or the H390 is not correctly interpreting them, at least for DSD64 and DSD128 playback. If I am unable to resolve this issue, I shall return the H390 before my 30-day audition period expires.

What do you all think?

[kmmcd]

How can I contact JRiver directly about this issue?

I have checked their web page, and there is no "contact us" option. I wish to get this issue resolved, as its timeliness represents considerable financial impact for me.

I have read the DoP standard, and this issue may very well be the one that is addressed on page 2. But this is not certain, and I would not presume to state this.

[Awesome Donkey]

How can I contact JRiver directly about this issue?

The forums are how. That said, the lack of replies is likely either a) not enough time has passed for people to read the topic and reply or b) because nobody knows because many people aren't using the H390. If I had to guess, you might need to contact Hegel about it and see what they say. But first you should try to narrow down whether or not it's the DAC causing the pops or if it's in the source DSD file(s) you're using themselves.

First, some (well, actually, a lot of) DACs are known to pop, especially when changing PCM sample rates or changing from PCM to DSD (or vice versa). My Topping D50s DAC always pops when switching from PCM to DSD or DSD to PCM. If it doesn't pop when changing tracks manually, this could be an indication. Like as a experiment try playing back a DSD track from an album (and make sure it does indeed pop at the beginning at playback) then manually start playback of a track from a completely different artist/album and listen for pops. If there isn't any, try playing back the first track you tried to play (the one that popped) and see if a pop occurs. If not, you may be able to rule out the source DSD files you're using as the source of the pop (more on this later).

However, if I stop 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 laying a DSD files and now "thinks" that playback is PCM.

This is probably normal. My current and past DSD-capable DACs, upon stopping playback, will drop out of DSD (DoP) back to PCM, be it 176.4 kHz or 352.8 kHz depending if I'm listening to DSD64 or DSD128 content. I literally just tested this one, I played back DSD64 content, pressed stop and the DAC drops back to PCM 176.4 kHz. You could contact and double check with Hegel about it (as the DAC controls this behaviour), but I'm fairly certain it's working as intended here. It not dropping back down to PCM with DSD256 can likely be explained as well. The manual for the H390 I saw mentions that its max PCM sample rate it supports is 384 kHz, but DSD256 over DoP would need a PCM sample rate of 705 kHz so that could be why it doesn't drop back to PCM. It is strange though, I'm not sure how it could support DSD256 over DoP without supporting a 705 kHz PCM sample rate. Maybe somebody can explain that one.

It is also strange that it pops with DSD64 and DSD128 content, but not DSD256. That to me would suggest it's some sort of quirk with the DAC or perhaps with the source DSD files you're trying to use. If you're using DSF files by extracting them from SACD ISOs using sacd_extract, I'd make sure you're using one of the forks of sacd_extract with the non zero padding fix (-z via the command line), because this can add audible pops/clicks at the beginning (split point) of DSF files when extracting/splitting them from SACD ISOs.

[kmmcd]

Donkey:

The DSD files are purchased as downloads from nativedsd.com and were not ripped from SACD. They have not exhibited this issue when played via USB to an Exasound E32 DAC or Topping D90 DAC. But, as you know, DoP is not employed by these two DAC's.

I notified Hegel of this issue, and they replied promptly. They suggested that I upgrade the firmware on the unit (if it is not already up-to-date), which I have not yet determined. They also point out that I am the first to raise this issue, and they have sold several thousand H190'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.

When skipping from a track from one album to another of the same DSD rate, and back again, there is no pop.
When skipping from a track from one album to another of a different DSD rate, there is a pop.
The exception to the above is that when skipping one DSD album of any rate to another one that is DSD256, there is no pop.

[kmmcd]

I just remembered: I also have not experienced this problem with an iFi iOne USB DAC, or with the integral DAC in the Yamaha A-S801 integrated amplifier (which the H390 replaced in my setup). But then again, none of these units use DoP, either.

[kmmcd]

I realize that no one here may have an H390. However, if you use Media Center with another DAC using DoP, I would greatly appreciate whether you experience the same anomalies that I have with the H390.

[Wheaten]

Here's some interesting reading on this matter, Hegel is one of the many that pops:
https://ifi-audio.com/pop-goes-dsd-why-does-this-happen/

[dtc]

As the ifi article suggests, try turning on the play silence option in the WASAPI setup and also the play silence in the normal audio setups.

As the Donkey says, there are know problems with converting isos to DSD, so, as a test, you can try setting up MC to convert all tracks to DSD and see if the problem still happens. Or, convert some PCM tracks to DSD and see how it works. That might help narrow down why the problem is occurring.

The ifi article is misleading when it states that the pop problem is unavoidable. Only some DACs do it, which means that some DAC designers have figured out how to deal with the issue.  For example, my Chord DAC using DoP and I never hear a pop.  Also, the article suggests that native DSD does not pop but DoP does, which seems to indicate that, in those cases, there is a problem with the DoP implementation.

[kmmcd]

The DSD pop does not occur with any of the several other DACs I have used (see above), but they do not use DoP. I tried selecting the "play silence" for WASAPI option that the iFi article mentions, but that makes no difference. The pop still occurs. The DoP open standard seems to warn of this very issue:

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

Given what little visibility I have of this issue, it seems very possible that the JRiver implementation of DoP is in error (unlikely, but not impossible, since JRiver was one of the authors of this standard), the Hegel implementation is in error, or the standard itself is flawed. DTC, your observation about the Chord DAC, while appreciated, is not that helpful. When shopping for a DAC several months ago, I researched (among many other vendors) Chord's DSD implementation, and Chord's FPGA-based inhouse-developed DSD processing does not play DSD natively. The Chord signal processing chain converts all DSD to PCM for playback. When I queried Chord why they chose this implementation, they replied it was so that volume could be adjusted for DSD playback (presumably in the digital domain). So, the observation of Chord playback may not be germane to my issue. (In contrast, an Exasound DAC, for example, adjusts volume in the analog domain.)

Therefore,it is still my hope for anyone else who has a DAC that uses the DoP protocol and plays DSD natively, to observe and report DSD playback observations. This would be extremely insightful.

[dtc]

My comment about the Chord DAC was specifically in reference to the comment in the ifi article.

The DoP standard specifically states "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." It seems like Hegel may have ignored this warning, at least for 1x and 2x DSD>

Given the problems you are having and Hegel's responses to you, I would consider looking for another option. I would be happy supporting a company who does not seem to want to help its customers. But that is your choice.

[dtc]

Therefore,it is still my hope for anyone else who has a DAC that uses the DoP protocol and plays DSD natively, to observe and report DSD playback observations. This would be extremely insightful.

I'm curious as to how you think Hegel converts DSD to analog. The most direct way is to use a R-2R ladder DAC, but I do not think Hegel does that. So, it probably converts to some multi-bit delta-sigma format, although they are notably quiet about how they do the actual conversions. If they uses a multi-bit format, then one can certainly argue that that is not "native" DSD.

In your research on Hegel, have you come across any discussion about how the D to A is actually done?

It is interesting to note that on Macs, the only way to play DSD is through DoP. If DoP always caused pops, then every DAC used with a Mac would pop.

[kmmcd]

I am 99% certain that Hegel uses an AKM DAC. In any case, their are explicit in their explanations of DoP that they process DSD natively.

[dtc]

PCM typically uses 16 bits or 24 bits. The AKM probably uses  6 bits.   Neither of those formats is "native" DSD, which is single bit. If you want to do D to A on single bits, you need to stay away from multi-bit formats. You need a ladder DAC for that, or you get into the whole noise shaping issue.

I just want to point out that "native" can be a  loose term in these contexts.

[kmmcd]

I have returned the H390 for a refund. My local dealer was most gracious and professional. More important than sounding good, a high end audio component should be fully functional.

[dtc]

That is too bad. Hegel has a fine reputation. I would have expected them to be more responsive to the problem.