• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Topping DX5II Balanced DAC and Headphone Amp Review

Rate this DAC & HP Amp

  • 1. Poor (headless panther)

    Votes: 17 3.2%
  • 2. Not terrible (postman panther)

    Votes: 19 3.6%
  • 3. Fine (happy panther)

    Votes: 54 10.2%
  • 4. Great (golfing panther)

    Votes: 439 83.0%

  • Total voters
    529
I just had this happen to me today
turned it on and it was on coax when I only have optical connected
I would think the unit should sense what is actually being used?

If you have the device set to auto-detect in the Input Option menu, then yes, switching to the first signal it detects is the expected behaviour. Because I have it set to Manual in the Input Option menu, I think the device should stay on the input I have chosen (i.e. OPT). When the USB connection has been severed (but still active in the settings), then it does not switch to USB. It only does so when there's a physical USB connection.

Topping did respond to my bug submission this time (they did not when I reported the issue on FW 1.57). They asked for a video with the USB disconnected, but I told them that that is not likely to show the problem. I sent them two: one connected, one disconnected. As expected, when the USB connection is severed, the device doesn't switch to USB because no USB signal was detected. The issue, I think, is with the device auto-detecting the first signal type it receives when coming out of standby mode despite the settings being on Manual. I do also have the On/Off Trigger set to Signal, and it's possible that there's a conflict between the Manual input option and Signal trigger. If Topping won't fix this (even though they inadvertently had in 1.62), then I may be in a spot where I'll need some kind of USB DDC with a 12v trigger out, and use that On/Off Trigger instead of Signal.
 
Really? Not responsible. The product is not a $50 dongle. I found that these days even such dongles' onboard PEQ does not exhibit this level of quantization noise.
Interesting measurements. You mention that the one shown is a worst case scenario. Is it because three filters are cascaded ? Does this perform better in a more typical usage scenario?

Regarding the low shelf, is there a suitable value of the Q factor that matches the equalizer aaPO implementation with Q0.71 ?
 
PEQ remains to be quite unreliable.

Few days ago I created a PEQ for my headphones (LS 80Hz 1dB 0.68Q ; peak 677Hz 2dB 3Q ; peak 2180Hz -2.5dB 5Q). Today when I finally got around to actually measure what DX5II outputs there was a huge dip at around 500Hz instead of gain at 677Hz. Going back to Topping Tune it showed that there was additional -7.5dB filter at 500Hz which I had never enabled.

I don't know when this new filter was added, so for now I'll measure DX5II output regularly to see when filters change without my input. I hope it's only when connected to Topping Tune and not randomly e.g. when switching power on/off.

ps. I'm using REW to measure this by connecting DX5II line out to my computers line in and then doing a measure sweep with PEQ disabled and PEQ enabled and compare those.
 
Unfortunately, my interest in this DAC, which can do room correction for all inputs, has faded. Too many glitches and bugs. I am surprised that Topping, with such a long experience in designing audio devices, could not implement at least a somewhat working product.
 
Interesting measurements. You mention that the one shown is a worst case scenario. Is it because three filters are cascaded ? Does this perform better in a more typical usage scenario?

Regarding the low shelf, is there a suitable value of the Q factor that matches the equalizer aaPO implementation with Q0.71 ?
We've been barking for stuff like that for sometime now.
At the linked thread you can also find a paper describing just that.

I'm afraid that XMOS's horsepower, shared with the rest of the stuff is not enough.

That's on top of user-errors like bad filter stacking, we don't just throw filters around randomly, and a good implementation should warn against it.
 
Sometimes I like to take some risks for fun so I pulled the trigger on a silver dx5ii. In spite of the limitations, for simple headphone PEQ it should work. I will try to set it once, maybe test frequency response and then uninstall the topping app to see if it remains stable in terms of settings.

What are you guys using to measure the frequency response with PEQ on ? It's been a while since I fiddled with such measurements and maybe there is some new software around.
 
What are you guys using to measure the frequency response with PEQ on ? It's been a while since I fiddled with such measurements and maybe there is some new software around.
@jkim's measurements were made using Room EQ Wizard. You don't need anything else.
 
Sometimes I like to take some risks for fun so I pulled the trigger on a silver dx5ii. In spite of the limitations, for simple headphone PEQ it should work. I will try to set it once, maybe test frequency response and then uninstall the topping app to see if it remains stable in terms of settings.

What are you guys using to measure the frequency response with PEQ on ? It's been a while since I fiddled with such measurements and maybe there is some new software around.
You shouldn’t need to uninstall it, just don’t actively run it.

Note the default behavior on windows is to close to taskbar, ie keep running. You can configure it to exit.
 
