Topping DX5II Balanced DAC and Headphone Amp Review

[CuriousAli]

Not all heroes wear capes.

Thank you, I hope it works for you too!

 

[ziggurcat]

Thank you, I hope it works for you too!

Works perfectly for me!

Edit: @CuriousAli may I send you a PM? I may have come across a bug with the app.

 

[CuriousAli]

Works perfectly for me!

Edit: @CuriousAli may I send you a PM? I may have come across a bug with the app.

Of course you can.


Edit: Current known issue is if you have the app open and disconnect and reconnect your DAC, you have to quit and open the app again.

 

[JIW]

I have been in correspondence with Topping about the popping for a bit now. So far, they have not been able to reproduce it. Neither with speakers or headphones. Not even with the silent file.

I have also gotten myself a USB C to USB B cable to rule out the USB hub, but alas there is no difference even when using headphones and connecting the DX5 II directly to a wall socket as well as running the MacBook Air on its battery.

 

[CuriousAli]

I have been in correspondence with Topping about the popping for a bit now. So far, they have not been able to reproduce it. Neither with speakers or headphones. Not even with the silent file.

I have also gotten myself a USB C to USB B cable to rule out the USB hub, but alas there is no difference even when using headphones and connecting the DX5 II directly to a wall socket as well as running the MacBook Air on its battery.

I have released a new version of the app that automatically detects device connect and disconnects and it should prevent pops, because in my case silent audio file playback wouldn't prevent it, but this app using CoreAudio APIs did.
Does the pops still occur with this app for you?

Releases · openmac/KeepMacAudioAlive

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

github.com

If it gets resolved, the source code is MIT licensed, so Topping can easily take that code and implement their own solution on Mac.

 

[Yorkshire Mouth]

To save me reading the whole thread, does the PEQ only work on USB input?

Thank you.

 

[Morla]

To save me reading the whole thread, does the PEQ only work on USB input?

Thank you.

I mean it certainly states EQ6 (my custom) using BT

 

[JIW]

I have released a new version of the app that automatically detects device connect and disconnects and it should prevent pops, because in my case silent audio file playback wouldn't prevent it, but this app using CoreAudio APIs did.
Does the pops still occur with this app for you?

Releases · openmac/KeepMacAudioAlive

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

github.com

If it gets resolved, the source code is MIT licensed, so Topping can easily take that code and implement their own solution on Mac.

Silent audio playback works for me. CPU use with QuickTime Player for a looped 60 s, 32 bit, 96 kHz WAV file is around 4%.

I have looked at the app in Xcode. Why is there that CFString warning?

 

[CuriousAli]

Silent audio playback works for me. CPU use with QuickTime Player for a looped 60 s, 32 bit, 96 kHz WAV file is around 4%.

I have looked at the app in Xcode. Why is there that CFString warning?

If that works for you why not, although this one should use much less resources in practice and doesn't cause conflicts for using media playback buttons on your keyboard.
And I made it as a proof of concept to show device manufacturers can make a simple software that prevents this issue similar to how the ASIO driver on Windows does it.
As for that warning, here is Gemini 3 Pro's reason for it:

This warning happens because Swift is trying to protect you from memory management errors. CFString is a managed object, and passing its address (&stringRef) directly to C code can confuse Swift's Automatic Reference Counting (ARC), potentially leading to crashes or memory leaks.

Here is the fixed version 1.3 without that warning:

Release KeepMacAudioAlive 1.3 · openmac/KeepMacAudioAlive

Addressed the CFString warning.

github.com

 

[JIW]

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.

I have discovered a problem with the wave module writeframes function. It works properly for 32 bits, but increases time for lower number of bits. At 24 bits, length is increased by 1/3 and at 16 bits, length is doubled. It also doubles the length when only one channel is used and reduces it by 1/3 when using 3 channels. I have restricted the program to use no more than 2 channels and added corrections for the time when using 1 channels. I have also added a restriction to either 16, 24 or 32 bits and added corrections for the times. Depending on the number of decimals of the time selected there can some small deviations in the number of samples and hence the time. I have again added the program in a txt file and it is shown in the picture below.

 

[JIW]

If that works for you why not, although this one should use much less resources in practice and doesn't cause conflicts for using media playback buttons on your keyboard.
And I made it as a proof of concept to show device manufacturers can make a simple software that prevents this issue similar to how the ASIO driver on Windows does it.
As for that warning, here is Gemini 3 Pro's reason for it:

Here is the fixed version 1.3 without that warning:

