To DSD or not to DSD?

[Miska]

question, for 384 KHz PCM recording at what frequency is the -120 dB level reached ?

 

You can calculate it by:

fs - passband = stopband

and thus

stopband - passband = transitionband

 

(RedBook is specified for 20.0 kHz passband while fs/2 is 22.05 kHz, rest is reserved for transition band)

 

For 22.05 kHz passband it would be 384000 - 22050 = 361950 Hz.

 

For high-res purposes, engineers usually want to extend pass-band as sampling rate is increased, instead of sticking to 20 kHz or so. Thus usually 96 kHz sampling rate is designed to give 45 kHz bandwidth and 192 kHz sampling rate about 90 kHz.

 

DSD64 was originally designed to have 50 kHz pass-band and 120 dB SNR, and thus given above formula -120 dB point needs to be at 2772400 Hz. Third order filter already gets you pretty close to this for which single op-amp is enough. For 384/24 PCM ADC, I would design 100 kHz pass-band with 144 dB attenuation and thus -144 dB point would need to reached at 284 kHz.

 

Different engineers design to different specs, so the exact numbers vary somewhat.

[Paul R]

This inefficiency of PCM does not apply if a lossless CODEC such as FLAC is used. Lossless CODECs send differences between samples, actually even better, they use a collection of previous samples to predict the likely next sample and then send the difference between the prediction and the actual sample. And to cover the case where the differences have a pattern, further data compression techniques are used (similar to those used to compress text) to compress the error samples. To get back the original audio the process runs in reverse: the compressed error data is uncompressed recreating the original error stream, then the previously decoded samples are run through the projector and the next error sample added to it to get the corrected next data sample, then the process is repeated on the next sample, etc...

 

Would you explain your idea a little more?

 

My first reaction is that the samples are decompressed and restored to the original LPCM format by the software music player before they are ever processed and sent on to a DAC, so little of this seems very relevant.

 

-Paul

[PeterSt]

Originally Posted by PeterSt

If so, is this (to be) covered for by an analogue filter in front of the A/D ?

 

If this is not the case, then genuine PCM A/D will do better because in that case the digital filter can be after the A/D with good effect.

 

 

You need to cut out everything above fs/2 for PCM A/D, because otherwise [...]

 

Miska, I emphasized it now.

About the time smear during the A/D process with SDM ...

[Miska]

Miska, I emphasized it now.

About the time smear during the A/D process with SDM ...

 

I don't understand what you are trying to say, especially first sentence in relation to second...

 

Time smear is defined by the analog anti-alias filter and possible digital decimation filter following the converter.

 

Full scale rise time of DSD64 is equivalent of about 120 kHz PCM and as the scale goes smaller it becomes faster. Thus if you aa-filter it with the spec'ed 50 kHz you have 10 kHz of extra safety margin making sure that slew rate is not limited the by ADC.

[Tony Lauck]

Would you explain your idea a little more?

 

My first reaction is that the samples are decompressed and restored to the original LPCM format by the software music player before they are ever processed and sent on to a DAC, so little of this seems very relevant.

 

-Paul

Lossless compression reduces the cost where it matters: on the server, downloading across the Internet, and stored in your music library. As you point out, there is no saving when it comes to the bandwidth between the processor that does the decoding and the DAC or the work done in the DAC itself. However, with modern interconnects such as USB the interconnection bandwidth is more than adequate and similarly for the circuitry in the DAC.

 

I am not disputing Tailspin's conclusion that more bits are needed for PCM than DSD, because that will depend on the specific formats that are being compared and one's personal judgment as to which PCM formats and DSD formats are comparable. I was merely pointing out that Tailspin's argument of sending differences vs. sending values was not applicable to PCM music distributed via lossless CODECs such as FLAC. Indeed, most hi-res PCM downloads sold on the Internet are sold in FLAC format. If you use FLAC compression the number of bits used for 192/24 PCM similar to that for DSD64.

 

 

For more details on how FLAC works, you can read the FLAC specification.

[Miska]

Full scale rise time of DSD64 is equivalent of about 120 kHz PCM and as the scale goes smaller it becomes faster. Thus if you aa-filter it with the spec'ed 50 kHz you have 10 kHz of extra safety margin making sure that slew rate is not limited the by ADC.

 

Just for the record, 1st order low-pass with fc=50 kHz is enough to keep DSD64 safe from that perspective.

[tailspn]

