Topping DX5II Balanced DAC and Headphone Amp Review

[Morla]

It's really kind of you to assist them in fixing bugs they probably should have stumbled upon on their own. So my respect for investing that time @ziggurcat

 

[Mutex]

Just dedicated in helping getting this device to the best possible place it can be.

Thank your for your services. Topping should send you a "Topping QA Team" T-Shirt.

 

[somebodyelse]

Thank your for your services. Topping should send you a "Topping QA Team" T-Shirt.

Or better yet a "Topping QA Team" pay cheque

 

[ziggurcat]

It's really kind of you to assist them in fixing bugs they probably should have stumbled upon on their own. So my respect for investing that time @ziggurcat

The last handful of issues I have reported to them wouldn't have been stumbled upon, and were only because of the unique setup I have for my desktop system. None of those issues happened under "normal" conditions (i.e. a straight USB connection from computer to DX5 II). My position has always been that they will not fix the problems no one tells them about, and it only benefits everyone if they are reported to them.

The only issue that's left, as far as I'm concerned, is fixing the data streaming pop on Mac, but that is one that is not specific to Topping or this particular DAC.

 

[Outspacer]

The last handful of issues I have reported to them wouldn't have been stumbled upon, and were only because of the unique setup I have for my desktop system. None of those issues happened under "normal" conditions (i.e. a straight USB connection from computer to DX5 II). My position has always been that they will not fix the problems no one tells them about, and it only benefits everyone if they are reported to them.

The only issue that's left, as far as I'm concerned, is fixing the data streaming pop on Mac, but that is one that is not specific to Topping or this particular DAC.

Long time lurker here just signed up - firstly, thanks for the bug reporting you and everyone else has done! I got mine a week or so ago with 1.76, almost immediately updated to 1.78 and then 1.91 when that came out. I haven't found any real issues and have just been able to enjoy it, no doubt helped by all the reports.

The one thing that is annoying me is the auto-switch to USB input when the PC wakes up, even though it's set to manual input select. In my case, I want to have the USB input available but primarily use the coax from a Wiim Pro, so I'd rather not have to disable USB in the settings (as I think you did to work around the problem...?). Did you get any feedback from them on that one?

 

[ziggurcat]

The one thing that is annoying me is the auto-switch to USB input when the PC wakes up, even though it's set to manual input select. In my case, I want to have the USB input available but primarily use the coax from a Wiim Pro, so I'd rather not have to disable USB in the settings (as I think you did to work around the problem...?). Did you get any feedback from them on that one?

Believe me, I have brought this up with them several times. They maintain that that is normal behaviour, and the last thing they said about it was:

"this setting isn't meant to disable the function; it's likely just to allow you to quickly select the input you need without having to navigate through so many options."

The good news is that you do not need to have the USB input active in the settings (leave it unchecked) in order to use Topping Tune or update FW. Simply having it connected with a USB cable is all that is necessary for either of those functions.

 

[Outspacer]

Believe me, I have brought this up with them several times. They maintain that that is normal behaviour, and the last thing they said about it was:

"this setting isn't meant to disable the function; it's likely just to allow you to quickly select the input you need without having to navigate through so many options."

The good news is that you do not need to have the USB input active in the settings (leave it unchecked) in order to use Topping Tune or update FW. Simply having it connected with a USB cable is all that is necessary for either of those functions.

Thanks. I might have a go at reporting it as well because their disappointing response there doesn't really answer the question! I'd be happy if 'manual' actually meant manual and it stayed where I'd left it! Unluckily for me I do actually want to use the USB input for music sometimes. Overall it's a pretty minor issue, but also seems like something they could fix fairly easily if they could be persuaded to.

 

[ziggurcat]

Thanks. I might have a go at reporting it as well because their disappointing response there doesn't really answer the question! I'd be happy if 'manual' actually meant manual and it stayed where I'd left it! Unluckily for me I do actually want to use the USB input for music sometimes. Overall it's a pretty minor issue, but also seems like something they could fix fairly easily if they could be persuaded to.

