JDS Labs Element IV DAC & HP Amp with EQ Review

[johny_2000]

Some conclusions:
- potential customers complain about an outdated power supply;
- potential customers complain about a web application for managing device settings that requires registration.

I think this is a good ground for JDS Labs to work on.

 

[Rednaxela]

I understand the hardware limitations preventing embedded implementation, [...]

Sorry if it has been mentioned but what is this hardware blocker?

Let's not forget that Sony could offer it for three bands using just a 21 character display and 1989 silicon. I'd have to check the manual how many rotary knobs it required but it can't have been more than two and it's certainly feasible with one. Same for push buttons - one or two, but one should be feasible.

(Source)

To me it looks more like a software development economics decision rather than a hardware limitation. Happy to stand corrected though.

 

[unpluggged]

To me it looks more like a software development economics decision rather than a hardware limitation. Happy to stand corrected though.

They say there are plenty of spare hardware resources left

And besides, the device does not care how the control app is implemented, as a web app or a native one. It runs in a browser in the end, and the browser is a native app.

 

[Ajax]

Hi Amir,

Your own measurements, plus personal listening tests using a demanding headphone together with 93% of members voting "fine or great", suggests you have uncovered another exceptional product at a reasonable price.

Pls never underestimate your contibution to the audio industry or the appreiation many of us have for your reviews. I have learnt so much from your work.

All the best Ajax

Edit: correct typos

 

[adc]

The more I think about the "Core" concept, the more disappointed I am.

1. When you're relying on a function that two of the three dominant browsers have apparently agreed is not safe, isn't that a clue that maybe you shouldn't be doing what you're doing?
2. What happens when Chromium finally agrees that it's a bad idea to allow direct USB access and also pulls the feature? Now your expensive Element IV is instantly obsolete, unless you want people to use outdated browsers to operate it.
3. In my own use case, my DACs hang off headless Raspberry Pis running MPD and MyMPD. Even if a native app for Windows or Mac were available, I'd have to go to some trouble to temporarily connect it to a desktop computer to program it. Not exactly convenient for my bedside music player.
4. The point has been made in this thread that if you're hanging this off a desktop PC, you probably already have software EQ available, making this feature not all that important. It _is_ important for headless operation, as in my case, which is why I snapped up the Element III last year - but it would be a real pain to access in the Element IV.

I was briefly excited when I saw that the IV had a wide-range PEQ, but now I'm bummed about the implementation details, and will stick with my Element III (and Atom+, and my one remaining Modi/Magni stack).

 

[unpluggged]

I was briefly excited when I saw that the IV had a wide-range PEQ

Not for optical input.

 

[somebodyelse]

Not that it makes much difference… but is the webapp interface to the XMOS XU316 actually based on Web_Serial API or a combination of WebUSB and WebHID APIs?
FiiO has a very similar webapp for their PEQ-enabled portable devices, based on the two later APIs.

The JDS blog post says it uses a virtual serial port, and that Firefox needs the 'WebSerial For Firefox' plugin. Visit https://core.jdslabs.com/ in Firefox and you will be pointed to that plugin too. The plugin makes no claim about adding WebUSB or WebHID, so it doesn't seem likely it's using those.

 

[CedarX]

The JDS blog post says it uses a virtual serial port, and that Firefox needs the 'WebSerial For Firefox' plugin. Visit https://core.jdslabs.com/ in Firefox and you will be pointed to that plugin too. The plugin makes no claim about adding WebUSB or WebHID, so it doesn't seem likely it's using those.

Thanks for the clarification. These APIs indeed open potential security holes: they don’t know where the code communicated by the serial/USB device is coming from (it may have been tampered).
Now the question is: are the alternatives any better?

Topping uses a proprietary Windows software for the D50-III settings and PEQ (side note: the D50-III PEQ is also XU316-based like Element-IV). Is this safer?

RME integrates an on-board UI/interface on some (all? I don’t know their products very well) their PEQ-enabled DACs. How much of that contributes to their higher price point? It certainly looks safer, but is it easier to use and maintain (fw updates)?

I *thought* that a webapp could be designed to be locally installable, not requiring an online, live, connection. This may not be the current path selected by JDSlabs, but could it be an acceptable tradeoff?
Or should JDSLabs embedd a local, mirrored, webserver (ESP32, Raspberry?) into the future Element V? Is it really safer?

EDIT: forgot to mention Qudelix. Is their Chrome extension solution fundamentally better and safer than webapp?

 