I was merely pointing out that Tailspin's argument of sending differences vs. sending values was not applicable to PCM music distributed via lossless CODECs such as FLAC. Indeed, most hi-res PCM downloads sold on the Internet are sold in FLAC format. If you use FLAC compression the number of bits used for 192/24 PCM similar to that for DSD64.

 

I agree. It's just that when the problems of PCM are reviled, and understood, it just doesn't pass the smell test with purists like me.

 

Technically though, there's all kinds of work-around's that have been developed over the years. For the most part, in the music production side of the biz, they're absolutely necessary. They're still no DAW DSD production tools available for recording post processing, leaving PCM the only alternative outside of analog pre or post.

[Hiro]

They're still no DAW DSD production tools available for recording post processing, leaving PCM the only alternative outside of analog pre or post.

 

What about the Sonoma DSD DAW? I believe there's still a chance it may get a DSD128 update one day...

[tailspn]

What about the Sonoma DSD DAW? I believe there's still a chance it may get a DSD128 update one day...

 

Sonoma, regardless of its bit-rate, can only do level changes and crossfades at DSD bit rates. Post production today requires far greater production operations to produce a commercial recording.

[Hiro]

Sonoma, regardless of its bit-rate, can only do level changes and crossfades at DSD bit rates. Post production today requires far greater production operations to produce a commercial recording.

 

In any event, as it has been pointed out before, all DSP features can be implemented in multi-bit PDM at 128Fs so the current situation is reflective only of the limited functionality of legacy PCM productions tools, rather then the PDM/SDM technology itself.

[tailspn]

In any event, as it has been pointed out before, all DSP features can be implemented in multi-bit PDM at 128Fs......

 

Please name one DAW with this capability at any DSD bit rate.

[Hiro]

Please name one DAW with this capability at any DSD bit rate.

 

Apparently, I haven't made myself clear. I said that all DSP functionalities 'can be' implemented in multi-bit PDM, not that all DSP features have already been implemented in muliti-bit PDM/DSD format. And that the current situation, with production tools limited to PCM-only DSP is reflective only of their limited functionality.

[tailspn]

I did. And it's great that there's technology theoretically capable of providing solutions. But music producers/engineers operate in the real world of available technology. They need tools they can use today to improve the sound quality of recordings. There's no DSD tools development work to my knowledge going on today towards that end.

[Hiro]

I did. And it's great that there's technology theoretically capable of providing solutions. But music producers/engineers operate in the real world of available technology. They need tools they can use today to improve the sound quality of recordings. There's no DSD tools development work to my knowledge going on today towards that end.

 

And so DSD recording remains a sole domain of purist direct-to-DSD projects (with analog pre or post mixing) and tape-to-DSD projects.

[tailspn]

And so DSD recording remains a sole domain of purist direct-to-DSD projects (with analog pre or post mixing) and tape-to-DSD projects.

 

Yes, but that includes a sizable acoustic music catalog. Certainly well above 1,000 releases. Also, any project that was post produced on a Sonoma, SADiE, or Pyramix with just editing and level changes (DSD Rendered level changes on Pyramix). These include most of the Telarc and Exton catalogs, and numerous limited release boutique labels.

 

It's not that it's impossible, or even difficult to produce an all DSD recording, especially acoustic music. The disappointing aspect is there's little call for it commercially. Most music consumers either don't know, don't care, or can't tell the difference. It's difficult to build a business on just the pure DSD fans.

[Superdad]

It's not that it's impossible, or even difficult to produce an all DSD recording, especially acoustic music. The disappointing aspect is there's little call for it commercially. Most music consumers either don't know, don't care, or can't tell the difference. It's difficult to build a business on just the pure DSD fans.

 

