Signalyst DSC1

@Vit123 @nautibuoy
Do you have any "external" usb isolator to test with tuned Amanero?

My current system is based on a higly tuned JLsounds dac/interface with reclock board, separate power supplies (Belleson) and custom discrete out stage. Unespectedly the insertion of an Intona isolator, dramatically improved the sound.

In order to to feed the Amanero/DSC2 system I'm in doubt to go to the Vit123 board with just the Crystek oscillators upgrade or land into a more complex board as nautibuoy has. To be honest I would like to avoid the Intona "soapdish" ... Unfortunately I'm too far from you!
 
Has any of you tried JLsounds I2SoverUSB board?

Yes, but in a basic 'no-DAC' setup not with a DSC2 decoder. I had to be careful powering up with the no-DAC because of the pop. It worked OK with no-DAC other than that.

I like the JLSounds board because it's excellent value, expecially when you consider it includes isolation and reclocking, and I have one with my Soekris DAM1121 DAC.

For DSC2 I will stick with Amanero because it is better optimised for DSD playback with DSC2 type decoders and because Pavel has designed DSC2 to work with Amanero.
 
@Vit123 @nautibuoy
Do you have any "external" usb isolator to test with tuned Amanero?


I tried Intona Galvanic Isolator with my DSC. Without succsess - more dirty sound.
IMHO the problem of isolators are an increase in jitter and additional noise.

Think that nautibuoy project is very promising (isolation + recklocing).

For now I'm using iFi Purifier 2 and happy with result (more black background).
 
Yes, the only way to properly use an isolator with a USB interface is: USB receiver-isolation-master clock(s) and re-clocking (Potato FF)-DAC. The isolator it self adds somewhere above 100 pS of jitter, so you need to re-clock direct from masterclock right before input of I2S (DSD) to the DAC. This way the master XO is on the clean side of the board and can have a clean power supply, and then you also do the final re-clock there right before the DAC for least amount of jitter.
Of course Intona is a totally different thing as it isolates actual USB signals, this does not isolate the DAC and masterclock from the processor noise of the USB receiver. best to use a very clean USB source rather than straight from a commercial computer. A Network Renderer like the Sonore Rendu series outputs a much cleaner USB data stream and can be used as NAA for HQPlayer, or with Audirvana and ROON DSD oversampling over the network.
 
... A Network Renderer like the Sonore Rendu series outputs a much cleaner USB data stream and can be used as NAA for HQPlayer, or with Audirvana and ROON DSD oversampling over the network.

Do you have experience with Sonore mRendu (DSD512 + Amanero)?

When I started experiments with PCM-DSD512 converting (HQP, mRendu as NAA, 2.5 firmware) it seemed to me that quantity of artifacts (whistling, hi-frequency noise at start of track) with mRendu was more often then with my Intel NUC (as NAA, Debian with kernels by Jussi Laako). As a result, I sold it.

That's why I'm asking.
Perhaps uRendu behaves better or it was just my imagination:)
 
My experience is that Amanero is sketchy with native DSD and Linux in general, and different Linux approaches do have slightly different results, but it seems to be because of the Amanero firmware still not being fully mature for Linux/Native DSD. For example, Rendu products run fantastically with XMOS based USB receivers, and native DSD.
Right now I have little experience with DSD 512, so I cannot comment there. If you like the approach of using a commercial NUC stick with it, but you are leaving some USB performance on the table.
I cannot tolerate any of the weirdness which sometimes happens with DSD 512, so i only use DSD 256 and do not go higher, there still seems to be too may instances of whistling, and burst of noise with Amanero and any linux approach. Hopefully DOM gets a final version of linux/native DSD firmware figured out, until then I stick with DSD 256 no matter the hardware.
 
For example, Rendu products run fantastically with XMOS based USB receivers, and native DSD.
Absolutely agree.

Hopefully DOM gets a final version of linux/native DSD firmware figured out, until then I stick with DSD 256 no matter the hardware.
Yes, for now I do not know any perfect working firmware for Amanero, DSD512 Native.

Even more - my diyink XMOS board works with DSCv2 at DSD512 without any artifacts at all.
But huge pops and clicks are very annoying.
 
Popless DSD

Hi,

@nautibuoy and I discussed BBB/Hermes/Cronus before and I'm glad to announce that the pops have been resolved. At least for me.

I managed to recompile and modify the snd_soc_davinci_mcasp driver for the latest 4.8.13-botic7-rc3 kernel. I am sure @miero will be outraged when he sees what I've done, but as far as kernel driver development, I'm more or less a noob.

In any case, I supply HIGH at rest to configurable Cronus data pin(s) and supply this to pin 11 of DSC2. I wait for the stream to initialize and I supply LOW the the same pin, thus enabling playback and avoiding the pop.
There is even a configurable mute delay in milliseconds, but I'm not sure it is needed - it works fine without it.

With BBB/Hermes/Cronus there used to be pops both during play and stop as well as rate change.

Also, I created a better I2S connection between Cronus and DSC2 and now I can't distinguish between Amanero straight to DSC2 and BBB/Hermes/Cronus. I suspect my system is not resolving enough, so my next step would be to assemble KGSS for my electrostats. Then I'll know.

In the meantime, I'd be happy to share the driver as it is. I need to clean it up a bit, but it should be ready tomorrow.