Yeah looks like floating point resolution vs double precision the software you guys use (apo or something)
I believe TTGK & FiiO devices such as the KA15 use HW-based DSP, or at least controllers with specialized DSP co-processors.
Topping PEQ implementation on the other hand relies on XMOS SW libraries. These libraries have been available for quite some time, but it appears they are only used with the XU316 chip. Could it be that, despite being XMOS high-end chip, it is still not powerful enough, or is missing the high-precision maths lib. needed to compute DSP correctly—as shown on these “corner-type” tests?
32 bit chip vs 64 required for lower quantization, that's why. I'm not sure what FiiO and TTGK use but it always depends on the bit depth regardless.
We've been barking for stuff like that for sometime now.
At the linked thread you can also find a paper describing just that.

I'm afraid that XMOS's horsepower, shared with the rest of the stuff is not enough.

That's on top of user-errors like bad filter stacking, we don't just throw filters around randomly, and a good implementation should warn against it.

I collected some relevant replies as we may not want this discussion to be scattered over different places.

I realize that this topic has been discussed in some depth. Upon reading the discussion b/w @audiofun, @Sokel, and @Dandelion in another thread, I do see valid points of both sides. In fact, the measured quantization noise level of the D50 III's (or DX5 II's) onboard PEQ is definitely better than the case of pure float32 biquad implementation (e.g., earlier versions of EQ APO)---EQ APO adopted float64 processing since V1.0 in 2021. For the Topping, there must be room for improvement as the XMOS XU316's processing power should be high enough to handle the need, but if it requires some careful software implementation (like what JDS Labs did), then we may be asking too much from a product that offers other excellent hardware features at this price point. Sure, we can criticize Topping for not being able (or willing) to do the same thing that another company did. But we may want to admit that these companies have different strengths and provide what they can within their limitations.

Anyway, as mentioned by @CedarX, with respect to computational efficiency and precision, PEQ based on a dedicated hardware DSP core must have an advantage. For example, the TRN Black Pearl provides 115 dB THD+N and transparent 10-band PEQ at a price < $50. TTGK and FiiO keep releasing similar devices...
 
Last edited:
PEQ, Screen with VU meter, remote this is stilly value for $300... I was looking forward to getting mine, then the post office lost it :(
 
If you have the device set to auto-detect in the Input Option menu, then yes, switching to the first signal it detects is the expected behaviour. Because I have it set to Manual in the Input Option menu, I think the device should stay on the input I have chosen (i.e. OPT). When the USB connection has been severed (but still active in the settings), then it does not switch to USB. It only does so when there's a physical USB connection.

Topping did respond to my bug submission this time (they did not when I reported the issue on FW 1.57). They asked for a video with the USB disconnected, but I told them that that is not likely to show the problem. I sent them two: one connected, one disconnected. As expected, when the USB connection is severed, the device doesn't switch to USB because no USB signal was detected. The issue, I think, is with the device auto-detecting the first signal type it receives when coming out of standby mode despite the settings being on Manual. I do also have the On/Off Trigger set to Signal, and it's possible that there's a conflict between the Manual input option and Signal trigger. If Topping won't fix this (even though they inadvertently had in 1.62), then I may be in a spot where I'll need some kind of USB DDC with a 12v trigger out, and use that On/Off Trigger instead of Signal.
Mine did it again

I’m only using optical

Shut it off yesterday and upon turning on it was on coax

No coax connected ever
 
Mine did it again

I’m only using optical

Shut it off yesterday and upon turning on it was on coax

No coax connected ever

I would report that to Topping. If you do not have Coax connected or activated in the Input Option menu, then maybe they'll fix it because they have responded by saying that it's normal behaviour.
 
Topping should be ashamed to put something like this out in the wild without ironing the software out first.
I agree, and considering the amount of enthusiastic beta testing that ASR members are doing here @TOPPING should contemplate donating a decent amount to the forum.
 
I agree, and considering the amount of enthusiastic beta testing that ASR members are doing here @TOPPING should contemplate donating a decent amount to the forum.
I see where you coming from but I really appreciate the incredible value of this $299 DAC with performance and features that would have cost 5x or more just a few years ago
 
I agree, and considering the amount of enthusiastic beta testing that ASR members are doing here @TOPPING should contemplate donating a decent amount to the forum.

No one is beta testing. They're encountering issues, and (hopefully) reporting them to Topping to get fixed.
 
No one is beta testing. They're encountering issues, and (hopefully) reporting them to Topping to get fixed.
That's exactly what beta-testing is.
In case anyone wonders what happens for mature products that get new versions after 3-5 years, it's exactly that, company does it before users.
 
Back
Top Bottom