DSD only using DSC 1,2 or 3?

[EuroDriver]

Or run something small for Windows-based NAA, like MinnowMAX and then run something bigger for player(s) and processing.

 

A year ago, we were big fans of NAA, but stopped using it as we could get as good or even better performance from a one piece solution when we gradually got the SSD noise and motherboard noise under control. Converting everything to DSD512 makes getting good SQ from a NAA solution even more challenging. On paper it should work, but from our limited experience with NAA, we feel that the time and effort needed to have a NAA work well at DSD512 is better spent on a one PC solution

 

In a similar vein, we have stopped using / experimenting with JPlay 2 computer solutions. Turns out that NIC's have there own sound signatures too :-(

 

This has severely dampened our previous enthusiasm for Ethernet solutions

 

I2S has great promise on paper, as our friends at Pink Faun are championing, but it cannot handle DSD512

 

Pick your poison data channel to the DA converter, for us it's USB Windows ASIO. The penalty that we have had to pay for this choice has been the hundreds of hours building a Win 10 OS that strips out nearly all of the stuff we don't need, and behaves almost like a Linux variant with a significantly reduced RAM foot print and thread count, but boy are we enjoying the music :-)

[jabbr]

A year ago, we were big fans of NAA, but stopped using it as we could get as good or even better performance from a one piece solution when we gradually got the SSD noise and motherboard noise under control. Converting everything to DSD512 makes getting good SQ from a NAA solution even more challenging. On paper it should work, but from our limited experience with NAA, we feel that the time and effort needed to have a NAA work well at DSD512 is better spent on a one PC solution

 

In a similar vein, we have stopped using / experimenting with JPlay 2 computer solutions. Turns out that NIC's have there own sound signatures too :-(

 

This has severely dampened our previous enthusiasm for Ethernet solutions

 

Don't give up on Ethernet!

 

Firstly, I have no problem using NAA at DSD512. My NAA is a measly ASRock q1900m -- tricked out, with shielding, mu-metal over the memory, reclocked, LPS and with PCIe USB and an Intel x520 NIC -- that said, no problem with DSD512 -- doesn't break a sweat at in terms of CPU cycles.

 

The other trick is that the NAA is entirely diskless, no SATA anywhere, as it boots over iSCSI and so Ubuntu is loaded into RAM. It has a fiberoptic cable in, an LPS power in and a USB out. I think the Intel x520 beats any copper Ethernet interface hands down, and there are other fiberoptic NICs, but these cards are already fairly well optimized for phase noise, albeit in the Ghz range where the eye pattern plots are done. For lower frequency phase, specialized drivers/cores may help.

 

IMNSHO the weakest link is USB which remains peskily susceptible to cables and requires an endless stream of widgets to achieve good SQ.

 

I2S has great promise on paper, as our friends at Pink Faun are championing, but it cannot handle DSD512

 

Yeah, direct DSD is the way to go. If they were to properly implement DSD on their card -- which I assume has an FPGA to communicate with the PCIe bus, they should be able to handle direct DSD2048 over LVDS without a sweat. Direct DSD is essentially a simple SPI connection with a BCLK, and two data lines RDSD and LDSD. So their board could FIFO from the CPU and clock the data out... hard to get simpler than that ... Oh, they'd actually have to write an IP module, rather than use prepackaged

 

Sorry, don't know those guys but have to call this as I see it :shrug:

 

Pick your poison data channel to the DA converter, for us it's USB Windows ASIO. The penalty that we have had to pay for this choice has been the hundreds of hours building a Win 10 OS that strips out nearly all of the stuff we don't need, and behaves almost like a Linux variant with a significantly reduced RAM foot print and thread count, but boy are we enjoying the music :-)

 

I agree that in the current state of affairs, USB is the current best choice, and you are taking the best current approach.

[YashN]

Larry, the limitation for Mac OS X is just that it only supports DSD via DoP. So the overhead for framing means that DACs which support DSD256 can run at just 128 via DoP. So for a DAC that supports DSD512, OS X will do DSD256 via DoP.

 

 

Not totally true: true if you are considering driverless, default operation.

 

However, if the manufacturer writes and supplies a driver or firmware update, you can have your full DSD256 via DoP for your DSD256 DAC.

 

e.g. With Mac OS X and the iFi iDSD Nano, I was behind the capability with Windows in terms of DSD rates for a good while. Recently, the good folks at AMR/iFi provided us Mac owners with a firmware update (and driver?) for free so that we now can enjoy DSD256 via DoP on Mac OS X!

[YashN]

IMNSHO the weakest link is USB which remains peskily susceptible to cables and requires an endless stream of widgets to achieve good SQ.

 

In reality IMO, there are a couple of weak links:

 

1. Noise profiles when using a packetised protocol (not restricted to USB). DSD doesn't really need to be sent in packets, it should be just output on a pin ideally.

 

2. Signal Integrity and RFI/EMI issues when the transportation from point A to point B nearer the DAC is made in the analogue domain (as is the case for USB) - pulses of light for the win!

[YashN]