@miero also promised to look at it, but I was too impatient: I like the DSC2 sound so much, I could no longer tolerate the pops.
 
I'm laid up with a bad chest infection at the moment so no progress on assembling anything for a few days, however, having looked through the V2.5.2 manual, I have reworked a new version of my isolator PCB to suit V2.5.2. I've rotated the DSC2 header through 180deg. so that it will plug onto the DSC2 board without having to worry about connecting the mute signal. I've done this because it isn't possible to stack the isolator/reclocker across the 2.5.2 board so it has to project from the front of the board as with the V2.6.2 Amanero interface arrangement. If isolation/reclocking works on my current board I will order a batch of the revised boards and offer them to V2.5.2 users.
 
Yes, the only way to properly use an isolator with a USB interface is: USB receiver-isolation-master clock(s) and re-clocking (Potato FF)-DAC. The isolator it self adds somewhere above 100 pS of jitter, so you need to re-clock direct from masterclock right before input of I2S (DSD) to the DAC. This way the master XO is on the clean side of the board and can have a clean power supply, and then you also do the final re-clock there right before the DAC for least amount of jitter.
Of course Intona is a totally different thing as it isolates actual USB signals, this does not isolate the DAC and masterclock from the processor noise of the USB receiver. best to use a very clean USB source rather than straight from a commercial computer. A Network Renderer like the Sonore Rendu series outputs a much cleaner USB data stream and can be used as NAA for HQPlayer, or with Audirvana and ROON DSD oversampling over the network.

Your suggested approach which is the method most USB audio devices use when they advertise themselves as galvanically isolated, is sub-optimal, IMO. Isolation of I2S signals AFTER the USB receiver is not the optimal point for isolation - this should happen on the incoming USB D+ & D- signal lines, before the USB receiver - it appears that the USB signal itself (& whatever noise is riding on it - common mode? ) bakes some distortion into the I2S signal itself (the output from the USB receiver).

Isolating this I2S signal is of no benefit regarding this baked in distortion.
 
hmmm.

Your suggested approach which is the method most USB audio devices use when they advertise themselves as galvanically isolated, is sub-optimal, IMO. Isolation of I2S signals AFTER the USB receiver is not the optimal point for isolation - this should happen on the incoming USB D+ & D- signal lines, before the USB receiver - it appears that the USB signal itself (& whatever noise is riding on it - common mode? ) bakes some distortion into the I2S signal itself (the output from the USB receiver).

Isolating this I2S signal is of no benefit regarding this baked in distortion.

By isolating the output of the I2S signal from the USB receiver and then re-clcoking it, you eliminate all the jitter just before the conversion, this is the ideal approach. Nothing is "baked in" to the I2S signal, there is only data and jitter, the data is perfect, but the timing is not. By re-clockign the perfect data stream, you eliminate all jitter as well.
 
By isolating the output of the I2S signal from the USB receiver and then re-clcoking it, you eliminate all the jitter just before the conversion, this is the ideal approach. Nothing is "baked in" to the I2S signal, there is only data and jitter, the data is perfect, but the timing is not. By re-clockign the perfect data stream, you eliminate all jitter as well.

Sorry, that's not what my experiments have shown me & AFAIR, USB isolators in front of DACs that do exactly what you say (reclock I2S) have been reported to improve the sound. I may be wrong about my premise 'some distortion being baked into the I2S signal' but there is a useful sonic improvement by isolating & reclocking the USB signal coming into the USB receiver over & above the sonic improvement from isolating & reclocking the USB receiver's I2S output signal - something is responsible for this but I don't know the exact mechanism that causes this improvement.

In a way this reminds me of the asynch USB debate of old where it was thought/claimed that this solved USB audio issues & made it sonically immune to upstream USB signal/cable quality - it didn't!
 
Last edited:
Well...

Sorry, that's not what my experiments have shown me & AFAIR, USB isolators in front of DACs that do exactly what you say (reclock I2S) have been reported to improve the sound. I may be wrong about my premise 'some distortion being baked into the I2S signal' but there is a useful sonic improvement by isolating & reclocking the USB signal coming into the USB receiver over & above the sonic improvement from isolating & reclocking the USB receiver's I2S output signal - something is responsible for this but I don't know the exact mechanism that causes this improvement.

In a way this reminds me of the asynch USB debate of old where it was thought/claimed that this solved USB audio issues & made it sonically immune to upstream USB signal/cable quality - it didn't!

1. no level of "isolation" is perfect as all isolators allow for some noise to couple through, therefore, in some set ups, isolation applied on the USB input side may also be of value.

2. I use the Sonore Signature Rendu SE to provide my USB feed, and this Renderer is designed to have as clean a USB signal as is possible, so I find no benefit to adding additional isolation on that side. If one is using just a normal commercial grade computer board to provide the USB feed, then yes, it may carry a lot of noise along with it.

3. But, the output from USB receiver chips has been shown to be quite jittered (and loaded with high frequency processor noise) regardless of how good the USB source is, it still needs to be isolated on it its output and re-clocked right before conversion, other wise you have 200 pS of jitter or more at the DAC. By keeping the masterclock and re-clocking circuit on the clean side of the isolation, you can then re-clock the signal directly into the conversion stage, this results in the lowest possible jitter where it matters, right at the point of conversion.