Signalyst DSC1

TNT

Member
Joined 2003
Paid Member
+1

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.
 
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.
Agreed

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.
Yes, & that is what I'm saying - USB electrical standards don't specify as "clean a USB signal as possible" so if not using the Rendu it's wise (if not optimal) to isolate & clean the incoming USB signal at the downstream USB audio device - this seems to be more effective than I2S isolation & reclocking after the USB receiver

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.
If you have any links for this, I would appreciate but USB receivers come in many different forms - XMOS & Amanero being the two most popular in audiophile devices & I haven't seen any specs showing 200pS jitter on their I2S outputs, however I find it beneficial to reclock I2S just before the DAC input - I2S isolation not really needed if already done at USB input
 
Last edited:
i have not been following the thread... apologies if it was mentioned somewhere...just to confirm for the Amanero with the correct firmware will remove the pop issue during start/stop/sample rate change?

Does the removal of the pop uses the "MUTE" pin 11 to sort of ground the output/relay circuit to mute the output ?

So this MUTE circuit is built into the Signalyst V2 GB ?

If i were to use the Amanero on other DSD design i would need to built a mute circuit using the "MUTE" pin as a trigger ?

Thanks
 
i...just to confirm for the Amanero with the correct firmware will remove the pop issue during start/stop/sample rate change?
Yes
For Windows - 1099c
For Linux - 2003be_xx

So this MUTE circuit is built into the Signalyst V2 GB ?
Yes, dead silent - no clicks, pops

If i were to use the Amanero on other DSD design i would need to built a mute circuit using the "MUTE" pin as a trigger ?
Yes
 
Member
Joined 2009
Paid Member
Vit123 the mute circuit using the "MUTE" pin as a trigger is the same schematic like attached pic?

TIA
Felipe
 

Attachments

  • RC filtro paso bajo.gif
    RC filtro paso bajo.gif
    38.5 KB · Views: 674
Member
Joined 2006
Paid Member
4x clocks vs 2x clocks?

Before I continue, for the past week since I fixed the pop/mute, I have been enjoying tremendously the DSC2.5. So much so that my iFi iDSD BL (and iDAC2 perhaps) are going on eBay.

Now to the question:
I have Hermes/Cronus with 44k and 48k oscillators. I normally use the divider, so BBB and DSC2 are getting 22k and 24k respectively.

So my question is: am I really hearing a difference between 2xk frequency vs 4xk frequency, as in 22k/24k setting being better?

Unfortunately I can't A/B them - it takes about 2 minutes to switch between the two setups.

Pavel, have you tried with different clock frequencies? If yes, did you measure any difference?
 
Member
Joined 2006
Paid Member
Did not quite understand the question.
This DAC does not have a built-in generator. The DSC works equally well with both 22/24 frequency grids.



Pavel,
My question is simple:
I have an isolator reclocker between BeagleBone and DSC2.
The clocks are 44.1 and 48 kHz.
They provide master clock to both BBB and DSC2.
I normally use them with a hardware divider (a simple jumper) x2, so this way they feed 2x kHz.

I tried without the divider and with the proper setup in BeagleBone Linux (set to expect 4x kHz).

I feel 4x kHz is worse than 2x kHz.

Does it make sense to you?
 
Pavel,
My question is simple:
I have an isolator reclocker between BeagleBone and DSC2.
The clocks are 44.1 and 48 kHz.
They provide master clock to both BBB and DSC2.
I normally use them with a hardware divider (a simple jumper) x2, so this way they feed 2x kHz.

I tried without the divider and with the proper setup in BeagleBone Linux (set to expect 4x kHz).

I feel 4x kHz is worse than 2x kHz.

Does it make sense to you?

I think you're confusing things.

I'm assuming you have 45.1584MHz and 49.152MHz oscillators installed in your Cronus; whilst these relate to the 44.1KHz and 48KHz data rate 'families' they aren't the same. With the x2 divider the clock signals you're outputting from Cronus will be 22.5792MHz and 24.5760MHz and with the x4 divider they'll be halved again. IIRC you need 22/24MHz clocks for DSD512 and at 11/12MHz you'll be limited to DSD256. So at the objective level you need to set the divider to provide the clock rates required for your data/hardware just so things work correctly, beyond that they're your ears...

