-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. 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!
Review and Measurements of Topping D50 DAC
- Thread starter amirm
- Start date
I think that D50 information can only be confirmed on the PC with Topping USB Audio Device Control Panel.
My D50 also updated the firmware. Revision shows v6.F2.
- Joined
- Jun 10, 2018
- Messages
- 6,246
- Likes
- 9,378
It depends a lot on how it is done. JRiver on windows uses very few CPU cycles. Foobar2000 can use a lot more. I have seen up to 25% on an N3700 Pentium.
serious MPD code contributor here. This is how the trunk version of MPD converts a DSD256 to redbook PCM, without even output to the DAC hardware. it utilize close to 100% of a single core on a Raspberry Pi 3 B.
If you mean "9% CPU while converting DSD to PCM" is for DOP, the following screenshot how it streams native DSD (with my kernel patch to enable native DSD streaming) to a Topping device. notice it actually consume 23%, as you also have to take kernel worker (alsa kernel routine, usb-audio driver) into account, too.
In my testing native DSD saves around 2% CPU utilization compares to DOP. 23% vs 25%. Which means without packaging data to higher bit depths, you can save around 10%.
Raspberry Pi 1 and 2 will be a lot slower than this.
The goal is near 0% CPU utilization, and we're very far from getting there.
23% seems a lot to me. Constant 23% utilization means people who use portable devices (Android Phone with a Topping NX4 DSD for instance, and a lot of phones are slower than Raspberry Pi 3) will suffer from battery drain.
Last edited:
Right. In my testing the software I contributed (MPD and cmus) consumes very few CPU cycles on Mac --- near 0% when play redbook, compared to commercial software such as VOX.app or audirvana, which sometimes consumes 5-10X more.
Not really as algorithms are pretty much the same, but the CPUs are much faster then they used to be in the old days. The rule of the thumb is that every system that is capable of playing HD video shouldn't have any trouble playing HD audio in any scenario of audio conversion.
No! The algorithms are similar, but implementation are widely different. A lot of widely used audio players are written by poor programmers, who don't even known how to do audio programming. If you take a look at a few open source Mac / Linux audio players' source code 2-3 years ago, you'll find erroneously used programming patterns everywhere, such as
- Using mutex/locks in the async audio render functions (all projects uses libao does)
- Use malloc/free in audio render functions (A lot of players do!)
- Use Objective-C method call in audio render functions (Cog.app)
- Does a few heavy work (such as decoding, bit manipulation or channel remapping) in audio render functions.
All of the above patterns are forbidden in Apple's CoreAudio programming guide.
It's not related to hardware performance --- cmus (which previously used libao) and MPD used to have severe hiccups when you play high res files even on latest gen Macs.
Before I jump into working on MPD and cmus's CoreAudio output, none of the open source projects did it correctly. Only until now it's getting a little bit better.
All:
I joined just to ask this question. I just ordered a Topping D50 to pair with a Shiit Magni 3.
In my thinking an amp (at this price range)...is JUST an amp...and for head phones..this range seems like more than enough.
I was thinking all the magic happens on the DAC.....but after reading through the comments on this review it almost seems like a D50 is a waste of money for a magni 3???
I'll be running the setup via Tidal and using a Focal Elex, Fostex TR-00x Ebony and a fewer cheaper units such as the HE4xx, HD6xx, HD59x, Vmoda M100s.
Thanks in advance.
Amazing reviews here, thank you for that also
I joined just to ask this question. I just ordered a Topping D50 to pair with a Shiit Magni 3.
In my thinking an amp (at this price range)...is JUST an amp...and for head phones..this range seems like more than enough.
I was thinking all the magic happens on the DAC.....but after reading through the comments on this review it almost seems like a D50 is a waste of money for a magni 3???
I'll be running the setup via Tidal and using a Focal Elex, Fostex TR-00x Ebony and a fewer cheaper units such as the HE4xx, HD6xx, HD59x, Vmoda M100s.
Thanks in advance.
Amazing reviews here, thank you for that also
The thing I discussed should be common knowledge in CoreAudio programming. See
http://atastypixel.com/blog/four-common-mistakes-in-audio-development/
There are four obvious mistakes talked in that article:
1. Don’t hold locks on the audio thread. Like pthread_mutex_lock or @synchronized.
2. Don’t use Objective-C/Swift on the audio thread. Like [myInstance doAThing] or myInstance.something.
3 Don’t allocate memory on the audio thread. Like malloc(), or new Abcd or [MyClass alloc].
4 Don’t do file or network IO on the audio thread. Like read, write or sendto.
But most, if not all, developers simply do not follow. Examples:
1. VLC. Gigantic render function. It's funny that in the comment it tries to enforce not using locks, wait and io in the renderer, but two lines later you see code saying "lock_lock(p_sys);"
https://github.com/videolan/vlc/blo.../modules/audio_output/coreaudio_common.c#L140
2. libao, the xiph (the org which maintain flac, vorbis) library which virtually all open source player uses, has a complex audio renderer with mutex locking even today:
https://github.com/xiph/libao/blob/master/src/plugins/macosx/ao_macosx.c#L127
3. The Cog.app, which a lot of Mac users use and recommend, not only call objective C functions, but also call stream reader that mallocs/frees.
https://bitbucket.org/mamburu/cog/s...viewer=file-view-default#OutputCoreAudio.m-38
The list just goes on and on! Practically, the performance of those projects are really bad even on my 2017 Macbook Pro --- Cog.app and VLC can barely render 92/24 without hiccups.
It seems the entire industry (including reviewers, developers, users) only concentrates on pretty UI and functionality, without paying attention to code performance and audio playback quality.
In comparasion, see how I implemented the renderer function in cmus and MPD:
https://github.com/cmus/cmus/blob/master/op/coreaudio.c#L268
https://github.com/MusicPlayerDaemon/MPD/blob/master/src/output/plugins/OSXOutputPlugin.cxx#L684
just 2-3 lines of code that just copy data from a lock free ring buffer.
thus, even with 352.8/32 it's still smooth like butter!
There are other good implementations. MPV project's implementation is similar to mine:
https://github.com/mpv-player/mpv/b...b7484f27d033f7a5/audio/out/ao_coreaudio.c#L74
The ao_read_data function is similar to reading the buffer in a lock free way:
https://github.com/mpv-player/mpv/b...89d42bfa3c9162ecef1f84e/audio/out/pull.c#L137
But unfortunately it calls mp_raw_time_us, which is a system call (which blocks until kernel return the back the time).
If you take a look and research how all music players implement their renderer callback in the market, you can safely arrive at the conclusion that most are on par with the design quality of Schiit DACs.
Last edited:
Here's how it looks on my RPI 3 B+ when dff file is being played in DSD Native playback mode. As you can see there is app 9% of CPU overhead when MPD is doing the conversion.
For some reason the DSD Native setting causes the DSD stream to be converted to 352 kbps PCM by MPD. I was told by Volumio developer MPD does the conversion because my DAC (Topping D10) is not recognised as a DSD Native capable device. Is that really so?
When converting DSD to 352 PCM:
When playing without conversion:
For some reason the DSD Native setting causes the DSD stream to be converted to 352 kbps PCM by MPD. I was told by Volumio developer MPD does the conversion because my DAC (Topping D10) is not recognised as a DSD Native capable device. Is that really so?
When converting DSD to 352 PCM:
When playing without conversion:
Last edited:
Volumio developer is right.
In my previous post I was testing DSD256 and see a close to 100% CPU usage when converting to PCM. Thus I can't play DSD512.
You're playing a DSD64 file, which is four times smaller. I did a quick test using a DSD64 file and see close to 19% CPU utilization, compare to your 12%.
Your RPi 3 B+ is a little bit faster than my RPi 3 B
Volumio developer is right.
In my previous post I was testing DSD256 and see a close to 100% CPU usage when converting to PCM. Thus I can't play DSD512.
You're playing a DSD64 file, which is four times smaller. I did a quick test using a DSD64 file and see close to 19% CPU utilization, compare to your 12%.
Your RPi 3 B+ is a little bit faster than my RPi 3 B
Can you please explain how MPD performs a volume control when mixer type is set to "hardware"? I have tried that with my USB bridge (USB to SPDIF) which doesn't have a DAC chip and it works the same as with D10 DAC, so how exactly is it working?
Last edited:
Unless I'm misunderstanding, it's a kernel issue, not MPD's necessarily. See a prior post from @yue where he pushed a patch upstream to get support added for Thresycon devices like the DX7s and D50 (and, I assume, the D10?).
You should be able to force mpd to use dop for the D10 though, no? (That only gets you DSD256, I believe, but it's better than nothing.)
You should be able to force mpd to use dop for the D10 though, no? (That only gets you DSD256, I believe, but it's better than nothing.)
Yes, DOP works but DSD Native doesn't. Actually DOP also doesn't work now as I have set mixer type to "hardware" and for the DSD to work volume has to be set to 100. But I don't care much for DSD anyway, what nterests me more is how exactly a volume control works when mixer type is set to "hardware"?
P.S. D10 can play DSD128 in DoP and DSD256 in Native.
Last edited:
For native DSD to work on D10, you need to patch the kernel so the it can recognize the DAC as a DSD_U32_BE capable device.
I did it and my Topping devices (NX4 DSD and DX7s) work pretty well. I don't have a D10 for testing
I was able to play DSD Native with D10 when i had it connected to my PC via ASIO driver.
DOP works fine with Volumio as long as volume is set to 100. But, as I said, DSD is not really of interest to me, I'm much more interested how exactly volume control works when mixer type is set to "hardware". Does XMOS chip do the volume control?
DOP works fine with Volumio as long as volume is set to 100. But, as I said, DSD is not really of interest to me, I'm much more interested how exactly volume control works when mixer type is set to "hardware". Does XMOS chip do the volume control?
right. XMOS does the PCM volume control. However, Topping firmware does not exposed the volume control correctly.
mixer is exposed in
/proc/asound/(hardware name)/usbmixer.
I don't have a D10. On DX7s I owned (and NX4 DSD, which topping sent me as a debugging device), The following control is exposed.
As you can see, NX4 DSD has two playback volume control. The first one is master and second one is dual channel. This is very strange. Your result volume will be the product of two volumes. (so L = volume1 * volume2 [0] and R = volume1 * volume2[1] ) which is not how volume control in most consumer devices work. Usually only digital audio interfaces work in this way with a Master volume and multiple anologue output/input volume. In addition the volume control name is "NX4 DSD " (hey, why adding extra space in the end?) rather than "PCM". So most, if not all, Linux players cannot correctly adjust the volume of NX4 DSD if you're using the default setup.
To make volume control work in MPD for now you have to define something like:
audio_output {
type "alsa"
device "hw:CARD=DSD" # strange device name.
mixer_device "hw:CARD=DSD"
mixer_control "NX4 DSD " #you cannot omit the last space, because Topping firmware name it in a weird way.
name "NX4 DSD"
# dop "yes" #mandatory if you don't have the kernel patch applied.
mixer_type "hardware"
}
Mac has similar issue.
Last edited:
Volume control works fine on D10 with Volumio when mixer type is set to hardware. My question was actually how XU208 does the volume control? Is it using the 32 bit arithmetics in a same way 32 bit DACs do when doing volume control, as it is described in the document below?
http://www.esstech.com/files/3014/4095/4308/digital-vs-analog-volume-control.pdf
P.S. My RPI has MPD using app 87% of CPU when playing/converting DSD256 dff file.
Similar threads
- Poll
