[analogsurviver]

  I'm becoming quite confused as to where the noise is actually occurring......
 
If we're talking about a purely digital operation - like converting a DSD file into a PCM file using Audiogate - then that is not a real time operation. Within reason, even a very slow computer should be able to do a perfect job, even though it might take a lot longer to finish. If that's what we're talking about, then all this talk about "reaching the computer's limit" is meaningless unless a specific piece of software simply faults when asked to perform certain conversions. 
 
HOWEVER, then I see it mentioned that "there is a good outboard DAC connected". If we're talking about having a program convert the DSD file into PCM "on its way to the DAC" rather than writing the output to a file, then this isn't implausable at all. Transferring digital audio to a DAC most certainly IS a real-time operation, and overtaxing the computer most certainly CAN result in odd noises coming from the DAC - because the computer has become unable to deliver a steady stream of numbers to the DAC. This typically results in what I tend to refer to as a "screeching" or "chittering" noise. This noise is being caused by the computer sending a non-continuous stream of audio information to the DAC, and is the result of the DAC then trying to decode this defective audio stream.
 
The important point here is that this should ONLY occur when we're playing audio through the DAC... and should NEVER occur if we're doing simple file operations. In other words, it could happen if you were playing a DSD file through a PCM DAC - and letting the player program do the conversion as the file is played. In that case, it's quite possible that the choice of using certain filters in the player could make the difference between the computer delivering a steady stream of audio to the DAC or failing to do so. However, it should NEVER occur if you were to convert the DSD FILE into a PCM FILE, then play the resulting PCM file... and the distortion should never be present in the PCM file itself. (I recall trying a certain player program which offered the option of upsampling the audio as it was played, and offered several filter choices. Some of those filters required so much processing power that my quad-core desktop computer with 8 gB of RAM wasn't capable of playing audio using them - and produced the characteristic chittering noise after a few seconds whenever it tried. Again, note, though, that the error was occurring inside the computer, to the audio stream on its way out to the DAC - and there was no flaw or error present in the actual file that was playing.

You are correct - converting DSD file to PCM file and then playing back should not result in any such increase of noise - it will just take so much longer to convert.
 
REAL TIME converting and playing  (from DSD to PCM, as in Korg Audiogate - or vice versa in jRiver19 , for example ) or so called converting in the fly IS another matter. jRiver specifies PRECISELY
http://wiki.jriver.com/index.php/Windows_System_Requirements
how much computing power you got to have
http://yabb.jriver.com/interact/index.php?topic=54396.0
in order to use the software in full measure - and will stutter, noise and hiccup if it is not met. 
 
FFT IS more demanding than just simple playback of 192/24. For those who think this is another audiophile myth, load Foobar2000 and start using graphic features like VU meter, spectrogram, etc, etc - and you should reach a point, sooner or later, when things will start sliding downhill.
 
Except if you have infinite computer power.

 

[castleofargh]

that's just showing once again how much DSD is a stupid choice for file format.

 

[lamode]

Originally Posted by analogsurviver /img/forum/go_quote.gif
 
converting DSD file to PCM file and then playing back should not result in any such increase of noise - it will just take so much longer to convert.

 
The CPU load of the conversion will be the same whether the conversion is saved as a file or transferred to a DAC. There is no reason why it should take "so much longer" to convert to a PCM file.

 

[lamode]

  that's just showing once again how much DSD is a stupid choice for file format.

 
"Stupid" is a strong word, but I'd agree that DSD is certainly inferior and should be allowed to die off ASAP.

 

[analogsurviver]

   
The CPU load of the conversion will be the same whether the conversion is saved as a file or transferred to a DAC. There is no reason why it should take "so much longer" to convert to a PCM file.

True.
 
What I wanted to underline is that it IS POSSIBLE to convert the file on a slow low computing power machine - and then play it back. Taking all the time in the world if required.
 
It is NOT POSSIBLE for the same machine to convert it on the fly - it is perfectly possible to get the noise as heard and seen in that FFT example. 
 
The same file on a more powerful computer would get converted much faster - and would be playing the conversion on the fly without any problems.
 
Please clinging to straws - for the task at hand, computer either does the performance required - BUT I HAVE NEVER SEEN ONE NOT AT LEAST TO TRY TO DO IT - noising, stuttering and so on and so forth in the process..
Not a SINGLE one waved the white flag by displaying message to the effect:
" Chosen application exceeds the capabilities of this machine"

 

[analogsurviver]

  that's just showing once again how much DSD is a stupid choice for file format.

It is different, it is much more data, it can be accused of being inefficient, etc, etc, etc.
 
It most definitely does require MUCH more computer power.
 
