I.have my DS on sorbothane isolators currently . I had been considering placement of isolation internal under the Analog PWB possibly when I do the jkrichards transformer kit swap.perhaps where the transformers weight down the PWB. Sorbothane that is too thick and not weighted properly can cause oscillation so it is a fine line in getting the right squish so it improves in lowest base regions where all the vibratory excitement happens.
No interest in being a Deity, just sharing tweak’s that I find work and don’t cost four digits or more but offer equivalent upgrade to a system.
I mentioned the FPGA software architecture earlier. Here’s a top-level block diagram. I’ll just wait for questions if there’s anything in particular you’all wonder about. (RD is rate detect.)
It’s a “need to mute, something changed” signal. It clears all buffers, dumps partial results from the upsamplers and mutes the SDM. It stays high for about 4 ms after the last change/error it saw. The SDM starts it’s 10 ms volume ramp up when the “need to mute” drops. I figure that when someone changes tracks or pulls an interconnect out that they really don’t care about the last little bit that they are switching away from. Getting rid of old data out of the upsampler when you “change tracks” is just a good idea, no need for the old and new tracks to get mixed. Flushing the FIFO means that the VCXO frequency control will slow down the clock so that the FIFO can fill towards the middle again with new data. It isn’t a special case, that’s part of the VCXO control anyway.
The SDM that the DS uses is a feedback design which is basically a low pass filter of the input (while at the same time suppressing the noise over the same range.) Here’s a graph of the difference between feed forward and feedback in another SDM.
“Look-ahead Sigma-Delta Modulation and its application to Super Audio CD” - Erwin Janssen, 2010, p. 20
When you do a sampling rate change, you usually upsample first which involves a low pass filter below the Nyquist rate of the lowest rate of the input and output, then you downsample which involves a low pass filter below the Nyquist rate of the lowest rate of the input and the output. One of these filters is redundant So you upsample, filter and downsample. The upsampling usues zero stuffing, the down sampling is throwing all but say, every fifth sample away. The cool thing is when you are upsampling you know that you are going to throw all but every fifth sample away, so you don’t compute them in the first place.
Yep, a part of the I2S input processing is converting to DoP (this happens for the USB input too.) Then I can simply use the same big FIFO and data path as the PCM and not need multiple sets of identical control logic managing different width data paths.
I combine things into sample pairs as soon as possible (just after the input select). The FIFOs treat the left and right as a single unit. The upsamplers, zero stuffers, … SDM all process left and right simultaneously. So it’s arguable whether they are ever two parallel streams or always two parallel streams.
With the FPGA diagram I can more easily describe the FPGA clocking differences between the DS and the DS Mk II.
In the DS there were three different clock rates and four phases of one of them. Everything up to the input select was done at 225.792MHz. The processing after the input selection, up to the output was done with various phases of a 169.344MHz clock and the final output was at 11.2896MHz. The differing phases of the 169.344MHz clock allowed me to roughly divide by four the number of signals changing at any point in time. That lowered the jitter and ground bounce across the FPGA as a whole. It also allowed me to put the most noise sensitive part on the third phase which is the quietest in the Spartan 6 FPGAs. Going from everything on the same phase to everything on different phases was the big change in a release in another galaxy, far, far away. People definitely noticed the difference. Since all clocks in the FPGA are synchronized with each other there aren’t issues like clock beating (heterodyning) etc. which is a normal problem with multiple clocks. But passing data from one clock domain to another has to be done carefully. Fortunately, FPGA vendors provide primitives to make this reliable.
The FPGAs in the Mk II are of a newer generation which doesn’t need quite as much babysitting on ground bounce, etc. So, things are much simpler, everything but the final output runs on one phase of the 225.792MHz clock. This simplifies the code since I don’t have to make clock domain crossings with the data signals, and I also avoid shepherding the sea of control flow signals across domains.
Thanks! For international beta units, we usually let our distros handle them. I believe a number of them will play and test them in their showrooms. Allows them to try it out for us and also drum up some excitement in their area.
So… 768 to 384 just by dropping every second sample is lossless because all the original inputs will be present in the remaining samples, then you perform 147 times oversampling via zero stuffing to 56.448MHz.
The original data is not spaced on multiples of five at this point (prime factors are 2, 3 and 7), so if there’s no additional filtering to change those stuffed zeros to values that track a waveform somewhere below 5MHz bandwidth I’m not understanding how discarding four out of five samples here isn’t a very lossy process. What am I missing?
Perhaps my question wasn’t clear as I was trying to be concise. I’m trying to ascertain whether there’s a filter – presumably FIR type – in the 20x to 4x conversion, and additionally whether this path is less lossless than the 44.1 path. (In the case of 44.1 every bit of input reaches the SDM but I’m not sure that’s true with the 48 path.)
With no filtering, zero stuffing followed by decimation does indeed cause issues.
I was oversimplifying with the 48, 96, series, I take multiple steps from 768 to 11.2896MHz: from 768kHz down to 384kHz, up sample by 21 to 8.064Mhz (with the appropriate filter) then down by 5 to 1.6128MHz, then up by 7 to 11.2896MHz (filtered once again, both with a FIR and with the SDM’s filter.) It’s the same as upsampling directly to 56.448MHz then down to 11.2896MHz, just done in a slightly different order.
I’d rather do it in one step, but coming from 768kHz we aren’t losing any of the original signal with 2 upsamplings instead of one.
With the DS I did indeed simply zero stuff everything to 56.448MHz and only calculate every fifth sample and then rely on the SDM’s filtering. And indeed there was a small amount of aliasing of 48, 96, and 192 in the 384kHz area. The oversampling and lowering was correct for the 44.1k series. With the Mk II I took the extra steps to keep the 48k series clean everywhere.
That feels like it makes sense to me now.
I don’t recall whether the original DS performed that decimation prior to SDM or if it processed the full 10xDSD rate as input, but the impression I took from the marketing/comms was that every bit of input for both 44.1 and 48 families was present right up to the SDM stage. I have no criticism to make – just enjoying learning about how it works.
The up/down/up/down/up sequence is fascinating. Did you elect to do that because of bandwidth/ops-per-second constraints in the FPGA similar to what you described earlier wrt to FIR filter design? Do you have a similar multi-stage approach to the 44.1 family for that same reason or is it actually direct from 705k to 56M?
The original DS:
44.1/48 to 88.2/96 (Nyquist rate cutoff)
88.2/96 to 176.4/192 (Nyquist rate cutoff)
176.4/192 to 28.224MHz (direct zero stuffing) (Butterworth IIR)
Decimation by 5
Somewhat later:
44.1/48/88.2/96 to 176.4/192 (Nyquist rate cutoff)
176.4/192 to 28.224MHz (direct zero stuffing) (Butterworth IIR)
Decimation by 5
Somewhat later:
44.1/48/88.2/96/176.4/192 to 352.8/384 (Nyquist rate cutoff)
352.8/384 to 56.448MHz (direct zero stuffing) (no more Butterworth IIR, not needed for 44.1…, good enough for 48…)
Decimation by 5
The system as a whole sounded better by dropping the Butterworth IIR
There aren’t enough multiplies available to do a respectable FIR filter at 56.448MHz. The system sounded better without an IIR in spite of some (pretty high frequency) low level aliasing.
For the Mk II I wanted to do the 48… properly. (It was already proper to zero stuff 705.6kHz to 11.2896MHz and then SDM.) But 48… would take more work, especially since I’d need to go to 112.896MHz if I only took one step. The answer was to take as big a step as possible at the lower frequencies and then take a smaller step if I needed to. The decimation by 5 would be early enough that it didn’t compromise the quality of the output, which precluded it from being used on 786kHz because that would have a filter cutoff out at 76.8kHz.
The upsampling needed to be 147/10 which is (3 * 7 * 7) / (2 * 5)
The biggest first step would be 49 and then 3, but then we’d need to be filtering at 37.632MHz.
The 2nd choice would be 3 * 7 or 21 and then 7 which is what I did.
Then I needed to put in the decimation by 2 and the decimation by 5.
Since the spec for the DS Mk II doesn’t support 384, decimating 768 to 384 wouldn’t lose anything so I could do it first. Decimating by 5 there wouldn’t be good.
So the 48… recipe became 48/96/192 to 768kHz and then 768 / 2 * 21 / 5 * 7 = 11.2896Mhz.
I’d like to add 384k and possibly even 768, but that won’t be for a release or two if I do do it.
TOSLink: 16 and 24 bits at 44.1, 48, 88.2 and 96 (off spec but usually works: 176.4, 192 and DoP64)
S/PDIF and AES3: Everything above, 176.4, 192 and DoP64
Dual AES: Everything above, 352.8 and DoP128
I2S: Everything above, 705.6, DoP256, DSD64, DSD128 and DSD256
USB: Everything above, except possibly 24 bits at 705.6 and DoP256 (DSD256 will still work.)
Interesting. I use a Sonore Signature Rendu SE (Fiber in, USB out). In the setup to act as a Roon endpoint it states:
“If your DAC supports DSD select DoP. Otherwise select none and Roon Server will transcode DSD to PCM.”
Up above you wrote "except possibly 24 bits at 705.6 and DOP256 (DSD256 will still work.) What does “except possibly” mean? Are there some cases where it will work?
DoP256 is 24/705.6
16/705.6 Works in USB Audio 2.0 (which USB 2.0 supports)
24/705.6 doesn’t work in USB Audio 2.0 (packets would either be too big or too fast for USB2.0)
24/705.6 works in USB Audio 3.0 (which USB 2.0 supports)
The issue then is does your source support USB Audio 3.0? Does the PC/MAC drivers for the Mk II USB? The Mk II hardware supports it, but I’m not positive the drivers we will ship with will (only because I had a chance to test it yet for myself.)
So some sources won’t be able to do 24 bits at 705.6 and DoP256 and I don’t know the state of the PC USB driver for the Mk II.
USB Audio 3.0 also has explicit support for native DSD without requiring a DoP envelope. So if they do add support for Audio 3.0 they might potentially do native instead of adding 50% to the throughput (top 8 bits of 24 are used to signal DoP, remaining 16 are DSD bits).
So you upsample, filter and downsample. The upsampling usues zero stuffing, the down sampling is throwing all but say, every fifth sample away. The cool thing is when you are upsampling you know that you are going to throw all but every fifth sample away, so you don’t compute them in the first place.