• 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!

Neutron HiFi DAC V1 Review

Rate this portable DAC & HP Amp:

  • 1. Poor (headless panther)

    Votes: 0 0.0%
  • 2. Not terrible (postman panther)

    Votes: 10 5.6%
  • 3. Fine (happy panther)

    Votes: 67 37.6%
  • 4. Great (golfing panther)

    Votes: 101 56.7%

  • Total voters
    178
Is the EQ feature in this compatible with Apple products?

DAC V1's DSP functionality (EQ, Crossfeed, ...) is platform independent because DSP is executed on DAC's CPU. Therefore you get EQ working with any device - Apple, Linux, Windows, Android, ... any platform which supports USB DACs.
 
Could be some Android OS issue maybe? Most probably, if you are using headset with built-in mic, OS sees that you connected audio input device and tries to listen for a voice command. Input feature did not have changes in latest fw releases, so if you started seeing it recently, then maybe Android OS or voice command component got updated on your Android device and have some issues.
It’s been happening for a long time. I’ve done several fw updates and still happens. NConfig Mic dsp is off. My headphones don’t have a mic. If I have some time I will give it another go.

Btw I find the thd option very interesting. I have several 32 ohm cans and it does change the way they sound likely for the better, at least that’s my subjective impression so far, but I wanted to ask if there is any doc or even better, a tool that can help figure out what thd changes to make for a particular headphone ? For example, the default 32 ohm profile has a diff value on L vs R channel .. is that right ? I tried reading through the neutron doc and even the ess dac doc but I got nowhere …
 
It’s been happening for a long time. I’ve done several fw updates and still happens. NConfig Mic dsp is off. My headphones don’t have a mic. If I have some time I will give it another go.

It is strange, never experienced similar issue with Android devices nor there are similar reports. If DAC V1 detects that inline mic is present it restarts self with Input part of USB descriptor present, otherwise only Output part of USB descriptor is give to the OS. I will inspect the related area again for the misdetection of inline mic presence.

I have several 32 ohm cans and it does change the way they sound likely for the better, at least that’s my subjective impression so far, but I wanted to ask if there is any doc or even better, a tool that can help figure out what thd changes to make for a particular headphone ?

You can check discussion about THD here: https://forum.rme-audio.de/viewtopic.php?id=34868

THD values can be different and it is normal because 2-nd and 3-rd harmonics can be slightly different for R and L channels due to PCB routing and slight differences in analog path (although according to DAC V1's review this difference is miserable). THD coefficients are derived by checking 2nd and 3rd harmonic in real time by measuring output with a high precision ADC, therefore even if difference exist they do not mean that signal became different, on the contrary, the signal on output channels becomes as much equal as possible. Without checking output with ADC it is not possible to set correct THD values, so I advise to use available presets.
 
Without checking output with ADC it is not possible to set correct THD values, so I advise to use available presets.
Just curious: do you adjust H2 & H3 coefficients individually on every V1 you produce, or do you have a set of pre-determined coefficients that you optimized once and apply on every V1?

EDIT: and what HP-equivalent impedance value do you use to optimize the THD comp. coefficients?
 
Last edited:
Just curious: do you adjust H2 & H3 coefficients individually on every V1 you produce, or do you have a set of pre-determined coefficients that you optimized once and apply on every V1?

It does not make sense to do it for every individual device if hw design and components do not change.
 
It does not make sense to do it for every individual device if hw design and components do not change.
Did you determine the optimum THD comp. coefficients with no load, or with a HP-equivalent impedance? Does it make a difference in your experience?
 
It is strange, never experienced similar issue with Android devices nor there are similar reports. If DAC V1 detects that inline mic is present it restarts self with Input part of USB descriptor present, otherwise only Output part of USB descriptor is give to the OS. I will inspect the related area again for the misdetection of inline mic presence.
I think this issue only happens when the neutron music player app is installed on the android device you plug your dac into and has something to do with the mic recording permission.

Normally when I plug any dac in including this one I get a pop up asking me if I want to allow neutron app to take control of the dac. When this one pops up it’s going to work as expected whether I allow it and use the neutron app or not.

Now sometimes and fairly often I don’t get the regular neutron notification but a different one asking me to allow neutron to record audio through the dac. So this is a completely different notification to the one about allowing dac control and I only get one notification or the other, never both. So whenever I get this audio recording notification, it becomes unusable as the voice recog pop ups keep appearing saying different things from cannot understand command to try saying x message to something went wrong and error message and every time one of these pops up, the mic icon is shown on screen as if the mic were being used…

So what I tried was uninstalling the neutron player and installing uapp and I got the same pop up asking if I want to allow uapp to record audio but with uapp it never triggered the voice cmd pop up. Also uapp has a setting in it’s menu about this recording notification specifically called ‘request recording permission’ and when I clicked on it it gave me the proper android pop up to allow the permission and after that I did not have the issue happen again until I reconnected the dac when I got the same pop up again even though I already gave it mic perms. Turns out you need to allow global mic access and with uapp I got a pop to do that the second or third time I plugged in the dac and since then reconnected the dac seems to work as expected… I’ve not tried reinstalling neutron and manually giving it
permission to record audio but if I get a chance I will try it.
 
Last edited:
Did you determine the optimum THD comp. coefficients with no load, or with a HP-equivalent impedance? Does it make a difference in your experience?

Yes, THD was derived with corresponding load, therefore there are 32 and 600 Ohm presets which cover most cases. 600 Ohm preset is generic for headphones with >= 80 Ohm.
 
- Apple sound option in nconfigurator does not get saved in the profile. - fw 51

NConfigurator was updated (for now just Windows and Mac versions) with this bug fixed. Later after completion of some other works will update to 1.7.2 for all platforms, for now it will show up as 1.7.1 (but with changes/fixes):
 
Any chance to support reasonable size convolution on the cpu of the DAC instead of the EQs?
 
@dmitrykos , how are you getting on with the development of the Game Mode 7.1 Virtual Surround Sound? (eg taking the 7.1 audio of games and processing it down to 2CH whilst retaining the spatial effects). This processing doesn't work for all consumers, but Creative SoundblasterX G6 Virtual 7.1 Surround Sound works for me in preserving in front & behind cues most of the time.

EDIT: would this mean that there wouldn't be enough CPU cycles leftover for headphone PEQ if operational at same time? Would there be any latency penalty for Virtual 7.1 Surround, and same question for PEQ? And what is the current latency of your DAC in a gaming environment? (Not that I know what the latency is of my current gaming DAC though, ha!). And are you envisaging having different configurable variables for the surround sound so that it can be finetuned for each individual - a bit like how Creative Soundblaster has the Surround Variable that can be set from 0 to 100?
 
Last edited:
2-300 ms long convolution usually more than enough for most FR correction tasks and if it is full stereo ( 4 convolutions) < 100 ms can do a lot of tricks ( binaural, HRTF, X_Talk cancellation etc). It would make it a very strong competitor for miniDSP, Raspberry boxes and other solutions, just more convenient.
 
2-300 ms long convolution usually more than enough for most FR correction tasks and if it is full stereo ( 4 convolutions) < 100 ms can do a lot of tricks ( binaural, HRTF, X_Talk cancellation etc). It would make it a very strong competitor for miniDSP, Raspberry boxes and other solutions, just more convenient.
Not sure if your response is to mine but for a gaming DAC you for sure want all processing to be done significantly significantly significantly significantly below 100ms which is a massive 0.1 second. Average auditory response time for humans is something like 100-150ms, so in competitive gaming scenario you don't want to be doubling your auditory reaction time just because you're choosing a certain DAC. But anyway, we have to hear from @dmitrykos as to the answer to the latency question I had, but more significantly also the 7.1 virtual surround questions I had.

EDIT: I kind of expect the delay of the 7.1 virtual surround implementation is due to a successful implementation being not a mean (average) task, far from it I suspect. I expect it would take much research & testing.
 
Last edited:
@dmitrykos , how are you getting on with the development of the Game Mode 7.1 Virtual Surround Sound?

It is still in to-do in the queue of tasks but its turn is approaching. One of the main difficulties I foresee is the amount of onboard SRAM because it has to hold buffer for 8 channels and, of course, available CPU time, but we'll see.

@fcserei thank you for clarification, I will add it into to-do for evaluation.
 
1) Apple sound option in nconfigurator does not get saved in the profile. - fw 51
2) IPhone 14, sometimes get lots of pause/play in subsequent and very fast order… used 2 diff cables but disabling touch on the dac seems to have stopped it - fw 51
3) Android 14 sometimes when I conn the dac cortana or whatever google’s voice recog robot is pops up and keeps saying something like it does not understand the command.. I unplug it and reconnect and sometimes it stops doing it, other times I gave up… - fw 50 and several before it, have not tried on fw 51 yet

@HeartByte would you please test all presence of all 3 mentioned issues after updating NConfigurator to the latest 1.7.2 and Firmware to 52. All two were released yesterday.

1) was fixed already for sure.
2) was most probably linked to inline mic detection (it could give false positive) and a very specific combination of host device (iPhone) and headphones, Firmware 52 has new approach towards detection which made it reliable across all devices (fix is confirmed by another user with a similar issue description).
3) although related to Neutron Player, still could be provoked by false positive inline mic detection and the fact that DAC V1 was starting with inline mic enabled by default (and then it was detected as absent), now it starts without Input interface enabled by default and inline mic detection happens after that. I think Android OS will no longer show recording permission request, but of course if your headset does not have inline mic.
 
@HeartByte would you please test all presence of all 3 mentioned issues after updating NConfigurator to the latest 1.7.2 and Firmware to 52. All two were released yesterday.

1) was fixed already for sure.
2) was most probably linked to inline mic detection (it could give false positive) and a very specific combination of host device (iPhone) and headphones, Firmware 52 has new approach towards detection which made it reliable across all devices (fix is confirmed by another user with a similar issue description).
3) although related to Neutron Player, still could be provoked by false positive inline mic detection and the fact that DAC V1 was starting with inline mic enabled by default (and then it was detected as absent), now it starts without Input interface enabled by default and inline mic detection happens after that. I think Android OS will no longer show recording permission request, but of course if your headset does not have inline mic.
I can confirm that the apple sound option now gets saved to profile, as for the mic issue, I have tried plugging it in a couple of times after reinstalling Neutron and it has not asked for mic permission yet and have not had any issues so this looks to have been fixed as well, thanks Dmitry . Also could you share an ETA on the Android NConfigurator app, please ? I am really looking forward to that ! Thanks
 
I can confirm that the apple sound option now gets saved to profile, as for the mic issue

The issue was somehow a very hardware dependent and not reproducible in the development environment with all sample hardware available, great that we nailed this bug! Thank you for reporting, it really helped.

ETA on the Android NConfigurator app

NConfigurator mobile app you meant I guess. There is no ETA but development is ongoing and hopefully will get working initial version asap. The plan is to introduce basic functionality which then will be gradually advanced to match functionality of the PC version.
 
A new option was introduced in Firmware 53 and configurable with NConfigurator 1.7.3 - High-Performance mode:

AdvancedHighPerformance.png

By default DAC V1 is operating in a low-power mode and if there is no streaming on USB bus for 10 seconds it falls into Idle mode which means - DAC chip and its peripherals are off. As a result if new audio stream is opened (user pressed Play in a music player for example) it takes some time for DAC V1 to start audio output thus if audio/music data had some useful content on a very first second then it could be partially truncated/silenced. New switch will make DAC V1 highly ready for a new audio data with no to negligible warm-up time.

This functionality was requested on Neutron Forum, so hopefully this option will be useful for other DAC V1 users. For generic use I advise to not activate High-Performance mode, especially if you connect DAC V1 to a battery-powered host because High-Performance mode means - DAC and its amp never sleep and obviously consume power, but for usage with PC when hearing short periodic (with periodicity beyond 10 seconds) sounds is required it can be useful.
 
Possibility to customize Oversampling Filter of DAC V1 is finally implemented in the latest Firmware 54 and NConfigurator 1.7.4. Besides user-defined filter (DAC tab Filter USER_DEFINED) NConfigurator provides 4 new additional linear-phase filters (NEUTRON_LINEAR_XXX, TUBE version simulates frequency response of the generic Tube amp):

NewFilterTypes.png

With your own Oversampling Filter you get DAC V1 with a unique sound image. The design steps/user manual is provided on Neutron forum in Custom Oversampling Filter for DAC V1 post:

NConfigurator will not support the design of the filter, instead, you can use MATLAB or Octave to do complex calculations and then load resulted filter via GUI (Oversampling Filter tab) to DAC V1:

OversamplingFilterTab.png

As a side note: DAC chip's built-in filter FAST_ROLLOFF_HYBRID is a minimum-phase filter composed of minimum-phase 1st stage + linear phase 2nd stage, all other filters are linear-phase.

I hope this new functionality will make interaction with the DAC V1 even more interesting and exciting :)
 
Back
Top Bottom