I never found it clear how Lampizator does DSD conversion. Their website says "THE LAMPIZATOR DSD DAC HAS USB PORT BUILT IN, SOLID STATE DIGITAL FILTER, PASSIVE DISCRETE ANALOG FILTER AND ACTIVE DISCRETE TUBE

 

It is also not likely a no-dac approach (which I understand as being just simple low pass filtering). All of this is of course of little importance and more a matter of curiosity as apparently their analog implementation is superb and their DACs sounds great.

 

Lukasz uses Tube filters in his chip-less DSD DACs and perhaps some radio technique (I'm not sure he uses both in his latest but one prototype did).

 

There are other Lampi DACs which are not Chip-less.

[jabbr]

In reality IMO, there are a couple of weak links:

 

1. Noise profiles when using a packetised protocol (not restricted to USB). DSD doesn't really need to be sent in packets, it should be just output on a pin ideally.

 

2. Signal Integrity and RFI/EMI issues when the transportation from point A to point B nearer the DAC is made in the analogue domain (as is the case for USB) - pulses of light for the win!

 

+1

 

When we are referring to DSD here we mean a direct, nonpacketized, protocol. 3 lines: clock, right, left

[jabbr]

Lukasz uses Tube filters in his chip-less DSD DACs and perhaps some radio technique (I'm not sure he uses both in his latest but one prototype did).

 

 

Supposedly a variation of the well known SRPP tube buffer circuit.

[Jud]

Optical Ethernet: Considerations re noise of the optical-electrical conversion?

[jabbr]

Someone could start making audiophile SFP modules, but seriously: optical electric generally considered significantly cleaner, greener, and lower noise than equivalent electrical Ethernet.

 

Lower noise = less jitter = better eye pattern

[ted_b]

On paper it should work, but from our limited experience with NAA, we feel that the time and effort needed to have a NAA work well at DSD512 is better spent on a one PC solution

 

 

Edward, I am puzzled somewhat by this statement. Are you saying that although the HQP machine is the one doing the very heavy lifting to DSD512, that the simple FIFO buffer NAA can run into, what, cpu bandwidh issues passing along DSD512 to the DAC? What within the NAA would be the bottleneck for anything, let alone DSD512? Note: I am not saying any ole NAAA will do; I clearly have heard better NAAs and worse NAAs, my fave still being my JCAT-card driven WS2012AO'd one (not the elaset of which is it is a great ASIO solution)...it's still a case of everything matters......but never thought it could be choked by what the HQP machine sent it.

[lmitche]

Ed is saying that a single low noise machine negates the benefits of an NAA. In other words, the NAA is redundant if the original source of the noise is eliminated.

[EuroDriver]

Ted,

 

What you say

my fave still being my JCAT-card driven WS2012AO'd one (not the elaset of which is it is a great ASIO solution)...it's still a case of everything matters......

 

makes the point I was trying to express. A really good performing NAA is quite a bit of work and not inexpensive at the end of the day :-(

[YashN]

Optical Ethernet: Considerations re noise of the optical-electrical conversion?

 

Good question...

 

It may take some work here if someone wants to optimise the noise profile at each end for the controllers and processing, probably needs some isolation work at the receiving end near the DAC.

 

OTOH the main advantage of using these is not being subject to noise/RFI/eMI when the cabling and signal between point occur in the analogue domain with voltage levels and ramp times.

[YashN]

Someone could start making audiophile SFP modules

 

Yup.

[Superdad]

A really good performing NAA is quite a bit of work and not inexpensive at the end of the day :-(

 

Well the forthcoming microRendu has a lot of work put into it and is not too expensive. Will be interesting to see if that changes your mind.

[EuroDriver]

Well the forthcoming microRendu has a lot of work put into it and is not too expensive. Will be interesting to see if that changes your mind.

 

But no Windows ASIO :-(

[jabbr]

Ed is saying that a single low noise machine negates the benefits of an NAA. In other words, the NAA is redundant if the original source of the noise is eliminated.

 

Sure, except that no easy to remove noise from Gtx 980 ti let alone overclocked CPU ... as the processing demands go up, and they will with room correction and multiple channels and if DSD512 is recognized as having better SQ than DSD256 -- next will be DSD1024 -- removing that noise will be an increasingly difficult proposition, whereas a nice little NAA with a fiber optic input and running on an increasingly sophisticated SoC may become increasingly quiet -- at least it will be encased in a solid block of aluminum so its internal screams will be deaf to the outside world

 

Likewise using diskless boot on NAA you can edit a text file , or click on a screen, and switch between Windows and Linux to drive your DAC as desired.

[jabbr]

I haven't done the calculations but with the DSC1 design, I see no problem handling DSD1024 or even DSD2048 -- our chips are capable of handling Gbs level switching. The limitation is how much work we can do in between clock cycles to get the data from the Ethernet side to the direct DSD side -- and in PL so that jitter is minimized.

 

If Miska were to allow his networkaudiod code or at least allow documentation of the protocol , and with the latest development tools, prob 90% of the work could be done in an FPGA itself, so Ethernet in to DSD out, and then the bandwidth would be virtually unlimited eg 16 channels of DSD1024 no problem.

[lmitche]

Sure, except that no easy to remove noise from Gtx 980 ti let alone overclocked CPU ... as the processing demands go up, and they will with room correction and multiple channels and if DSD512 is recognized as having better SQ than DSD256 -- next will be DSD1024 -- removing that noise will be an increasingly difficult proposition, whereas a nice little NAA with a fiber optic input and running on an increasingly sophisticated SoC may become increasingly quiet -- at least it will be encased in a solid block of aluminum so its internal screams will be deaf to the outside world

 

Likewise using diskless boot on NAA you can edit a text file , or click on a screen, and switch between Windows and Linux to drive your DAC as desired.

 

Ed, I don't think you are using a GPU on the SMG server for DSD512 upsampling. Is that right?

 

Jabbr - removing the added complexity of a second machine makes lots of sense to me in a KISS rule kinda way. However it does it, if the SMG server can prove that a computer can be made to run HQplayer upsampling and still be quiet enough for a direct connection to a DAC, that is a good thing to my way of thinking.

 

If the same design reproduces music at a level never attained before, it is a true breakthrough. Don't you agree?

[Jud]

Someone could start making audiophile SFP modules, but seriously: optical electric generally considered significantly cleaner, greener, and lower noise than equivalent electrical Ethernet.

 

Lower noise = less jitter = better eye pattern

 

Was just curious, since some opto-isolators for USB, for example, have a reputation for being noisy.

[EuroDriver]

lmitche

Ed, I don't think you are using a GPU on the SMG server for DSD512 upsampling. Is that right?

 

Larry,

 

No CUDA gpu, just 6700K with a core allocation scheme to keep the various software modules happy and a pretty minimal Win 10

[tne]

Well the forthcoming microRendu has a lot of work put into it and is not too expensive. Will be interesting to see if that changes your mind.

 

I think the price the Jesus referred to in the microRendu thread, while not too expensive, is certainly non-trivial. Add LPS, and it becomes even more non-trivial.

 

What is the perceived advantage of what the NAA approach provides that other approaches (Intona, Acoussence, Mutec, etc.), do not provide? What is the thinking (with current audio USB technologies) about why the NAA approach would be an improvement regarding SQ over the other approaches?

 

For me, without extensive testing, a one-box solution seems better if the one box is somewhat optimized, and it is interesting to hear EuroDriver's comments in this regard. My Mac Mini has PCIe SSD (no SATA drive) and uses JS-2 LPS, going into REGEN (also JS-2 powered) then to Mutec (reclock and USB to AES converter) to DAC (so not really one-box when the other thingees are considered). I am not sure what more the microRendu or other NAA could do to improve sound quality, but my mind is always open (but critically) toward future options where SQ is actually improved.

[jabbr]

Ed, I don't think you are using a GPU on the SMG server for DSD512 upsampling. Is that right?

 

Jabbr - removing the added complexity of a second machine makes lots of sense to me in a KISS rule kinda way. However it does it, if the SMG server can prove that a computer can be made to run HQplayer upsampling and still be quiet enough for a direct connection to a DAC, that is a good thing to my way of thinking.

 

If the same design reproduces music at a level never attained before, it is a true breakthrough. Don't you agree?

 

Actually, I was using a workstation before moving to NAA, and at the moment I'm not seeing the NAA as the weak link, rather I think it is an elegant solution itself.

 

Regarding the DSC1,2 etc, my current thinking is that the USB connection is the weak link, and while a great deal of work has gone into optimizing it, there seems to be no end to the stream of widgets that are now chained together in search of USB perfection, including boxes and cables that are several hundreds of $$ each. Even entire computers that have been designed with the goal of optimizing the USB connection. Shrug.

 

Looking at this from the DAC, USB input point of view, the Amanero board, for example, combines an ARM chip and a CPLD (little brother of FPGA) and others like Xmos similarly use an ARM chip *just to convert USB to I2S/DSD*, so no matter what, we are stuck with at least one extra processor to the extent that you find that less elegant.

 

To me, the most elegant approach would be to use an ARM/FPGA SoC (e.g. the Xilinx Zynq 7000 series) to handle SGMII input (what comes out of the fiberoptic SFP module) and convert to direct DSD output. That is: fiberoptic Ethernet in, direct DSD out -> DSC1 shift register FIR board (and then I-V and analog SK filters). So how would that work? The ARM processor runs Linux and hence networkaudiod (NAA). Do you still consider that another machine? If so why would you accept an SoC to convert USB -> DSD but not to convert Ethernet -> DSD. I think that's even more KISS because there is no USB at all.

 

As I've outlined, there are some recent techniques that have the potential to be real breakthroughs. I also think room correction kernels will become more desirable, and certainly at DSD512 the GPU coprocessor is necessary. We can have it all!

[jabbr]

I should note that the approach I've outlined above is the same approach advocated by the Ravenna/AES67 community. Alc Networx offers a dual ARM/FPGA board to convert from Ethernet -> I2S. I think Merging and others offer similar products. This same approach can be done with HQPlayer using the NAA protocol rather than Ravenna, and output as direct DSD rather than I2S.

[tne]

...We can have it all!

 

I like the way you're thinking.