I will set my Cronus up to provide 22/24MHz clock signals to DSC2 (which will be 45/49MHz oscillators and x2 divider)
 
Last edited:
May i ask if this BBB driver is available ? I have a BBB going into a DSD dac (different design from DSC2) but would need a MUTE trigger to stop the pops. I will have to come out with a MUTE circuit but thats another story. Thanks


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.
 
Absolutely. I’ll provide instructions and download link tomorrow.

Just a general question about your BBB usage with DSC2 2.5

Is your setup BBB>I2S>DSC2 or BBB>USB>Amanero>DCS2?

I'm looking from long time for a solution capable to jump over USB and directly land into I2S for pure DSD playout. I read around and saw implementations with Rasperry or BBB but in all of the cases there was a lack in mute implementation, that's not acceptable in my scenario (high expensive speakers).
 
Member
Joined 2006
Paid Member
Adventures in BBB Botic and DSC2.5

Just a general question about your BBB usage with DSC2 2.5

Is your setup BBB>I2S>DSC2 or BBB>USB>Amanero>DCS2?

I'm looking from long time for a solution capable to jump over USB and directly land into I2S for pure DSD playout. I read around and saw implementations with Rasperry or BBB but in all of the cases there was a lack in mute implementation, that's not acceptable in my scenario (high expensive speakers).

Short answer: I don't use USB/Amanero.

Long answer:

I started with Odroid C2/BBB>Isolator>Amanero USB>DSC2.5.

Then I switched to I2S with isolator/reclocker via Botic BBB: BBB>Hermes>Cronus>DSC2.5.
It was not successful in the beginning - random noise as loud as music. Fortunately, Pavel figured out that replacing one IC would be sufficient to allow non-Amanero sources to interoperate with DSC2, including XMOS. He has fixed this design issue with the new batch of DSC2.5.2 and DSC2.6.2.
For the users of the old batch, there were two options: replace the IC in order to invert the phase of the signal or do this in software.
One cannot easily do this with XMOS devices. Unless one can recompile the firmware. In BBB/Botic, it is a simple parameter to the Botic driver.
After that issue was resolved, it was time to listen.
There were loud pops, but they didn't concern me as much - it was more annoying than anything. I suppose because I'm using a tube amp with huge output transformers... maybe they smooth the pops out. Maybe I'm just careless.
In any case, the result was also not very promising sound-wise, so I decided the DSC1/2 was made to be used with Amanero.
I know, it is not very scientific, but then when one's science fails him, he resorts to alternative descriptions of reality.
I think the reason I was not happy is because of the length and arrangement of the I2S lines.

Then I went back to Amanero, but added a reclocker to the system and switched the isolator model and position - this time AFTER Amanero: BBB>Amanero USB>Hermes>Cronus>DSC2.5.
This system worked best sound-wise, but there were loud pops again: the Hermes isolator is originally made for Buffalo DACs, which do not require the mute pin the same way as Amanero implements it. Therefore, the MUTE pin is not exposed at the isolated side. This is the reason nautibuoy has created an alternative isolator that would deal with this issue.

I was left with the option to either use USB/Amanero or recompile the Botic kernel driver and use one of the GPIO lines to supply MUTE to the isolated side. miero, Botic's original developer (thank you with all my heart), seems to have moved on to other areas of interest and was not very eager to go back and revise the code. This is totally understandable. My only choice was to hack my way through kernel driver development.

In the end, I managed to do it and right now, I feel BBB>Hermes>Cronus>DSC2.5 is the best DAC that has been I'm my system. Previously there were a few PCM63K implementations (Adcom, Parasound, heavily modded PSUs). Recently, I was using HQPlayer with iDSD BL @ DSD512, and before that I was using DAM1021 (XMOS USB, RPi > I2S or BBB > Hermes/Cronus > I2S).
A case can be made maybe I wasn't doing something right to not be able to get the right sound from the R2R DACs.
Maybe so, but in my system, I don't think anything touches the holographic presentation of HQPlayer combined with DSC2 and reclockers. In my opinion.

I am developing a PCB to adapt Cronus output to DSC2.x.x input and allow for flexible selection of the mute pin on the Cronus side.

I'm happy to share the recompiled Botic driver and the Schematic/PCB of the adapter. I just completed the initial design and since it is my first attempt at this, it may be helpful if other people chime in.
 
Last edited: