• 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: 11 2.5%
  • 2. Not terrible (postman panther)

    Votes: 14 3.2%
  • 3. Fine (happy panther)

    Votes: 43 9.8%
  • 4. Great (golfing panther)

    Votes: 371 84.5%

  • Total voters
    439
Topping only gives a reason for it happening. Since this does not happen with the SMSL PO100 2024 using the same XMOS chip, this seems like a hardware problem. If the digital signal is corrupted there, it could show up in the FFT and level meter. It does not. However, the meters only show signal from -59.5 dBFS RMS or so and the FFT from -59 dBFS RMS and it could be below that.
 
I have created a file of all zeros for my own testing using Python. It produces popping over USB. It does not produce popping using a SMSL PO100 2024 with either optical or coaxial input.

I cannot attach either the program or the audio file, however, so I have added the program code as a txt-file. Change the ending to .py and it will work as a python program. I have attached a picture of it and the console output below.
Due to an unforeseen compromise of my privacy brought to my attention by @Berwhale, the picture had to be removed. I have made a new one and put it below.
Screenshot 2025-12-05 at 20.48.06.png
 
...wow...is this getting better or worse...?!?...

...I am having no issues with the Schiit stack...I don't love it though...

...I thought I could love the DX5II...maybe I would love an RME ADI 2 DAC FS...
 
Last edited:
...wow...is this getting better or worse...?!?...

...I am having no issues with the Schiit stack...I don't love it though...

...I thought I could love the DX5II...

It's not getting worse. The discussion has been on an issue that has been known for years, and is not exclusive to this DAC (or even Topping).
 
I was just about to get the DX5 II when I read about the popping.

I ran that python script, but haven't heard a thing.

I'm currently using an audio interface on Linux and I have zero popping in my headphone. Should I expect popping if I get a DX5 II?
 
I was just about to get the DX5 II when I read about the popping.

I ran that python script, but haven't heard a thing.

I'm currently using an audio interface on Linux and I have zero popping in my headphone. Should I expect popping if I get a DX5 II?
The script just generates and checks the file. Did you open the file in player?

No idea how it works on Linux.
 
The script just generates and checks the file. Did you open the file in player?

No idea how it works on Linux.
Yes. No popping.

I tested the ZH3 and I had the 200ms delay silence when playing a new audio. So I suppose this means it's not continuous streaming? Otherwise I would expect no delay silence in the ZH3 every time I play a new audio. Or is that delay in the ZH3 a device internal thing and not related to having continuous stream or not?
 
Last edited:
As a new DX5II user I got curious about this popping effect, so I ran the above python script, generated zeroed wav file and tried to play it in different players on Windows (MPC, Foobar via "Primary Sound Driver", as well as FL Studio via Topping ASIO driver) - absolute silence, no matter where to start/play/replay/pause etc.
Just in case, my setup: Windows 11 26200.7171, Topping DX5II 1.76 firmware, Topping Audio Driver 5.74, HIFIMAN Ananda Nano.
 
The same thing happens on Windows out of the box, which is how 90% of users use it.
Really? This happens on Windows when you use shared audio? My impression is that this issue only affected users who used exclusive modes. I've never experienced it with my DX5 II.
 
I am just sending zeros with the file and playing and pausing that. That alone produces the popping.
The point of the zero stream is to ALWAYS having it playing in the background. This stops the DAC from sleeping and prevents pops when you start playing 'real' music.

This is similar to the 'fix' in Windows, where the XMOS driver (written by Thesycon and used by many DAC manufacturers) constantly streams data (i.e. zeros) to the DAC when Streaming is set to 'Always On'...

1765015255258.png
 
So I installed a USB analyzer on Windows...

I set Windows audio to output to my monitor (to stop it outputting to the DX5 II)
I set MusicBee to output to my DX5 II using WASAPI Exclusive. I have nothing playing in MusicBee.

With Streaming set to 'Always On' in the Topping Control Panel. You can see the '0' being streamed DOWN to the DX5 II...