Release KeepMacAudioAlive 1.3 · openmac/KeepMacAudioAlive

Addressed the CFString warning.

github.com

I tried opening the program but macOS refused.

When I then opened it via the system settings, it opens the terminal.

After the process is completed, there is still popping as before.

On the second attempt, it worked however. It uses 0.2% CPU when hidden and works.

Also, maybe you can do something about the non-transparent background of the icon.

Also, it would be nice if it could be set to streaming zeros by default as it could then be used as a login item and run all the time in the background. The start/stop and active/inactive status could also be eliminated. If it is on, it is streaming zeros. If that is not desired, it can be quit. Further, placing the icon in the menu bar and having the drop down menu when clicking it just be the device could be the simplest and most elegant implementation.

EDIT: I fixed the non-transparent background by cropping the image I found under right click on app in folder -> Show Package Contents -> Contents -> Resources as below.

Now it looks like this in the dock.

EDIT 2: I have found an even better way to fix the icon. I used Preview's instant alpha function to remove the checkerboard and cropped one pixel each side. Now it looks as below.

EDIT3: I have adjusted the image to be of similar size to all other icons by increasing the canvas by 15%. I have put it below and attached it as well since the image from the text is of worse quality.
View attachment 498632
Now it looks like this in the dock.

EDIT4: After some comparison, I have further reduced the size of the icon. Now it fits really well. I have updated the uploaded file.
View attachment 498649

 

[Mutex]

And I made it as a proof of concept to show device manufacturers can make a simple software that prevents this issue similar to how the ASIO driver on Windows does it.

Not really the job of the manufacturers to fix flaws in the OS.

As I mentioned earlier, on Linux with ALSA/Pipewire (CoreAudio equivalent on Mac) one can just set a flag to tell it to idle individual audio devices instead of suspending them. If anything, macOS users should raise a support ticket with Apple asking them to fix their system and to provide users proper control over it.

(Sorry for the rant, but its frustrating when things that aren't a problem become a problem, because of some OS' philosophy to treat users like children)

Here an excerpt from ChatGPT: "macOS does not expose a user-configurable “audio device idle suspend” policy like PipeWire/PulseAudio do on Linux. Audio and USB power management are handled internally by CoreAudio + IOKit, and Apple does not provide a supported knob to disable it globally. The only reliable method on macOS is: Keep an audio stream open continuously".

 

[ziggurcat]

I have been in correspondence with Topping about the popping for a bit now. So far, they have not been able to reproduce it. Neither with speakers or headphones. Not even with the silent file.

I have also gotten myself a USB C to USB B cable to rule out the USB hub, but alas there is no difference even when using headphones and connecting the DX5 II directly to a wall socket as well as running the MacBook Air on its battery.

So strange because they recognized the popping when I showed them the video I made for them. I have to wonder sometimes when they say they can't reproduce something that is so easily reproduceable.

 

[ziggurcat]

To save me reading the whole thread, does the PEQ only work on USB input?

Thank you.

PEQ works with all inputs on the DX5 II, but you cannot set the sample rate higher than 192kHz.

 

[JIW]

So strange because they recognized the popping when I showed them the video I made for them. I have to wonder sometimes when they say they can't reproduce something that is so easily reproduceable.

In a video they sent me of testing with a speaker they were in a fairly large open space with several people talking and doing things. Not the best test environment. They also said they tested with headphones, but which ones, where and whether on high gain or not they did not say.

Oddly enough, they could just record the output of the DAC with a good ADC and see if they get anything. They have no need to listen for anything at all.

 

[ziggurcat]

In a video they sent me of testing with a speaker they were in a fairly large open space with several people talking and doing things. Not the best test environment. They also said they tested with headphones, but which ones, where and whether on high gain or not they did not say.

Oddly enough, they could just record the output of the DAC with a good ADC and see if they get anything. They have no need to listen for anything at all.

No wonder they're never able to reproduce anything

I even let them know that the popping (for me) won't happen with HPA SE if Low gain is used, but will happen if High gain was used, and they took that information to be useful, so I don't know what's going on. Even in the video I provided to them, the popping is very difficult to pick up on a phone mic, and is more audible coming from the woofer than the tweeter, so if they're all in a room yapping at each other, they're never going to hear it.

It is evident that there's a distinct lack of consistency with them because sometimes I will get very thorough/detailed responses, but other times it's a canned copy/paste "please use in confidence, everything is fine" kind of response.

 

[CuriousAli]

I tried opening the program but macOS refused.