You can certainly try, but they will likely respond by telling you that's normal behaviour. I personally don't agree with that (IMO, if it's set to Manual, then it should only change inputs if/when you choose to change the input). Lately, I have found that it doesn't change to USB as often, and I noticed that if I click the mouse button first (which just wakes up the DAC, the monitor stays in standby mode) before pressing any key on the keyboard to fully wake my Mac up, it will stay on OPT. I do generally keep the USB input disabled to avoid it constantly switching, though. I also found that the DX5 II will not randomly wake up if I have the USB input disabled in the settings -- using only OPT input, it stays in standby mode.

Now, at this time, you may notice a hiccup/stutter during music playback if you use the OPT or COAX inputs. If you do, simply go into the settings, and flip the SPDIF mode back and forth (meaning: if it's on Mode 1, change it to Mode 2, then immediately back to Mode 1, and exit the settings menu). That should correct it until they release the next FW (I can confirm it has been fixed in the test FW they sent me last night, but it caused another major problem that you will not encounter on the current FW, so I will not go into the details unless it shows up in the next publicly-released FW).

A few additional notes on the hiccup: If you ever press the preset buttons on the remote (C1 or C2), you need to do the workaround again. Also, the workaround is output-dependent, so if you change to a different output type (i.e. if you go from HPA to LO or even switch from HPA BAL to HPA SE/LO BAL to LO SE), it needs to be done again. You only need to do the workaround once if you do not switch outputs or use the preset buttons on the remote. I have not found that power cycling the DX5 II with the switch on the back causes the issue to reappear in case you prefer to turn it off that way after each listening session.

 

[Outspacer]

You can certainly try, but they will likely respond by telling you that's normal behaviour. I personally don't agree with that (IMO, if it's set to Manual, then it should only change inputs if/when you choose to change the input). Lately, I have found that it doesn't change to USB as often, and I noticed that if I click the mouse button first (which just wakes up the DAC, the monitor stays in standby mode) before pressing any key on the keyboard to fully wake my Mac up, it will stay on OPT. I do generally keep the USB input disabled to avoid it constantly switching, though. I also found that the DX5 II will not randomly wake up if I have the USB input disabled in the settings -- using only OPT input, it stays in standby mode.

Now, at this time, you may notice a hiccup/stutter during music playback if you use the OPT or COAX inputs. If you do, simply go into the settings, and flip the SPDIF mode back and forth (meaning: if it's on Mode 1, change it to Mode 2, then immediately back to Mode 1, and exit the settings menu). That should correct it until they release the next FW (I can confirm it has been fixed in the test FW they sent me last night, but it caused another major problem that you will not encounter on the current FW, so I will not go into the details unless it shows up in the next publicly-released FW).

A few additional notes on the hiccup: If you ever press the preset buttons on the remote (C1 or C2), you need to do the workaround again. Also, the workaround is output-dependent, so if you change to a different output type (i.e. if you go from HPA to LO or even switch from HPA BAL to HPA SE/LO BAL to LO SE), it needs to be done again. You only need to do the workaround once if you do not switch outputs or use the preset buttons on the remote. I have not found that power cycling the DX5 II with the switch on the back causes the issue to reappear in case you prefer to turn it off that way after each listening session.

Well, worth trying anyway!

Thanks for the info on the hiccup, I'd read your posts on it but that's a very handy how to. I don't think I've noticed it yet, but that might be just because I'm still in the exploring phase, fiddling with setup and settings and jumping around lots of tracks rather than playing through albums as much. I do switch between HPA All and LO All sometimes so I suppose that sets me up for getting it though (when I forget to do the workaround). Hopefully a working firmware to fix that soon since they're on it already.

 

[ziggurcat]

Well, worth trying anyway!

Thanks for the info on the hiccup, I'd read your posts on it but that's a very handy how to. I don't think I've noticed it yet, but that might be just because I'm still in the exploring phase, fiddling with setup and settings and jumping around lots of tracks rather than playing through albums as much. I do switch between HPA All and LO All sometimes so I suppose that sets me up for getting it though (when I forget to do the workaround). Hopefully a working firmware to fix that soon since they're on it already.

The pattern I noticed with the hiccup is it generally happens in the first minute of playback, then will happen about every 2-3 minutes after that. It might not even happen if you're using something like a WiiM, it's possible that it will only occur if you're using a computer as your source.

 

[Morla]

Would be nice if device had a way to display the bluetooth codec that is currently used.

 

[ziggurcat]

Would be nice if device had a way to display the bluetooth codec that is currently used.

The manual mentions aptX-Adaptive, but also says that it supports multiple codecs, and if aptX is disabled in the settings, other codecs will be used depending on the device (though, it says "depending on the phone").

 

[Morla]

Yeah that's exactly what I did. Disabled the aptx and were left with either bad bluetooth or ldac. Depends on the sending device if I get told what codec is used and some android devices do tell you about it (even with a ldac "switch" icon) and some do not. Sometimes it even involves activating developer options. While the topping device knows the codec name and could display it. Annoying (a bit).

P.S. maybe the BT 96Khz gives it away..

 

[Bauhaus]

Yeah that's exactly what I did. Disabled the aptx and were left with either bad bluetooth or ldac. Depends on the sending device if I get told what codec is used and some android devices do tell you about it (even with a ldac "switch" icon) and some do not. Sometimes it even involves activating developer options. While the topping device knows the codec name and could display it. Annoying (a bit).

P.S. maybe the BT 96Khz gives it away..

I also discussed it here.
I sent an email to Topping Service today requesting the addition of this feature. We will see if it is possible

@ziggurcat

The manual mentions aptX-Adaptive, but also says that it supports multiple codecs, and if aptX is disabled in the settings, other codecs will be used depending on the device (though, it says "depending on the phone").

It is not really clear to be honest. If your device doesn’t support aptX (which is my case), do you get SBC or AAC if aptX is not disabled?

 

[Morla]

@Bauhaus does it show 96Khz too using not aptx and not ldac?

 

[ziggurcat]

It is not really clear to be honest. If your device doesn’t support aptX (which is my case), do you get SBC or AAC if aptX is not disabled?

I have no idea. All that is shown in the Audio MIDI app is 44.1kHz 2ch 32-bit Float, and it doesn't allow me to change it from anything other than that.

 

[Bauhaus]

@Bauhaus does it show 96Khz too using not aptx and not ldac?

I will check when I get back home.

 

[Outspacer]

The pattern I noticed with the hiccup is it generally happens in the first minute of playback, then will happen about every 2-3 minutes after that. It might not even happen if you're using something like a WiiM, it's possible that it will only occur if you're using a computer as your source.

Right. For some reason I can't reproduce it, so there must be specific circumstances in the setup needed for it to happen. I tried with optical from a Windows PC that has Realtek HD Audio on the motherboard, at 48kHz and at 44.1kHz, using HPA All and LO All output, and pressing config button after 10 minutes or so to see if that would prod it to occur. I don't claim to have done this methodically or exhaustively, so can only say that there seems to be cases where it doesn't hiccup. Lucky me I guess!

 

[CuriousAli]

Those of you on Mac that had the delay/pops, I have created a proof of concept app that uses CoreAudio APIs to send zeroes to the selected Audio device to prevent delays and pops, it was all made with Gemini 3 Pro, can't take credit for it, and also use it at your own risk.
In my case (with Fiio KA17) it can't prevent the delay totally but reduces it, and no pops so far, so hopefully it works for you on DX5 II too?

I don't have a paid developer account to send the app to Apple for notarization, so you have to manually allow the app in macOS security settings to run, or build the Xcode project yourself from the sources on Github:

GitHub - openmac/KeepMacAudioAlive: Keep Mac audio alive to prevent delays or pops with some DACs.

Keep Mac audio alive to prevent delays or pops with some DACs. - openmac/KeepMacAudioAlive

github.com

 

[ziggurcat]

Those of you on Mac that had the delay/pops, I have created a proof of concept app that uses CoreAudio APIs to send zeroes to the selected Audio device to prevent delays and pops, it was all made with Gemini 3 Pro, can't take credit for it, and also use it at your own risk.
In my case (with Fiio KA17) it can't prevent the delay totally but reduces it, and no pops so far, so hopefully it works for you on DX5 II too?
View attachment 498457

I don't have a paid developer account to send the app to Apple for notarization, so you have to manually allow the app in macOS security settings to run, or build the Xcode project yourself from the sources on Github:

GitHub - openmac/KeepMacAudioAlive: Keep Mac audio alive to prevent delays or pops with some DACs.

Keep Mac audio alive to prevent delays or pops with some DACs. - openmac/KeepMacAudioAlive

github.com

Not all heroes wear capes.

Edit: and it works like a charm!