But none of that means it is not worthwhile for boutique DAC designers to embrace and explore new techniques and topologies which take advantage of freedoms inherent in high-rate, multi-bit SDM. Such can pay off when playing back both PCM and single-bit SDM (DSD) of any encoded rate. See my earlier post/question to Peter regarding this (http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/direct-stream-digital-or-not-direct-stream-digital-16093/index46.html#post355724).

[tailspn]

But none of that means it is not worthwhile for boutique DAC designers to embrace and explore new techniques and topologies which take advantage of freedoms inherent in high-rate, multi-bit SDM. Such can pay off when playing back both PCM and single-bit SDM (DSD) of any encoded rate. See my earlier post/question to Peter regarding this (http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/direct-stream-digital-or-not-direct-stream-digital-16093/index46.html#post355724).

 

Absolutely! It's a chicken and egg thing, and we're already seeing the effects. The better the playback systems become, the more aware are producers and engineers that they need to produce better sounding recordings to stay competitive, and market their projects.

 

In the last 3-4 years, the DAC designers/manufactures have largely out paced the recording industry in producing better, more natural sounding products. That's putting pressure on DAW manufactures to improve the sound quality of their products, or loose their customers to competition.

[Paul R]

Lossless compression reduces the cost where it matters: on the server, downloading across the Internet, and stored in your music library. As you point out, there is no saving when it comes to the bandwidth between the processor that does the decoding and the DAC or the work done in the DAC itself. However, with modern interconnects such as USB the interconnection bandwidth is more than adequate and similarly for the circuitry in the DAC.

 

I am not disputing Tailspin's conclusion that more bits are needed for PCM than DSD, because that will depend on the specific formats that are being compared and one's personal judgment as to which PCM formats and DSD formats are comparable. I was merely pointing out that Tailspin's argument of sending differences vs. sending values was not applicable to PCM music distributed via lossless CODECs such as FLAC. Indeed, most hi-res PCM downloads sold on the Internet are sold in FLAC format. If you use FLAC compression the number of bits used for 192/24 PCM similar to that for DSD64.

 

 

For more details on how FLAC works, you can read the FLAC specification.

 

Okay. I think Tailspin was talking about the difference when playing DSD vs PCM music, files but I see your point. Thanks.

 

I do feel that there is not much reason to compress files these days - storage and processor, and networking too, have far outstripped the needs of most music storage.

 

But for DSD files, which areor can be much larger indeed, you could easily store the DSD files on a compressed disk partition, or even on nearline storage that accomodates deduplication and compression. Either would gain the transmission and storage benefits you reference, without the need to use a format that requires uncompression before it can be used in a music player, like FLAC.

 

 

Yours,

-Paul

[Ipoci]

Peter,

what about a joint venture: Miska does the software part and you do the hardware part.

 

KR

 

Matt

 

This is my current dream … an audiophile grade DSC1 DAC optimized by PeterSt … with HQP as player !

 

I will be one of your first customers !

 

Have a nice day. Massimiliano

[manisandher]

Peter,

what about a joint venture: Miska does the software part and you do the hardware part.

 

Ha... having owned and used products from both parties for quite a number of years now, I'm not sure there'd be much 'synergy'. In the sense that I don't think there's much lacking on either party's part that the other could help with. Both Miska and Peter are more than capable in both the software and hardware departments. And it's the 'and' here that's so important. There are very, very few people on the planet with this kind of combined expertise, and to get the best out of computer audio, I think it's essential.

 

The biggest difference I can see is that Peter has become a hardware manufacturer, whilst Miska has avoided this (to date), but made his designs accessible (to his massive credit, IMO).

 

Not so long ago, I really wanted Peter to adopt Miska's NAA approach, which I felt was the way forward, having put together two NAAs myself (with Miska's help). But Peter found another (totally unique, of course) solution to isolating the DAC from the player PC.

 

No, rather than partnering together, I think we're all better served if Miska and Peter continue their sparring matches, push each other's thinking and take the whole of computer audio forward, in the sense of making the software and hardware work most effectively together.

 

Mani.

[PeterSt]

I don't understand what you are trying to say, especially first sentence in relation to second...

 

Time smear is defined by the analog anti-alias filter and possible digital decimation filter following the converter.

 

Full scale rise time of DSD64 is equivalent of about 120 kHz PCM and as the scale goes smaller it becomes faster. Thus if you aa-filter it with the spec'ed 50 kHz you have 10 kHz of extra safety margin making sure that slew rate is not limited the by ADC.

 

I think you understood Miska. But (see emphasized part) this thus means that there's an analogue filter in front of the whole (A/D) converter section ?

ALWAYS ?

[Miska]

I think you understood Miska. But (see emphasized part) this thus means that there's an analogue filter in front of the whole (A/D) converter section ?

ALWAYS ?

 

Yes...

 

How steep it needs to be depends on your ADC sampling rate.

[PeterSt]

Ha... having owned and used products from both parties for quite a number of years now, I'm not sure there'd be much 'synergy'. In the sense that I don't think there's much lacking on either party's part that the other could help with.

 

I know, I took out some relevant context. But this allows me to put a few things in my own words;

 

The first what came to my mind is "sparring" but then you said that yourself, Mani. And at least from my side this is fuel which to myself seems a very good thing. And it doesn't even need to happen from both sides, because when one side can contribute to the progress of audio as a whole, it already will be for the better.

Whether such an approach is the most efficient is something else. But you already hinted to that.

 

I think a form of co-operation is already going on but this goes in a very invisible fashion (and I mean even to us ourselves, mutually). On both sides things happened unsolicited (I think this is a negative word, but I mean it the other way around) and I can promise everyone that no single private email was spent, nor was the subject concerned ever mentioned. One exception : I hinted Miska about the DoP (then unknown) idea so he could be the first with it (and HQPlayer was as far as I know) coming along with my sort of "I have no time for this anyway". Easy enough because it was true and btw still is.

 

There is no way I will be able to "catch up" with all the work Miska has been done. There is also no way that I see myself more smart so I would be faster than him. But I also see no sense in spending the time into something which already has been done, and has been done very well. All it needs at some stage is this hooking up of products in a format yet unknown. But if I don't trust this to happen then I better trust nothing to happen because at some stage I can't do all.

 

For Miska this is not different but the focus is coincidentally the other way around. What I see is that he deserves a kit of hardware so his software can excel. And not for commercial reasons but to prove a being right. Mind you, all my own words and thinking but I think so myself. But do we ever know what it takes to design hardware that will be able to comply to the software specs ? I know, sounds odd, but if you first create software which is able to have digital noise specs somewhere at -200dB it would be nice if there's hardware that does do better than -100dB (I hope it is clear what I mean).

I lost counting, but my latest design will have taken something like 1200 hours or so. So envision that someone has to spend 1200 hours somewhere in between nice software development - which is thus impossible and will stop software development. This, while you know you are good at that software development. You have to make a choice ...

 

Back to myself ... No need to explain more I think. So I did the hardware and anticipated someone doing the software. No single word has been spent about it. So Miska doesn't even know.

I guess now he does ...

 

Time to put up my prepared post from two days ago in response to Alex C's suggestions. In the text you won't see all the way that it is about what I just told, but you now know it is.

[PeterSt]

Hi Peter:

 

I always appreciate your ideas and explanations. You and Miska are the only ones here presenting insights and facts based on real world testing, engineering, and evidence. I don't mind at all that you do not agree. I learn from you both.

 

 

I am curious to hear your thoughts about PDM in general--going beyond the problematic 1-bit instance of the format--versus limitations of PCM.

 

Since:

a) PCM1704K gets us only so far (though I do love my 1704K NOS box and look forward to someday running it up to 768KHz; stuck at 176.4/192 for the moment), and laser-trimmed resistor ladders are crazy-expensive (OEM price of MSB Platinum module? You don't want to know), and

 

b) We all agree that software or hardware algorithms to take data rates (of PCM or DSD) up into the tens of megahertz make things much easier for all DAC topologies, and

 

