So, I've read a good amount on strategies to reduce jitter for PCM, specifically stuff like ASRCs and what not. However, I haven't seen much on how to do the same for DSD streams. For your typical USB system, the path of the data should go like this:
DSD file --> DoP encapsulation --> USB Audio --> USB Receiver --> DoP deconversion --> ???? --> DSD DAC --> line-out
The question is, what, if anything, needs to be done in between the converting of the DoP to the DSD stream and the DAC stage to remove jitter?
DSD file --> DoP encapsulation --> USB Audio --> USB Receiver --> DoP deconversion --> ???? --> DSD DAC --> line-out
The question is, what, if anything, needs to be done in between the converting of the DoP to the DSD stream and the DAC stage to remove jitter?
just put it into most any current multibit Delta Sigma - they digitally filter the single bit DSD for increased word length and merge into their modulator to match their internal thermometer code DAC resolution - incidentally giving less jitter sensitivity
next to no one offering "DSD compatibile" DAC are really puting 1 bit DSD out into a analog filter
next to no one offering "DSD compatibile" DAC are really puting 1 bit DSD out into a analog filter
Okay, but that's not what I'm asking. I know you can put DSD streams into a DAC, and it will internally convert it into PCM. However, how do I get the stream TO the DAC reliably in the first place?
I presume I need some sort of PLL. Silicon Labs and TI both have things they refer to as "clock jitter cleaners." Would those work?
Clock Jitter Cleaners - Dual / Cascaded PLL - LMK04816 - TI.com
I presume I need some sort of PLL. Silicon Labs and TI both have things they refer to as "clock jitter cleaners." Would those work?
Clock Jitter Cleaners - Dual / Cascaded PLL - LMK04816 - TI.com
DSD appears to me to be inordinately jitter sensitive in native form, something that I've never seen DSD-pushers admit to. One solution, which I originally saw proposed by Hawksford is to use a transversal filter. Essentially this sums together an array of 1bit DACs each delayed by a single sample period with individual weightings to give the desired filtering effect.
The original mention is here - http://www.essex.ac.uk/csee/research/audio_lab/malcolmspubdocs/J16%20Letter%20re%20J15%20JAES%20paper.pdf. You'll note from this that Bob Adams recognises the extreme jitter sensitivity of noise shaped DACs with negative SNR over their operating range.
<edit> The only place that jitter needs to be reduced is at the point of converting from digital domain to analog - i.e. at the DAC itself. Nowhere else matters.
The original mention is here - http://www.essex.ac.uk/csee/research/audio_lab/malcolmspubdocs/J16%20Letter%20re%20J15%20JAES%20paper.pdf. You'll note from this that Bob Adams recognises the extreme jitter sensitivity of noise shaped DACs with negative SNR over their operating range.
<edit> The only place that jitter needs to be reduced is at the point of converting from digital domain to analog - i.e. at the DAC itself. Nowhere else matters.
Last edited:
Who told you its native? That part uses a multibit SDM with multibit DAC so seems very unlikely the designers will have added an additional native 1bit converter to the silicon area.
If the USB protocol is async then the jitter is going to be that of the local clock, nothing to do with anything about the DSD signal.
If the USB protocol is async then the jitter is going to be that of the local clock, nothing to do with anything about the DSD signal.
Last edited:
According to the datasheet it is, at least, I assume it is because it explicitly mentions the ability to convert to PCM. Why would they even give the option of converting to PCM if this happens anyway?
Anyhow, regardless, do things like PLLs have to be specifically made for audio? Will anything with the right specs work? What specs should I be looking for?
Anyhow, regardless, do things like PLLs have to be specifically made for audio? Will anything with the right specs work? What specs should I be looking for?
Point us to the chapter and verse where you say the datasheet mentions the ability to convert to PCM?
As jcx has pointed out given that it'll internally convert DSD to its own noise-shaped PCM format, the jitter sensitivity is reduced over that of native DSD. No PLL is called for if you're using async USB and if you're not using async USB, whyever not?
As jcx has pointed out given that it'll internally convert DSD to its own noise-shaped PCM format, the jitter sensitivity is reduced over that of native DSD. No PLL is called for if you're using async USB and if you're not using async USB, whyever not?
WM8741 has "Direct" DSD mode or "DSD Plus" which converts to PCM.
There is an interesting thread at C.A. where it explains multibit SDM is not PCM (not my posts):
* 1 bit PCM is the same thing. In PCM, a bunch of 1's will add up to create a larger width pulse.
No, PCM encodes absolute amplitude as two's complement encoding at discrete time steps where width of each period is determined by sampling rate.
PDM encodes signal as density of positive and negative pulses. PWM is just variation where adjacent same bits are merged to encode signal as width of positive and negative pulses. Sampling rate defines smallest possible pulse length.
DSD is strictly a PDM, but practically it is used as PWM.
* However, in a modern day DAC, you have an analog sum of multilevel (usually first 5 or 6 bits) and DSD (usually 2 bit with MSB as sign, resulting in so-called 2-1/2 bit DSD).
That's only TI's hybrid architecture. Others make pure SDMs.
And the "2.5-bit" means five output levels (as described in the datasheet), IOW, log2(5) = 2.3219 which is roughly 2.5 bits as two's complement (which it is not, since it's not PCM). Practically zero level and two voltage levels above zero and two below zero (after I/V). You could think it as similar to NAD's PowerDrive amplifier circuit.
When used for DSD playback, it is used to form four alternative analog FIRs (since the output element behavior is not hard-coded).
There is an interesting thread at C.A. where it explains multibit SDM is not PCM (not my posts):
* 1 bit PCM is the same thing. In PCM, a bunch of 1's will add up to create a larger width pulse.
No, PCM encodes absolute amplitude as two's complement encoding at discrete time steps where width of each period is determined by sampling rate.
PDM encodes signal as density of positive and negative pulses. PWM is just variation where adjacent same bits are merged to encode signal as width of positive and negative pulses. Sampling rate defines smallest possible pulse length.
DSD is strictly a PDM, but practically it is used as PWM.
* However, in a modern day DAC, you have an analog sum of multilevel (usually first 5 or 6 bits) and DSD (usually 2 bit with MSB as sign, resulting in so-called 2-1/2 bit DSD).
That's only TI's hybrid architecture. Others make pure SDMs.
And the "2.5-bit" means five output levels (as described in the datasheet), IOW, log2(5) = 2.3219 which is roughly 2.5 bits as two's complement (which it is not, since it's not PCM). Practically zero level and two voltage levels above zero and two below zero (after I/V). You could think it as similar to NAD's PowerDrive amplifier circuit.
When used for DSD playback, it is used to form four alternative analog FIRs (since the output element behavior is not hard-coded).
That's not explanation that's probably just Miska. For example DSD is indeed PDM (pulse density modulation) but its not 'practically used as PWM. PWM has a different quantum of pulse width from the symbol rate, whereas DSD has its quantum the same as the sample rate. I'd not place a lot of weight on what you read over at CA, they do have a high proportion of DSD pushers there 
<edit> Forgot to mention Charles Hansen has begun posting over there recently, injecting a much more reasonable perspective but seems he's not particularly been made to feel welcome
<edit> Forgot to mention Charles Hansen has begun posting over there recently, injecting a much more reasonable perspective but seems he's not particularly been made to feel welcome
Last edited:
That was indeed Miska
Is he wrong too in saying multibit SDM is not PCM? is he wrong in any other DSD related statements he has made? I know nothing about PCM/PDM but and to me he seems to be quite a knowledgeable guy and he has stated many times he likes, favours and uses both.
BTW, there are may be many DSD pushers over "there" but just as many if not more PCM pushers. I don't understand why one should "push" anything, choice is good and all have their pros and cons.
Is he wrong too in saying multibit SDM is not PCM? is he wrong in any other DSD related statements he has made? I know nothing about PCM/PDM but and to me he seems to be quite a knowledgeable guy and he has stated many times he likes, favours and uses both.
BTW, there are may be many DSD pushers over "there" but just as many if not more PCM pushers. I don't understand why one should "push" anything, choice is good and all have their pros and cons.
As far as I can see he's wrong yes - multibit SDM uses PCM, the only difference is there's appreciable out of band noise and higher OS ratios in the SDM case, but those differences don't invalidate the format classification.
I haven't noticed anyone pushing PCM - given that PCM isn't a marketing format there's nothing to be gained financially by pushing it anyway. People push DSD because their business models require its greater acceptance ISTM - they've already made investment in DSD hardware and seek to differentiate their offerings in the market by adopting it.
I haven't noticed anyone pushing PCM - given that PCM isn't a marketing format there's nothing to be gained financially by pushing it anyway. People push DSD because their business models require its greater acceptance ISTM - they've already made investment in DSD hardware and seek to differentiate their offerings in the market by adopting it.
I'm afraid we've gotten a little bit off topic. Regardless of how the DAC handles DSD internally, the question is: how do I get it there most reliably?
There's some code for the XMOS which can handle DoP. So, I gather you sent it over in the PCM container, and it gets converted back into a DSD stream, which is sent over to the DAC.
If I remember correctly, XMOS is asynchronous. So were you saying I don't even need any sort of reclocking for asynchronous?
There's some code for the XMOS which can handle DoP. So, I gather you sent it over in the PCM container, and it gets converted back into a DSD stream, which is sent over to the DAC.
If I remember correctly, XMOS is asynchronous. So were you saying I don't even need any sort of reclocking for asynchronous?
Wow, so the XMOS output should be entirely jitter free? Okay not "entirely" jitter free, but low enough to not worry about? I can just send it straight to the DAC?
Just playing devil's advocate, I see tons of stuff on here about FIFOs, and ASRCs, and even in other converters and interfaces, some of which use XMOS, I see stuff to combat jitter. For example, the Benchmark DAC1 I'm pretty sure uses PLLs AND uses XMOS. Are you saying all of that is entirely redundant?
Just playing devil's advocate, I see tons of stuff on here about FIFOs, and ASRCs, and even in other converters and interfaces, some of which use XMOS, I see stuff to combat jitter. For example, the Benchmark DAC1 I'm pretty sure uses PLLs AND uses XMOS. Are you saying all of that is entirely redundant?
No output from the XMOS chip itself is going to be any good (coz that re-syncs and adds jitter) but the master clock on their board is what you should send direct to the DAC yes. If its not the right multiple of the frequency then you'll need a low jitter divider (not a ripple counter).
As far as I'm aware the Benchmark does not only have USB input, it also receives AES-EBU and S/PDIF - both of these require a PLL.
As far as I'm aware the Benchmark does not only have USB input, it also receives AES-EBU and S/PDIF - both of these require a PLL.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.