1765017203739.png


With Streaming set to 'On When Needed' in the Topping Control Panel. The '0' disappear...

1765017280363.png


So I played something in MusicBee. This is what a USB packet of 'La femme d'argent' by Air looks like... :)

1765017522729.png


I have not heard any popping yet, I may not have left the DAC long enough for it to sleep.
 
Last edited:
So I set Windows to output to the DX5 II and set MusicBee to play using DirectSound. Streaming is set to 'On When Needed' in Topping Control Panel.

When playing music, the packet capture is similar to the last screen above.

When I stop the music, the packet capture output looks similar to the output with Streaming set to 'Always On' i.e. there is a stream of '0' being set to the DAC.

25 seconds after stopping the music, the '0' stop and we are left with the same pattern we had above with streaming set to 'On When Needed'...

1765018456659.png


So it looks like Windows does not stream anything to the DAC if no sounds (system or application) are playing. I still haven't heard any popping...
 
Last edited:
I got the popping! It's pretty quiet and it would probably not bother me given the noise floor in the Berwhale household.

To get the popping, I have Windows set to output to the DX5 II and I have MusicBee set to output to the DX5 II using WASAPI Exclusive - with this setup I get a small pop when starting and stopping music playing in MusicBee.

If I set MusicBee back to DirectSound, the problem disappears.

This explains why I have not encountered this issue before. For many years, I have been using eAPO to apply PEQ in Windows and have therefore not been using exclusive audio in any application. I don't see any need or benefit to running exclusive mode drivers for music listening with PEQ applied on the DX5 II, so i'll be leaving MusicBee on DirectSound.
 
I got the popping! It's pretty quiet and it would probably not bother me given the noise floor in the Berwhale household.

To get the popping, I have Windows set to output to the DX5 II and I have MusicBee set to output to the DX5 II using WASAPI Exclusive - with this setup I get a small pop when starting and stopping music playing in MusicBee.

If I set MusicBee back to DirectSound, the problem disappears.

This explains why I have not encountered this issue before. For many years, I have been using eAPO to apply PEQ in Windows and have therefore not been using exclusive audio in any application. I don't see any need or benefit to running exclusive mode drivers for music listening with PEQ applied on the DX5 II, so i'll be leaving MusicBee on DirectSound.
I thought DirectSound was an old audio interface superseded by WASAPI (shared)
 
I thought DirectSound was an old audio interface superseded by WASAPI (shared)
Yes, it is the old DirectX interface, perhaps I should use WASAPI (Shared). As far as I recall, MusicBee defaults DirectSound and I can't hear any differences between the two, but DirectSound is deprecated, so I expect it will disappear at some point.
 
With Streaming set to 'Always On' in the Topping Control Panel. You can see the '0' being streamed DOWN to the DX5 II...
So basically they can create a program on Mac that runs in background and does the same (streaming zeros) to prevent this issue?
I think the design is problematic that requires such a workaround in the first place, whether it is on the XMOS side or device manufacturers, I don't know.
 
So basically they can create a program on Mac that runs in background and does the same (streaming zeros) to prevent this issue?
I think the design is problematic that requires such a workaround in the first place, whether it is on the XMOS side or device manufacturers, I don't know.
Yes, that is a workaround on a Mac. Someone has already created a program to do this, I posted the link a few pages back. I have no idea if it works as I don't have a Mac.
 
Yes, that is a workaround on a Mac. Someone has already created a program to do this, I posted the link a few pages back. I have no idea if it works as I don't have a Mac.

I went to that link, but it wouldn't let me download anything (it was blocking for spam/malware reasons or something along those lines).
 
Yes, that is a workaround on a Mac. Someone has already created a program to do this, I posted the link a few pages back. I have no idea if it works as I don't have a Mac.
I understand, but what I mean is that "always on" option for the Windows driver does the same thing basically right? So there is no limit for Topping to release such a software on Mac. Unless the driver does something else too on Windows?
 
Back
Top Bottom