c) Wider PDM (8-to-40 levels or more) is quite attainable with low cost chips (NOT DAC chips!),

 

then maybe more effort could be concentrated there, leaving DAC designers more time to focus on clocking, isolation, output filters, and output stages (you two s/w designers already have the computer SRC/filter end handled nicely).

 

I guess my point is, that while I enjoy really good upsampled Redbook on my NOS PCM DAC (BTW, Miska's Polysinc filters are the BEST available in an OS X player for PCM--HQ Player is not just for the DSD crowd!), I'm looking forward to a 45MHz, 33 or 65-level thermometer PDM DAC. (Yes, I know we need to evolve computer audio data interfaces a bit first.)

This can all be done, and once built, I am sure both XXHigh-End and HQ Player would be the best two players to support it! (Perhaps by them both players' UIs will have evolved a bit as well )

 

 

Anyway, please keep the dialog going--and try not to let the closed-minded at both ends of the spectrum annoy you too much. (Audio is a lot like politics: the loud voices at both extremes do the least to advance progress or consensus.)

 

Regards,

 

Alex C.

 

Hi Alex,

 

Let's say that you picked up the message from that thread of mine I started (one of the very very few), so here is a small teaser for you.

 

 

 

 

 

As you can see I don't go as far as Miska as only 1/1000th of the whole design is shown here (haha), but about "best DAC's" ... this could be it. So 27 bits and resolves to the 25th bit *if* the noise specs as designed will be met. And I will know that soon.

 

I'm looking forward to a 45MHz, 33 or 65-level thermometer PDM DAC.

 

It won't be that because it will be "the same" as all there is (OK, about) and it would exhibit the same "DSD nastyness" as some see in it (this could include me ;-). Although I am fairly sure 22 MHz is possible (by later firmware upgrade) for now I'll stick to 11.2896MHz (or 12.288MHz for 48 based). But THEN it will be DSD without that noise - the one I referred to. So think sample and hold DSD.

Meanwhile it takes that same 11MHz (12MHz) for PCM input, meaning that today's "mighty" 16x Arc Prediction upsampling/filtering will do 256x. And yes, over a USB2 interface.

So crazy PCM (for upsampling) and redefined DSD over the exact same hardware and no intermittent conversions. And no analog filter anywhere either (at least this is not planned at this moment).

 

The above part about DSD is the mere vague description because I take it that it is possible to first turn a DSD stream into something I tend to call "stable", which means proper filtering. For that of course we depend on Miska so don't ask me at this moment how that part of it will work out. Maybe not at all, and then the DSD will be (upsampled) 45MHz. Also nice, but as said, "about the same as all". Doesn't intrigue me much.

 

The PCM part is a different story, because that will be turned into sheer DSD "principle" (modulated digital stream) and is explicitly meant to actually upsample PCM 256x, ending up in DSD played over the ladder DAC. This one should be easy to understand because it does the same as the current conversion of PCM to DSD but now without any of the cons of DSD itself (including the inexistent hardware modulator hence all under our control).

As a bonus this part will be able to play a 5MHz test signal with same THD result as today's 20KHz not upsampled (so fs/2 max). Not that this is useful by any means, but I mention it because there is no single way normal DSD is capable of this. Still, and this is the interesting part, by no means PCM is used to accomplish this; it is and remains "DSD" (though the source is allowed to be PCM).

The modulator for this is all working and proven (can restore original PCM and is thus also lossless).

Btw, the DAC can internally jump to PCM on an ad-hoc base (say per the sample) but this would violate good filtering aspects. So for example, when a one-time large transient is passing by it would be able to process that by means of a one-time PCM code. But I am not doing that because it takes out the fun (of for example being able to process mentioned 5Mhz which can't go automatically, knowing that at the same time it must be able to process e.g. 10Hz).

 

When we understand this a little, it is more easy to see how it can also do native DSD (further upsampled or not) because all can be done, and it is the software which determines the how. The DAC just processes it and the fact that each of the output samples (in voltage) is done by means of a ladder coded DAC does not make it PCM (just saying). It is only that it can process/output at a rate of 45MHz (49MHz) but interface bandwidth limits it (more for PCM-DSD conversion than for native DSD).

 

You and Miska are the only ones here presenting insights and facts based on real world testing, engineering, and evidence. I don't mind at all that you do not agree. I learn from you both.

 

So I have to say it again - not correct (about not agreeing) and hopefully this proves it. It is only that we have to go very far to make it all less compromised and it is that what I did. So what I say is that PCM to DSD conversion is better than native PCM but for an unexpected reason : bandwidth. Just think about how super large any 256x PCM file would be on disk (no PC will even be able to read all speedy enough) and how actually an e.g. 64x DSD file occupies the space of a 2x (or whatever) PCM. So same thing. In other words, upsampled/filtered Redbook 2x is better than not filtered at all, 4x is better again, my 16x is very nice, but 256x will be way better again. Meanwhile (and you must think this over) this *IS* DSD now because of the way it has to work. This is about the modulation. Thus, once we say that we only output a modulated digital stream, it just has become DSD. Simple as that. And what was the argument ? upsample more of PCM. What are we in lack of ? bandwidth. So what to do ? make it a modulated stream.

Crazy ?

No, logic. It is only that no such thing exists for D/A converter from any angle imaginable. And just saying - also not for discrete designs. Start with the precision of the resistors and have a good day with that alone. So no, also no compromise there or anywhere else, like a (well known) discrete design could tell you "hey, all discrete - but sorry, resolves to 14 bits only and hey, still sounds better".

Crazy ? OK, Yes.

[Miska]

It won't be that because it will be "the same" as all there is (OK, about) and it would exhibit the same "DSD nastyness" as some see in it (this could include me ;-). Although I am fairly sure 22 MHz is possible (by later firmware upgrade) for now I'll stick to 11.2896MHz (or 12.288MHz for 48 based). But THEN it will be DSD without that noise - the one I referred to. So think sample and hold DSD.

 

Challenge with high speed high-bit conversion is settling time. Because the converter voltage needs to settle to within ½ LSB in fraction of the sample period for the LSB to be useful. (at high speed the glitch energy could cause overshoot energy to span several LSBs)

 

For this reason converter manufacturers have went the SDM route, so the number of levels is small and conversion rate high.

 

For the interested, there's a good introductory document from AD here:

http://www.analog.com/static/imported-files/tutorials/MT-013.pdf