Yes, you're using transformers in a layout similar to Hazard's build. Jesper's sounds a little different in not having transformers and two passive LP filters, which I thought people might also like to see.
Ray
Yes. The correct method is to use ECL with CCS to weakening the PSU voltage variation and avoid amplitude modulation distortion.
I'll have a go, though you're not very specific about what you mean by 'output'. To answer I'll reference the JLSounds I2SoverUSB board that I use;
http://www.diyaudio.com/forums/digital-line-level/273474-best-dac-no-dac-9.html#post4323177
You can see from the information that several of the pins on the board (7 and 8 for example) are able to output 3.3V; they switch between 0V and 3.3V to indicate certain states so not constant 3.3V.
But I guess you not talking about these state indicators but the data outputs such as pins 13 and 14 (as we're talking about DSD). The simple answer is no, these don't output a constant 3.3V. In fact these are acting in a similar fashion to the state indicators, switching between 0C and 3.3V, just at a very high frequency in order to describe the data signal. Averaging 0V and 3.3V over a period of time is why you get 1.65V DC offset on the output. That's a very simplistic answer that does no justice to the actual engineering that makes these things work properly and consistently.
Ray
This morning I made an update that may be of interest to those using HQPlayer with an NAA.
I installed a second network card into my HQPlayer PC and set up a subnet that just connects to the NAA device. This means that the network traffic to the NAA (the upsampled DSD data stream from HQPlayer) is completely separated from all other traffic on the home network, essentially having a network to itself.
With DSD256 streaming I was getting very occasional dropouts but these have been completely eliminated and everything works very well and sounds unbelievably good.
With music playing (as DSD256) the traffic load on the NAA subnet is almost constant at around 30Mbps whereas the traffic on the main home network shows a lot of peaks and troughs as the flac source files are pulled down from the NAS.
Setting up a subnet isn't difficult and may be worth considering.
Ray
I installed a second network card into my HQPlayer PC and set up a subnet that just connects to the NAA device. This means that the network traffic to the NAA (the upsampled DSD data stream from HQPlayer) is completely separated from all other traffic on the home network, essentially having a network to itself.
With DSD256 streaming I was getting very occasional dropouts but these have been completely eliminated and everything works very well and sounds unbelievably good.
With music playing (as DSD256) the traffic load on the NAA subnet is almost constant at around 30Mbps whereas the traffic on the main home network shows a lot of peaks and troughs as the flac source files are pulled down from the NAS.
Setting up a subnet isn't difficult and may be worth considering.
Ray
wow, what IC did you used? or discrete LTP? I dont have much experience of ECL.
Next step should be switching to fibre for optical isolation. Then you can see if Acko's reclocker truly isolates all upstream artifacts passed on by the server.
Something like this in the server:
http://www.startech.com/Networking-...abit-ethernet-fiber-card-open-sfp~PEX1000SFP2
And this connected to the NAA:
http://www.amazon.com/gp/aw/d/B0062..._UL100_SR100,100_&refRID=1G26W8KBYB0X0CM16VCK
Last edited:
In my experience the SO3 does what it says on the tin...
Not that I'm using one in this project currently, clocking and isolation are built into the JLSounds USB board
Oh I thought this was using the I2S outs on the BBB.
Anyways many people are reporting sonic benefits on Computer Audiophile optically isolating their NAA's from the server.
No, I haven't managed to get the BBB/Botic functioning with NAA and my Linux skills are inadequate to take it further at the moment. BBB/Botic works perfectly well with DSD in it's own right, just not as an HQPlayer NAA - I use it via UPnP to replay original, or offline converted, DSD files.
I can accept that fibre network might deliver benefits through isolating the devices but I remain to be convinced that if you have isolation and reclocking already that there are cumulative benefits. Personally I would go for an isolation and reclocking capability before fibre Ethernet.
Ray
I suppose it would take trying both to come to a conclusion on this point. I'll be doing some experimenting with optical in conjunction with non-reclocked/isolated and reclocked/isolated USB interfaces. Hopefully this will clear up misconceptions so we can come up with definitive guide regarding these tweaks.
It will also be essential to ensure the fiber to copper transceiver device isn't creating more noise than the connected server in the first place. Audio Precision test gear will be handy for finding this out.
The principle is like the attachment file.
"Ultra High Frequency Transistor Arrays" can be used as discrete components. Note that the transistor alternate work in the either saturation or cutoff.
Attachments
Regarding optical Ethernet -- generally considered to have significantly less noise but like with everything : implementation dependent
Sent from my iPhone using Tapatalk
I think some real tests of the fibre to copper converter devices need to be conducted. If these can be built to be low noise, it will definitely be another layer of defence against upstream noise getting into the DAC.
In other words, why analog FIR just as Jussi's dsc1 does, and why double differential architecture just as DSD1700 does?
In my own practice, there was a alternative idea that a friend gave to me is to take a high-speed multi-bit DAC and only used its single MSB, pretty good sound experience. From no IC to IC return, effective but some madness.
Furthermore, I do not understand about the duty cycle as you said, noticed DSD1700 data table is also described that say 75% blabla.