It most definitely requires MUCH more storage. 
 
Yes, true. Please note the minimum DSD I consider to be usable is DSD128 -twice the SACD sampling, DSD64.
 
But if the end result mops the floor with the CD redbook - it is all that matters.
 
You can call it crazy - but most definitely not stupid. 
 
Higher sampling rates of PCM place very similar requirements on the computer.

 

[Head Injury]

  But if the end result mops the floor with the CD redbook - it is all that matters.

It doesn't, though.

 

[StanD]

Originally Posted by analogsurviver 
 
But if the end result mops the floor with the CD redbook - it is all that matters.
 
Originally Posted by Head Injury /img/forum/go_quote.gif
 
It doesn't, though.

I get a head injury reading some of his claims. 

 

[stv014]

Higher sampling rates of PCM place very similar requirements on the computer.

 
That is not entirely true, because processing DSD (such as downsampling it to a saner format) has to run at the MHz range sample rate of the DSD, and does not really benefit computationally from the lower resolution. 192/24 is still smaller than DSD128 by about 18%, and converting it at high quality to/from 44.1/16 can easily be done in real-time on any CPU that is not very outdated (there are some old 44.1->96 benchmarks here, 192 kHz is twice as expensive in theory).

 

[cel4145]

It is different, it is much more data, it can be accused of being inefficient, etc, etc, etc.

It most definitely does require MUCH more computer power.

"Much more computing power" than what? You specified a netbook as being a problem earlier on, but those are very, very, very weak machines. What's the actual proof of how much computing power it needs. That JRiver Wiki page you provided was useless. Their minimum system requirements look like they were written years ago. And their recommended system? No one should have to have a solid state drive, which means they are just pulling a fast system out of hat. Meanwhile, the benchmarks list forum page tells one nothing about what's necessary to do the DSD conversion.

But if the end result mops the floor with the CD redbook - it is all that matters.

But where is the proof? So how are you going to test this theory of yours? Just because you believe it is true doesn't make it true. Provide evidence.

 

[maverickronin]

  FFT IS more demanding than just simple playback of 192/24. For those who think this is another audiophile myth, load Foobar2000 and start using graphic features like VU meter, spectrogram, etc, etc - and you should reach a point, sooner or later, when things will start sliding downhill.
 
Except if you have infinite computer power.

 
 
It's not a myth but you've got to have a pretty ancient computer or be running a crapload of effects before it becomes an issue.  Real time audio processing is pretty trivial on vaguely modern CPUs.
 
OTOH real time video processing will crush most cpus.  I'm doing my best to keep myself form upgrading to a hex or octo core i7 so I can tweak my Avisynth SD video upsampling script for even better quality.
 
 

 #MT SUPPORT SETUP
    SetMemoryMax(1024)
    SetMTMode(3,0)
    ffdshow_source()
    SetMTMode(2,0)
#GET CLIP PROPERTIES
    SD = (Width<1280) \
        ? True \
        : False
    p720 = (Width>=1280 && Width<1920) \
        ? True \
        : False
    p1080 = (Width==1920) \
        ? True \
        : False
    ar=float(ffdshow_dar_x)/float(ffdshow_dar_y)
    diff=ar-1.5555
    WIDE = (diff >= 0) \
        ? True \
        : False
    #Subtitle("SD is " + string(SD) + ", 720p is " + string(p720) + ", 1080p is " + string(p1080) + ", Wide is " + string(WIDE))
#CALL FILTERS AFTER HERE
#PRE-RESIZE DENOISE
    fluxsmoothst(7,7)