[johny_2000]

RME integrates an on-board UI/interface on some (all? I don’t know their products very well) their PEQ-enabled DACs. How much of that contributes to their higher price point? It certainly looks safer, but is it easier to use and maintain (fw updates)?

RME has a built-in interface (with rotary encoders and a full-color screen) and a Win/Mac/iOS app to control all the functions of the device. This greatly improves the usability of the devices.

 

[somebodyelse]

Thanks for the clarification. These APIs indeed open potential security holes: they don’t know where the code communicated by the serial/USB device is coming from (it may have been tampered).
Now the question is: are the alternatives any better?

Topping uses a proprietary Windows software for the D50-III settings and PEQ (side note: the D50-III PEQ is also XU316-based like Element-IV). Is this safer?

RME integrates an on-board UI/interface on some (all? I don’t know their products very well) their PEQ-enabled DACs. How much of that contributes to their higher price point? It certainly looks safer, but is it easier to use and maintain (fw updates)?

I *thought* that a webapp could be designed to be locally installable, not requiring an online, live, connection. This may not be the current path selected by JDSlabs, but could it be an acceptable tradeoff?
Or should JDSLabs embedd a local, mirrored, webserver (ESP32, Raspberry?) into the future Element V? Is it really safer?

EDIT: forgot to mention Qudelix. Is their Chrome extension solution fundamentally better and safer than webapp?

I'd say that's going well off topic. I don't think the JDS approach is unreasonable, and I don't think there's an approach that will please everyone. My preference is for manufacturers to publicly document their API. That lets people with different needs implement something that meets those needs, as well as covering the long term support issue. Parks Audio do this for the Waxwing's bluetooth interface, so writing a desktop app is possible for those who don't want to use a phone app. MOTU document the network control for their AVB line, but not for the Ultralite Mk5 which uses an Electron based app. That has at least allowed people to extract the content and host it locally for browser control on platforms not supported by MOTU. Neumann don't advertise the fact, but their DSP speakers use a protocol Sennheiser have published. As a result we have khtool which works on platforms Neumann don't support.

@jseaber any chance the serial API will be publicly documented?

 

[barneycaudill]

The more I think about the "Core" concept, the more disappointed I am.

1. When you're relying on a function that two of the three dominant browsers have apparently agreed is not safe, isn't that a clue that maybe you shouldn't be doing what you're doing?
2. What happens when Chromium finally agrees that it's a bad idea to allow direct USB access and also pulls the feature? Now your expensive Element IV is instantly obsolete, unless you want people to use outdated browsers to operate it.
3. In my own use case, my DACs hang off headless Raspberry Pis running MPD and MyMPD. Even if a native app for Windows or Mac were available, I'd have to go to some trouble to temporarily connect it to a desktop computer to program it. Not exactly convenient for my bedside music player.
4. The point has been made in this thread that if you're hanging this off a desktop PC, you probably already have software EQ available, making this feature not all that important. It _is_ important for headless operation, as in my case, which is why I snapped up the Element III last year - but it would be a real pain to access in the Element IV.

I was briefly excited when I saw that the IV had a wide-range PEQ, but now I'm bummed about the implementation details, and will stick with my Element III (and Atom+, and my one remaining Modi/Magni stack).

First of all, this amp/DAC doesn't "require internet connectivity", I have no clue where you got that idea from the literature. Second, I don't see how this is a security concern, as you're passing a very specific set of data back and forth to the device over web serial. It's not root access to the device. I hope you realize this is a device that works like any other combo unit on the market, but a very clever feature set is available to those who want to use it, and are competent enough. Don't like it? Fine, use it like any other product. The option being there is enough for me.

 

[jseaber]

I'd say that's going well off topic. I don't think the JDS approach is unreasonable, and I don't think there's an approach that will please everyone. My preference is for manufacturers to publicly document their API. That lets people with different needs implement something that meets those needs, as well as covering the long term support issue. Parks Audio do this for the Waxwing's bluetooth interface, so writing a desktop app is possible for those who don't want to use a phone app. MOTU document the network control for their AVB line, but not for the Ultralite Mk5 which uses an Electron based app. That has at least allowed people to extract the content and host it locally for browser control on platforms not supported by MOTU. Neumann don't advertise the fact, but their DSP speakers use a protocol Sennheiser have published. As a result we have khtool which works on platforms Neumann don't support.

@jseaber any chance the serial API will be publicly documented?

Yes, happy to share the API! Attached is the relevant section from internal documentation (uploaded here as a .txt file, change to .md for better formatting). This information is enough for anyone to build their own app, or simply communicate through the serial port.

Would you prefer to see Core released as an opensource project?

Feel free to PM or email me with any technical questions. Just a heads-up, I have thread notifications turned off this time of year due to other obligations.

FWIW, demand for Element IV has far exceeded our expectations. We sized the first batch to last 8 weeks based on historical trends, and it's nearly sold out in less than a quarter of that time. Retailers are already backlogged into 2025.

 

[TurtlePaul]

Opinions may differ, I think that setting a 10-band PEQ on a rotary encoder with a small screen would be one of the seven rings of hell. I get why JDS goes with a USB approach. As they update the software, I hope they support import from REW .txt filter files.

 

[jseaber]

Yes I was wondering about this as well. I wonder how it would fare without the isolator? Would the issues be audible or just measurable? I expect it would not be audible.

Just measurable.

Here's SINAD with Element IV at high gain, connected directly to my Dell monitor using the bundled cable without Synapse:

With Synapse:

Here's the PM I sent to Amir:

Looking through your notes from the 2022 Element III, you cited difficulty replicating my measurements due to noise or grounding. Thus, I will include Synapse to ensure repeatability. Even without Synapse, I see 118 dB SINAD at maximum volume (10VRMS). Noise may be slightly higher without Synapse. We have a 3-phase solar array on our roof which injects noise into all measurements, so our outlets are by no means clean!

Let me know if you have any questions.

 

[adc]

I don't see how this is a security concern, as you're passing a very specific set of data back and forth to the device over web serial. It's not root access to the device.

I doubt anyone wants to turn this thread into an expose of how software and website exploits work, or why this architecture represents a dramatic (and in my opinion, unnecessary) expansion of the attack surface of an otherwise low-risk USB device. Not everyone cares about such things; the evidence and resulting breaches are in the media nearly every day lately.

First of all, this amp/DAC doesn't "require internet connectivity", I have no clue where you got that idea from the literature.

C'mon, that's just trolling. Internet connectivity is a requirement (for now anyway) in order to use one of this device's most unique features.

 

[gvl]

Glad to see PEQ is making its way into more affordable offerings with great performance to complement. That said, what I really want is the ability to PEQ Qobuz/Spotify on iPhone, but there seem to be some conspiracy to keep this feature out.

 

[adc]

Opinions may differ, I think that setting a 10-band PEQ on a rotary encoder with a small screen would be one of the seven rings of hell.

I'd be ok with it if it's one-time effort, and I could store and recall profiles on the DAC itself. That probably bumps into those hardware limitations, though.

 

[CedarX]

Glad to see PEQ is making its way into more affordable offerings with great performance to complement. That said, what I really want is the ability to PEQ Qobuz/Spotify on iPhone, but there seem to be some conspiracy to keep this feature out.

If you like the HW-based PEQ of Element-IV, there are several HW-based PEQ dongles that would work with an iPhone.

 

[barneycaudill]

C'mon, that's just trolling. Internet connectivity is a requirement (for now anyway) in order to use one of this device's most unique features.

When I read "I love JDS, and I own and love an Element III Mk2 and an Atom+, but no way am I interested in an amplifier which requires internet connectivity for basic functionality. That's just nutty", that sounded to me like there's an assumption the device is entirely useless unless connected to internet. That's my misunderstanding of your original comment.

 

[pablolie]

The more I think about the "Core" concept, the more disappointed I am.

1. When you're relying on a function that two of the three dominant browsers have apparently agreed is not safe, isn't that a clue that maybe you shouldn't be doing what you're doing?

I am curious about what the security issue is? Polling a remote web server is the whole point of the World Wide Web. If that's a big worry, toss away all your devices that access the Internet. Or are you worried someone out there steals your precious PEQ presets from the JDS server? I see how it may be inconvenient for several use cases, but I don't see a genuine security flaw in the concept.

1. The point has been made in this thread that if you're hanging this off a desktop PC, you probably already have software EQ available, making this feature not all that important. It _is_ important for headless operation, as in my case, which is why I snapped up the Element III last year - but it would be a real pain to access in the Element IV.

If you already have software EQ, it sould seem to me you are not a target customer for the Element 4... I'd save some $ and buy a used Element 3.