|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
66.220.116.223
In Reply to: RE: A week with the iFi Micro iDSD posted by Sprezza Tura on November 20, 2014 at 08:59:51
DACs should mute when switching from DSD to PCM and back.
Follow Ups:
Steve,
> DACs should mute when switching from DSD to PCM and back.
The iDSD micro does mute when switching, the problem is DoP.
If ONE DoP marker is missing (read one sample) the system switches back to outputting PCM.
What this means to a DAC that processes DSD natively (without conversion into intermediate formats) is that the DAC becomes in effect stuck at one rail. When it has been switched to PCM this full scale DC offset is suddenly cleared.
The problem is that all happens within one sample. Even with interrupt and fast MCU it is often not possible to catch this stream change before it has put a full-scale pulse through the system, as the this pulse happens at the instant the stream changes.
This is just too short to engage analogue mute and digital mute will not help, as the DAC needs to be reconfigured between PCM and DSD. J-River on Windows (not sure about Mac) implements a suitable mechanism to make DoP stream changes do not cause big clicks as well.
When using DSD via ASIO this does not happen as there is a better management of how the stream change is indicated. one might say that when the Spec for DoP was written it never considered the situation where a DAC has to be reconfigured. At any extent, it being dealt with in firmware and will resolved as soon as we can.
Ciao T
At 20 bits, you are on the verge of dynamic range covering fly-farts-at-20-feet to untolerable pain. Really, what more could we need?
This is a design flaw with DoP. This is why I previously characterized DoP as a kluge. Perhaps a better assessment is that DoP is a bad kluge.
This is not your fault. Other DACs have the same problem. Good luck at coming up with a workaround that minimizes this problem, but I doubt that there is a real solution to it other than the best solution: don't use DoP.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Why can't you use native DSD?. DSD to PCM at 352.8k is not bad either.
"Why can't you use native DSD?. DSD to PCM at 352.8k is not bad either."
I use native DSD. I tested DoP and found that it didn't work so well. I agree that downsampling DSD to PCM at 352.8 is not bad, but I wouldn't call it good.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Sounds fine in my system; may be it's your player. See thishttp://www.audioasylum.com/forums/pcaudio/messages/14/140707.html
Edits: 11/22/14
My DAC doesn't play 352.8. So I had to reconvert to DSD. It is possible that most of the degradation that I heard came on the reconversion to DSD rather than the downconversion to 352.8.
I do know that conversion from DSD to 352.8 and back to DSD is not transparent, as can be determined by playing the two files. Also, this is known by recording engineers such as the people at Channel Classics. As a result they try to do all the mixing in the analog console connected to the microphone preamplifiers so they can issue pure DSD recordings. Sometimes, however, it is necessary to remix and this involves the trip through 352.8.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Tony,
I commented on this elsewhere (in a "popular science" level article attached to an interview in Audiostreams).
If we convert DSD to PCM and back, no matter what rate and bitdepth (and no matter where the conversion takes place) we incur losses. In effect we get the worst of both formats and best of non, same for the PCM-> DSD-> PCM case.
A in my experience A SINGLE conversion is acceptable if done at high enough level of quality.
Example 1 - Convert DSD to PCM at 176.4KHz and 24 Bit and play this back using a pure PCM DAC (read multibit) without additional digital filtering and result is very good, not identical but I have no DAC that can make this comparison truly fair, so I suspect it is more DAC differences than anything else.
In my system I have so far preferred this to any "DSD DAC" playing it as DSD, but as said this may be down to the DAC's than the format. I have BTW not preferred it to native 176.4/24 PCM recordings (that is multibit SAR type ADC sourced) made without digital filter though (there are a few).
But once you introduce digital filters (especially brickwall type) or other manipulation the sound reverts to generic PCM for either source.
Example 2 - Convert PCM (say 176.4/24) to DSD256 or DSD512 (I find DSD and DSD 128 insufficient) and play this using a DAC that leaves DSD in native, unmanipulated format and the results are very good.
Using DSD(64) especially introduces that distinct DSD sound, which to me is an acquired taste. At DSD256 (11.3MHz) I find it hard to tell if I am listening to the DSD256 converted version or the original PCM played back without digital filter, at DSD512 (22.6MHz) I am not betting a red penny either way.
But using double conversion in either case (so to PCM to DSD512 and back to PCM or DSD to PCM and then back) is always readily audible to me, regardless of other preferences.
Bottom line, ideally play DSD as DSD and PCM as PCM, with no domain conversion. If you must convert (e.g. because your DAC does not support DSD and it plays PCM which is > 80% of your music collection better than anything else for your taste or because your DAC is DSD only etc.) keep the conversion singly and as high quality as possible.
There are large differences in the possible algorithms DSD-> PCM or PCM-> DSD between for example Weiss Saracon, J-River MC and ASIO-Proxy (PCM-> DSD only).
ASIO-Proxy is notionally for foobar but applicable to any ASIO capable player and DAC on Windows
Of course, anyone who took Information Theory 101 or has one of the least common of all senses will hardly be surprised by this.
Ciao T
At 20 bits, you are on the verge of dynamic range covering fly-farts-at-20-feet to untolerable pain. Really, what more could we need?
While in general I agree with you about PCM/DSD conversions and vice versa, it is a bit different at the production level.Analog tapes captured to DSD or native DSD recordings produced as Redbook CDs can sound quite good.
Case in point: The pricey Japanese SHM CDs which are made from flat transfers from master tapes, converted to 176.4 for mastering, then finalized as a CD. They are using SOTA SRC and the end results are superb. Those SHM discs sound very analog.
One of Sony's original papers on DSD noted that it was an excellent capture tool from which other digital formats could be commercially produced and even hints at the fact that this what it may have originally been intended for.
Edits: 11/23/14 11/23/14
Hi,
I would not agree consider DSD "an excellent capture tool for other digital formats".
What Sony got right was to store the modulator output as master, not the converted version decimated to PCM, especially given the available filter technology in the 90's.
What they got wrong though was to use a 2-Level modulator at 2.8MHz.
Even with 1990's tech a capture at 8-Bit/11.3MHz would have been possible. A capture at 24-Bit/176.4kHz without digital filtering was commercially possible back then.
Either would have been a hugely better choice...
Ciao T
At 20 bits, you are on the verge of dynamic range covering fly-farts-at-20-feet to untolerable pain. Really, what more could we need?
Tony,
I agree, DoP is a cludge.
But if it can be made to work like on ESS DAC without resorting to broad spectrum re-sampling, async sample rate conversion etc., it is not a problem.
As we found playback software other than J-River not very open to help fix it on the playback side we put our software team on this.
Right now we have the problem 60-70% licked already. We know how to fix the rest, it just means re-writing/restructuring many lines of code which tend to have knock on effects and then testing the heck out of the code.
And yes, the fixes will be available to all DSD capable iFi devices.
Ciao T
At 20 bits, you are on the verge of dynamic range covering fly-farts-at-20-feet to untolerable pain. Really, what more could we need?
Good luck with the software updates, I hope you don't run into a "squeezing a balloon in a suitcase" situation where fixing one part of the problem pops out another part that was previously OK.
The problem you mentioned concerned robustness of the coding in the face of data errors. There really is no excuse for data errors on a USB connection, but there are still opportunities for problems, e.g. unwanted mode switches due to buffer underruns at the computer. These errors depend on the size of device driver buffers, etc... Some years ago when I was playing with DoP on my Mytek I was able to cause these problems by deliberately overloading the computer and causing buffering errors. The results seemed to depend on buffer sizes. I didn't investigate further, since I normally use ASIO and the driver allows native DSD over USB. Early versions of the Mytek driver and firmware had horrible pop problems on wanted and unwanted mode switches, but later revisions cured this. (The only pops that I get now come if I turn off the DAC without powering down my powered monitors.)
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Yes, they should.
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: