Neutron Hifi DAC V1

[dmitrykos]

Will there be a preorder promotion?

If you order device + leather case (or USB cable) + USB cable (I advise to get USB-C -> USB Micro-B for supplying external power if such necessity happens) then you get free delivery.

 

[dmitrykos]

(Maybe limiting PEQ to 10 band on each channel (left & right driver), and whilst limiting to 48kHz might give enough overhead for virtual surround processing, as an idea.)
(Maybe it would be useful to have a configuration setting for putting the DAC into 5.1 mode or 7.1 mode, as some games might not do 7.1 for instance, but I'd say 7.1 is the main one.)

@Robbo99999 thank you for your comments!

DAC V1's Firmware 42 was just released (support for Surround (Ambiophonics R.A.C.E. + limit of output frequency via NConfigurator), so will investigate whether Gaming mode/Virtual Surround can be possible for DAC V1 - I mean streight-forward downmixing will perfectly be possible as well as exposing DAC V1 as 5.1 or 7.1 device but we need to preserve positional clues or at least approach to the perception of the position and it means some DSP for rear + side channels. Output frequency and availability of DSP can be revised depending on known CPU consumption of course.

 

[Robbo99999]

@Robbo99999 thank you for your comments!

DAC V1's Firmware 42 was just released (support for Surround (Ambiophonics R.A.C.E. + limit of output frequency via NConfigurator), so will investigate whether Gaming mode/Virtual Surround can be possible for DAC V1 - I mean streight-forward downmixing will perfectly be possible as well as exposing DAC V1 as 5.1 or 7.1 device but we need to preserve positional clues or at least approach to the perception of the position and it means some DSP for rear + side channels. Output frequency and availability of DSP can be revised depending on known CPU consumption of course.

Yes, and to clarify for others reading your comment, when you say "CPU consumption" you mean the CPU of the DAC, just I briefly misunderstood that to mean CPU of the PC/laptop/etc at first, but yes of course you mean the CPU actually built into your DAC. Well, it'll be very interesting to hear how you get on with that, and indeed the CPU within your DAC will have to do that DSP for the rear & side channels - if it has the overhead to do it is one thing, & then the other side of the coin is if it can be a good virtual surround sound implementation, which will depend on what decisions you make re the DSP that you implement (and perhaps you might be limited in that with the hardware too but I'm not sure). I'd like to find out how you get on with it though!

 

[LoFiAudiophile]

@dmitrykos Congratulation on the launch. Neutron player is legendary and so I’m probably going to buy one anyway my collection of DACs

I am curious if there are any plans for an iOS version of NConfigurator?

 

[dmitrykos]

I am curious if there are any plans for an iOS version of NConfigurator?

Unfortunately Apple has not enabled direct access to USB devices, here is their reply on question related to "iOS USB device access" on Apple Developer forums. That is why there is no Direct USB Access option on iOS for Neutron Player, unlike on Android or Win32. After implementation of external USB drives support probably it is time for Apple to consider relaxing this limitation too. Support for external USB storage on iOS was largely motivated by iOS users, so maybe it make sense to push Apple to do this move from the side of audio community by requesting this feature (direct access to USB devices, macOS has necessary API for that) from Apple via technical support or Apple forums.

 

[LoFiAudiophile]

Unfortunately Apple has not enabled direct access to USB devices, here is their reply on question related to "iOS USB device access" on Apple Developer forums. That is why there is no Direct USB Access option on iOS for Neutron Player, unlike on Android or Win32. After implementation of external USB drives support probably it is time for Apple to consider relaxing this limitation too. Support for external USB storage on iOS was largely motivated by iOS users, so maybe it make sense to push Apple to do this move from the side of audio community by requesting this feature (direct access to USB devices, macOS has necessary API for that) from Apple via technical support or Apple forums.

Thanks Dmitry, I was afraid so. It is indeed frustrating that simple stuff like talking to USB devices is nearly impossible on iOS.

If you’re so inclined, I do have a couple of ideas that you may like to ponder on. Of course I have no expectations given you have probably a million better things to do

1. USB devices can advertise multiple endpoints (you probably already are familiar with this). Since all we need is a low speed interface for control and configuration messages, you might like to see if Neutron DAC can also advertise a USB HID device endpoint that the configuration app can talk to as there is a (limited) way to have bidirectional communication with HID devices on iOS.

2. This one is a little bit crazier but given you’re a DSP wizard it may interest you Your DAC is capable of accepting and decoding signals right upto 384kHZ (768?). There’s absolutely no music that way up but even a 16kHZ band is enough to implement an old fashioned acoustic modem Of course getting signal the other way is harder but I wonder if a fake “microphone” for the other direction could just do the trick.

Actually, uh I don’t know why I wrote about audio modem, the signal is all digital and the device is 32bit/24bit capable, which allows fully digital bidirectional (assuming a fake mic channel) communication with a suitable app. You could even implement a “signature pulse” to let the device know that it’s a configuration app talking to it and not the music player.

Love this device anyway. Just some ideas.

 

[CedarX]

advertise a USB HID device endpoint