Thank you so much for all the feedback and helping with the icon!
The funny thing is on macOS 26 it seems it cropped the icon before showing it, so I didn't notice it.
Here is the new version with the fixed icon:

Release KeepMacAudioAlive 1.4 · openmac/KeepMacAudioAlive

Fixed the icon background transparency (thanks to JIW).

github.com

As for the prompt that macOS shows when you try to run it, it is because my Apple developer account is free and therefore couldn't send the app to Apple for Notarization, that's why you had to allow it in security settings.
Regarding it opening the Terminal first and then the app, does it always happen? I guess that's the side effect of me only testing it on macOS 26, on other macOS versions it may need some fine-tuning.
Regarding your suggestions for start at startup and menubar icon, I agree it will get much better, hopefully I get some free time the next few days and try to implement them with AI's help too.

Not really the job of the manufacturers to fix flaws in the OS.

As I mentioned earlier, on Linux with ALSA/Pipewire (CoreAudio equivalent on Mac) one can just set a flag to tell it to idle individual audio devices instead of suspending them. If anything, macOS users should raise a support ticket with Apple asking them to fix their system and to provide users proper control over it.

(Sorry for the rant, but its frustrating when things that aren't a problem become a problem, because of some OS' philosophy to treat users like children)

Here an excerpt from ChatGPT: "macOS does not expose a user-configurable “audio device idle suspend” policy like PipeWire/PulseAudio do on Linux. Audio and USB power management are handled internally by CoreAudio + IOKit, and Apple does not provide a supported knob to disable it globally. The only reliable method on macOS is: Keep an audio stream open continuously".

I think Apple was so far ahead in earlier Mac OS X days with CoreAudio and it has stagnated for some years, hopefully some shakeups at the company's leadership will make them take these stuff more seriously.
So while I would like to have that option from Apple too, it doesn't fix a flawed device which our new DACs are becoming.
You can do that on Linux, I can use my app on Mac, Windows users can set to stream zeros using the ASIO driver, but what about a gaming console? What about mobile devices?
I think it requires a cooperation between chip makers (like XMOS), device manufacturers and also standard bodies (for USB Audio) and of course OS makers.
There is a reason these devices go to sleep, to reduce energy use, but then they wake up with a delay or pop.
What you do with ALSA/Pipewire, my workaround and others keeps these devices awake and still using the energy when nothing is playing, so either this energy saving is wrong and shouldn't happen (like my other audio devices with earlier XMOS chips which are always on), or it should wake up perfectly without these settings and workarounds.
We know this can be done because our cellphones try to conserve as much energy as possible but they can immediately ring or play a notification while their screen isn't on and are in some sort of sleep, it just needs better implementation on the external DACs by all parties involved.

 

[JIW]

Thank you so much for all the feedback and helping with the icon!
The funny thing is on macOS 26 it seems it cropped the icon before showing it, so I didn't notice it.
Here is the new version with the fixed icon:

Release KeepMacAudioAlive 1.4 · openmac/KeepMacAudioAlive

Fixed the icon background transparency (thanks to JIW).

github.com

As for the prompt that macOS shows when you try to run it, it is because my Apple developer account is free and therefore couldn't send the app to Apple for Notarization, that's why you had to allow it in security settings.
Regarding it opening the Terminal first and then the app, does it always happen? I guess that's the side effect of me only testing it on macOS 26, on other macOS versions it may need some fine-tuning.
Regarding your suggestions for start at startup and menubar icon, I agree it will get much better, hopefully I get some free time the next few days and try to implement them with AI's help too.
[...]

The icon is indeed fixed with regard to the background, but still larger than the others. It also looks better than my workaround since the edges are better.

The terminal only opened on the first attempt. No issues since not even opening it through the system settings. A prompt is typical for unknown developers and downloads not from the app store. There is no way to disable that in the system settings and was something I expected. I did not expect it to not give me the option to open it anyways.

I tried making an Apple developer account, but it stated there was an annual fee of 99 € so I abandoned that idea.

The improvements would be nice, but you have already provided a workable and quite efficient solution.

I may have a look at the code and make some suggestions to make the program simpler the way I suggested earlier.

 

[JIW]

To add to the above post, I found out how to test locally without an Apple Developer account, so I can just try it myself.

 

[NOD33]

Hello ASR,

I have heard this DAC/AMP is REALLY good for the price. Like really really good.

And I want to change my old, ODAC O² Combo. Is it worth ugprading to this Topping ?

I'm listening (for the moment) with a DT770 Pro 250ohms and DT990 Pro 250ohms.

Thanks for your reply.