#RESIZE
    WIDE==True \
        ? ffdshow_setDAR(16,9) \
        : ffdshow_setDAR(4,3)
    SD==True && WIDE==True ? Eval("
        BicubicResize(1920,1080)
        ") \
    : nop()
    SD==True && WIDE==False ? Eval("
        BicubicResize(1440,1080)
        ") \
        : nop()
    p720==True && WIDE==True ? Eval("
        LanczosResize(1920,1080,4)
        ") \
        : nop()
#BLUR
    SD==True ? Eval("
        binomialBlur(3,3)
                                #gaussianblur(vary=3,varc=3,border=4,integrate=true)
        ") \
        : NOP()
#SHARPEN
    SD==True || p720==True  ? Eval("
        aWarpSharp(24,4,.5,1)
        ") \
        : NOP()
    SD==True ?  Eval("
        Tunsharp(64,2,32,1, radius = 3)
        ") \
        : nop()  
#MT SUPPORT FINNISH
    SetMTMode(1)
    GetMTMode(false) > 0 \
        ? distributor() \
        : last

 
(BTW... is there <code> button I'm missing?)
 
This is the very bleeding limit of what my 3.7GHz quad core i7 can reliably manage when upsampling SD video to 1080p.  I'd like to use higher quality blur and sharpen options that my cpu just can't handle, hence the dreaming about an upgrade that could probably buy me a used pair of Omega II's...
 
Audio is a walk in the park in comparison because there's just less data to work with.  192 thousand samples per second times 24 bits per sample time two channels is 9216kpbs.  For 1080p video you have 1920 pixels wide times 1080 pixels tall times 12 bits per pixel (for the common video YV12 color format) times an approximate 30 frames per second (varies by source, DVD, blu, HDTV channel etc) is 746496kbps or 81 times as much data. 
 
That's not even a fair comparison because 192/24 is pretty over the top compared to 1080p video.  4k video might e a fair comparison would have 4 times as much data as 1080p video for a whopping 324 times as much data as 192/24 audio.  Also, if you some kind of "video purist" in the same vein as those who believe that 24 bit is a better playback format for audio than 16 bit then you'd probably want to use 32 bit RGB colorspace instead of 12 bit YV12 and need to multiply all those numbers by another 2.67.
 
As a foot note, you might notice that video on your hard drive doesn't take up this ludicrous amount of space.  That's because it all compressed with what amount to the same kinds of lossy compression that MP3s use for audio.  While it seems no one around here can stand any kind of (data) compressed audio but you hardly hear a peep about poor quality video compression or demands for lossless video formats...
 

 

 

[analogsurviver]

   
 
It's not a myth but you've got to have a pretty ancient computer or be running a crapload of effects before it becomes an issue.  Real time audio processing is pretty trivial on vaguely modern CPUs.
 
OTOH real time video processing will crush most cpus.  I'm doing my best to keep myself form upgrading to a hex or octo core i7 so I can tweak my Avisynth SD video upsampling script for even better quality.
 
 
(BTW... is there <code> button I'm missing?)
 
This is the very bleeding limit of what my 3.7GHz quad core i7 can reliably manage when upsampling SD video to 1080p.  I'd like to use higher quality blur and sharpen options that my cpu just can't handle, hence the dreaming about an upgrade that could probably buy me a used pair of Omega II's...
 
Audio is a walk in the park in comparison because there's just less data to work with.  192 thousand samples per second times 24 bits per sample time two channels is 9216kpbs.  For 1080p video you have 1920 pixels wide times 1080 pixels tall times 12 bits per pixel (for the common video YV12 color format) times an approximate 30 frames per second (varies by source, DVD, blu, HDTV channel etc) is 746496kbps or 81 times as much data. 
 
That's not even a fair comparison because 192/24 is pretty dame over the top compared to 1080p video.  4k video might e a fair comparison would have 4 times as much data as 1080p video for a whopping 324 times as much data as 192/24 audio.  Also, if you some kind of "video purist" in the same vein as those who believe that 24 bit is a better playback format for audio than 16 bit then you'd probably want to use 32 bit RGB colorspace instead of 12 bit YV12 and need to multiply all those numbers by another 2.67.
 
As a foot note, you might notice that video on your hard drive doesn't take up this ludicrous amount of space.  That's because it all compressed with what amount to the same kinds of lossy compression that MP3s use for audio.  While it seems no one around here can stand any kind of (data) compressed audio but you hardly hear a peep about poor quality video compression or demands for lossless video formats...
 

 

   
 
It's not a myth but you've got to have a pretty ancient computer or be running a crapload of effects before it becomes an issue.  Real time audio processing is pretty trivial on vaguely modern CPUs.
 
OTOH real time video processing will crush most cpus.  I'm doing my best to keep myself form upgrading to a hex or octo core i7 so I can tweak my Avisynth SD video upsampling script for even better quality.
 
 
(BTW... is there <code> button I'm missing?)
 
This is the very bleeding limit of what my 3.7GHz quad core i7 can reliably manage when upsampling SD video to 1080p.  I'd like to use higher quality blur and sharpen options that my cpu just can't handle, hence the dreaming about an upgrade that could probably buy me a used pair of Omega II's...
 
Audio is a walk in the park in comparison because there's just less data to work with.  192 thousand samples per second times 24 bits per sample time two channels is 9216kpbs.  For 1080p video you have 1920 pixels wide times 1080 pixels tall times 12 bits per pixel (for the common video YV12 color format) times an approximate 30 frames per second (varies by source, DVD, blu, HDTV channel etc) is 746496kbps or 81 times as much data. 
 
That's not even a fair comparison because 192/24 is pretty dame over the top compared to 1080p video.  4k video might e a fair comparison would have 4 times as much data as 1080p video for a whopping 324 times as much data as 192/24 audio.  Also, if you some kind of "video purist" in the same vein as those who believe that 24 bit is a better playback format for audio than 16 bit then you'd probably want to use 32 bit RGB colorspace instead of 12 bit YV12 and need to multiply all those numbers by another 2.67.
 
As a foot note, you might notice that video on your hard drive doesn't take up this ludicrous amount of space.  That's because it all compressed with what amount to the same kinds of lossy compression that MP3s use for audio.  While it seems no one around here can stand any kind of (data) compressed audio but you hardly hear a peep about poor quality video compression or demands for lossless video formats...
 

All valid points.
 
I merely wanted to present HOW that noise in FFT could originate. That recording from Linn is from Christmas 2013 free downloads and DID, DOES and WILL play back without that increase in noise on any capable enough machine. As you noted, it is not too difficult or expensive to achieve this - but it is mre demanding than redbook. FFT certainly is harder requirement and does tax computer more than mere playback - and CAN overtax the capabilities available, resulting in such noise.
 
Since you are running computer for video, such low requirements may well seem petty to you; there are not for some others. Certainly not for those accustomed to the requirements that are barely enough for redbook - or slightly more. You need not go too far back to find 192/24 uncapable machines.

 

[analogsurviver]

   
That is not entirely true, because processing DSD (such as downsampling it to a saner format) has to run at the MHz range sample rate of the DSD, and does not really benefit computationally from the lower resolution. 192/24 is still smaller than DSD128 by about 18%, and converting it at high quality to/from 44.1/16 can easily be done in real-time on any CPU that is not very outdated (there are some old 44.1->96 benchmarks here, 192 kHz is twice as expensive in theory).

Of course not. Each one can figure on his own how much is required for each format.
 
Trouble is, PCM has got to be MUCH higher sampling in order to allow anything like shallow filters possible for DSD and phase response ( ot whatever it is correctly called - we all know what is meant ) for both being roughly similar to quite high frequencies. Then it is several times bigger than DSD128. 
 
Each format has its pros and cons, I would choose 192/24 over DSD64 any day in the week. By judging what is still manageable one can reach a sensible compromise.
Sky is the limit - DSD512. No filtering required anymore, de facto almost instantaneous pulse response/close to zero rise time, not as implied by (you?) for the redbook - prior to output filtering. Not at the actual analog output, as with DSD512. In other words - an almost perfect recording, past any chance humans could possibly hear its defects either in frequency response or dynamic range. Finally, something limited by people operating such equipment, not the other way around.
 
Once upon a time, a computer was the size of the room, with several technicians required only to constantly change its failing tubes. Now, we already have DSD capable audio players that fit easily into a pocket - like Astell and Kern, Chord Hugo etc - but are still quite pricey and capacity to carry much music is still limited.
 
But in 10 years - WHO knows ? 

 

[maverickronin]

  I merely wanted to present HOW that noise in FFT could originate.

 
A slow cpu still can't cause that.
 
If it's to slow to play the file, or to run the FFT, it's just going to stutter and skip.  It's not going to act completely normal except for adding random and/or spurious tones to the FFT output.

 

[analogsurviver]

   
A slow cpu still can't cause that.
 
If it's to slow to play the file, or to run the FFT, it's just going to stutter and skip.  It's not going to act completely normal except for adding random and/or spurious tones to the FFT output.

You can download , now for free, 
 http://www.korg.com/us/products/audio/audiogate3/ This soft will work in "lite load" and "high quality" modes - but high quality requires autechnication by connecting a Korg recorder or DAC. There IS one hell of a difference between the two versions - both in SQ and in how much will your computer "sweat".
 
There are settings in Audiogate for the format you want to listen DSD files in. From 192/24 all the way down to MP3 96 kbps - and everything in between. You can quickly find that some less capable computers will start to noise whenever too fast sampling will be selected - and things toughen up by the use of high quality mode.
Sometimes, a high quality mode and lower sampling is preferable to light load and 192 sampling. Audible on laptop speakers.
 
At the very bottom of the page, there is a link for downloading the last Audiogate V.2.x - it is less strain on the computer than V.3.x - but also less fine sounding.
Playing with any of these can quickly find the spot where a computer might start acting normal while adding noise - even if it will not stutter at all. 
 
Experience from > 20 instalations to various computers. Latest ones usually perform without a single hiccup - while some older can not work, even if and when Audiogate is the only thing running - no internet, no nothing. And everything in between.
 
 
That on your PC or MAc and your DAC - even if it is DSD capable. DSD playback (for now) possible using Audiogate only with Korg DSD DACs.