I don’t think iOS enables HID device access either…

2. This one is a little bit crazier

That’s an interesting idea… It would mean developing a proprietary communication protocol encoded in the, say 192-384 kHz band, and using the mic. as return/response handshake.

A third option, involving HW, is to add an inexpensive BT LE controller. That’s what @IVX has done with its PowerDAC: it’s a (large) USB dongle that works with both iOS and Android phones (+ PC, Mac, Linux), but the PEQ, compressor, loudness etc. parameters are set through an iOS / Android app via BT.

 

[dmitrykos]

if Neutron DAC can also advertise a USB HID device endpoint that the configuration app can talk to as there is a (limited) way to have bidirectional communication with HID devices on iOS

DAC V1 is exposing several HID endpoints: for media controls (to handle own media commands, which you invoke by tapping top/bottom or side of device - DAC V1 has accelerometer inside) and for NConfigurator communication needs. But iOS does not support communication over HID endpoint either, e.g. USBDriverKit is for macOS only). The reason of this is, to my view, in Apple's MFi which is slowly deprecating for USB devices since the moment when Apple decided to support USB devices directly by replacing Lightning with USB-C in the latest models. Maybe with time being Apple will add support for USBDriverKit in iOS - it would be a natural move.

2. This one is a little bit crazier but given you’re a DSP wizard it may interest you

Not really crazy. I was considering it too - communication via PCM channel. Neutron has Input (it supports in-line mic) and Output (playback device) functionality, so theoretically there is possibility to create 2 way communication over PCM channels with special data packets which can be detected by firmware (just like DSD is detected in DoP). The downside of this - added complexity in firmware, additional real-time detection for such special packets, OS audio layer must be transparent for Input and Output data (possible to achieve on iOS). So in general it can be possible but looks more like a workaround. In any case I keep it on radar as possible solution.

That’s an interesting idea… It would mean developing a proprietary communication protocol encoded in the say 192-384 kHZ band and using the mic. as return/response handshake.

Too complicated. We already pass DSD over PCM (DoP), in the same way any other encoded data can be passed by using different header signature.

A third option, involving HW, is to add an inexpensive BT LE controller.

Yes, was also considered. There are really small BLE ICs, like 4x4mm with 3mA consumption and built-in antenna (I do not know if there are smaller ICs). There were considerations about interference of Bluetooth signal with audio circuit (obviously interference would happen, so IC must normally be in deep sleep) but it could be solved by some special activation sequence of media command, for example 3 double taps on top/bottom. DAC V1 is very small device, so adding BLE IC would take more PCB space (DAC V1 has 2 PCBs by the way built as tower in order to use all the space available inside enclosure), would add more complexity. Therefore this approach is reserved for the future. But, OSes really must support communication via HID, including iOS, then such hw workaround would not be necessary.

 

[mc.god]

DAC V1 is very small device, so adding BLE IC would take more PCB space (DAC V1 has 2 PCBs by the way built as tower in order to use all the space available inside enclosure), would add more complexity. Therefore this approach is reserved for the future. But, OSes really must support communication via HID, including iOS, then such hw workaround would not be necessary.

I'm totally out of knowledge here so probably saying nonsense, but just yesterday I noticed another dongle using this Arm M4 BT interface for some functionality (that dongle doesn't even has BT functions), so since you are already using this type of architecture couldn't something like this be considered?

 

[LoFiAudiophile]

. The downside of this - added complexity in firmware, additional real-time detection for such special packets, OS audio layer must be transparent for Input and Output data (possible to achieve on iOS). So in general it can be possible but looks more like a workaround. In any case I keep it on radar as possible solution.

but it could be solved by some special activation sequence of media command, for example 3 double taps on top/bottom.

I agree, an always on detection will be way too complicated and IMHO unnecessary too after I realized from your comment that the device has accelerometer and tap sensing - that’s pretty damn cool.

Given there is no BTLE HW onboard there is really no way currently to run a configuration app at all.

A compromise could be to have the user put the device in “configuration mode” by tapping it. In configuration mode there can’t be any music playing whatsoever, so that the device side complexity could be reduced to a minimum and the configuration app can use the PCM channels as it may wish because there will be no expectation of music playback at all (playback must be muted anyway to prevent arbitrary noise due to configuration messages).

The nice thing about this is that this way a native app is technically not needed at all, and even a web app would do

 

[dmitrykos]

@mc.god Airoha AB1565 looks interesting for future designs - small package, dedicated DSP core, BT, - something to consider... I will take a note of this producer. The downside of smaller producers like Airoha is availability of hardware and undefined product life time - too agile, too risky for long lasting hw designs. With NXP MCUs you have a guarantee from NXP that selected MCU has some defined lifetime and it is extremely important for long-term projects like Neutron HiFi DAC V1 (even if such NXP MCU is phased out it is possible to get it from stock distributors). Although both MCUs are Cortex-M4 in practice these are absolutely different devices with own specific peripherals, SDK API, behavior, performance metrics and etc. So it is not easy to replace one with another.

A compromise could be to have the user put the device in “configuration mode” by tapping it. In configuration mode there can’t be any music playing whatsoever

I think it worth trying. Currently NConfigurator is in active development phase, once stabilized it will go into Neutron Player and then such functionality (communication via PCM I/O streams) will be very useful.

 

[CedarX]

@mc.god Airoha AB1565 looks interesting for future designs - small package, dedicated DSP core, BT, - something to consider... I will take a note of this producer. The downside of smaller producers like Airoha is availability of hardware and undefined product life time - too agile, too risky for long lasting hw designs. With NXP MCUs you have a guarantee from NXP that selected MCU has some defined lifetime and it is extremely important for long-term projects like Neutron HiFi DAC V1 (even if such NXP MCU is phased out it is possible to find it from stock distributors). Although both MCUs are Cortex-M4 in practice these are absolutely different devices with own specific peripherals, SDK API, behavior, performance metrics and etc. So it is not easy to replace one with another.



I think it worth trying. Currently NConfigurator is in active development phase, once stabilized it will go into Neutron Player and then such functionality (communication via PCM I/O streams) will be very useful.

Off topic, I know… The AB1565xx (not sure which variant) has been used by HiBy in their now discontinued WH2 TWS. There were 2 versions (I have both ), a single DD and a dual BA. The dual BA had a very interesting adjustable active crossover—a way to explore driver IMD and other things.

Just to confirm that the AB1565 onboard DSP has some interesting capabilities.

 

[dmitrykos]

@CedarX Airoha seems to be not that friendly to developers, they have not replied up to now... So removing them from radar, and with this they seem to confirm the risky profile of small chip producers.

 

[CedarX]

@CedarX Airoha seems to be not that friendly to developers, they have not replied up to now... So removing them from radar, and with this they seem to confirm the risky profile of small chip producers.

This is the kind of “perspective” only a manufacturer like you can give. Thanks for sharing!
We, on the user side, don’t always understand why OEM X chose to use DAC Y and not the “so much better” chip Z… We don’t know what it is to work with suppliers like Qualcomm (even to get a simple datasheet, you need to have a multi-$$$$$ established business), or the laughable errors repository documents from ESS (making that up from what I’ve read here and there ).

I’m glad to see Neutron openness to share what it is they are doing, and why. Hope ASR users feedback and comments will be valuable: I think we are all after the same thing in the end—the best audio stuff!

 

[Robbo99999]

@dmitrykos , any news re any testing you've done re 7.1 virtual surround for gaming? Only been a couple of weeks since we last discussed, but you seem to move quickly!

 

[dmitrykos]

@dmitrykos , any news re any testing you've done re 7.1 virtual surround for gaming? Only been a couple of weeks since we last discussed, but you seem to move quickly!

Not yet approached but this issue stays on the top of the task queue. Will update on the progress once complete tests/investigation on this question.

We, on the user side, don’t always understand why OEM X chose to use DAC Y and not the “so much better” chip Z…

Yes, component selection is very important question, especially if development progress is thorough and long-lasting due to tests, corrections of hw design and etc. Therefore, it is normally not possible to select complex component (like DAC chip, or especially MCU) and immediately use it for the production device. As to MCU, like NXP, STM, Airoha, ... every MCU producer offers own API and that implies dependence of the firmware code on that API. In case of MCU, to my opinion, it is better to stick to a general-purpose MCU with good technical documentation and support (NXP offers developer support as well as community-based via the forum, the same is for STM, Airoha demonstrated expected for small silicone producers negative approach in this respect) and then build device on top of that. Such approach creates a reliable foundation which can be reused for different device models.

 

[dmitrykos]

As long as Neutron HiFi Isolator V1 was discussed in this thread, I would like to briefly point to its dedicated new forum thread for the continued discussion about it. Isolator V1 was just released (got first batch in the online store), so if you are interested to know more details, or have questions, please do so in that new thread - I will be glad to participate and clarify.

 

[LoFiAudiophile]

@dmitrykos Are there any plans to open source the NConfigurator App, or at least to document the protocol? I am loving the little device - it’s beautiful and its superb pair for my headphones, but the application to configure EQ is, pardon my expression, clunky!

I will be happy to hack away at it or make a better one but I don’t feel like reverse engineering the protocol.

 

[dmitrykos]

@LoFiAudiophile NConfigurator supports loading and saving of EQ presets, so if you develop a better tool for configuring PEQ it could save EQ preset into a file which could further be loaded by NConfigurator and uploaded to DAC V1. NConfigurator tool could also be updated to operate as console-only app, so your tool could invoke NConfigurator and upload updated PEQ filters to DAC V1 via it. If you have intention to move towards this direction, please let me know.

 

[LoFiAudiophile]

@dmitrykos if there’s no plan to open source the configurator then I’ll say that a command line version would be acceptable.

Your comment got me thinking. I wondered why you’d not like to open source the software support for a fairly expensive device. I think I get that NConfigurator is probably built on the same framework that Neutron player is and this it will be a significant effort to open source the configuration app.

If so, you might consider just publishing a README for USB configuration interface or even just an open command line interface.