That's great, would definitely show up in measurements, 100% certain of that.I fully agree that theoretically this should not be happening, but in practice I find that it does and on any system and before there are any ABX etc nonsense calls this has been proven without doubt, ie 100%.
Can you describe the difference in sound between these files?
This is good, you seem to have some kind of hypothesis (or "theory" if you like), As mentioned in another post, the actual data is played back from RAM. Also as mentioned, MS Windows and Linux are not RTOSs, and the common way to make up for that is making a RAM buffer substantially larger than it would need to be in an RTOS, so that the buffer won't run out (causing the sound to stop) if the processor(s) spends an inordinate amount of time on another task.
That's a fascinating hypothesis. I can only wonder how it can be tested.
Just one nit to pick - an RTOS doesn’t mean faster response or lower latency. An RTOS just implies bounded latency. For example, QNX is an RTOS, but the performance is lower than Linux in many cases because there are tradeoffs required to achieve that guarantee. In the case of QNX, device drivers are in user space which can have a performance impact.
Linux and Windows do have schedulers capable of preemption of user processes, but the kernels / kernel threads are not by default. You can also apply the full PREEMPT_RT Linux kernel patch to get closer to an RTOS, but you’ll find it doesn’t normally improve anything.
Last edited:
...As mentioned in another post, the actual data is played back from RAM...
That may depend a lot on particular driver implementation. Also, KSTR has taken measurements to show that cheap dac sound quality can be very slightly affected by where data is stored. He described the measured effect as being less than anyone would likely be able to hear, but the fact remains as other posts have acknowledged that such an effect is not impossible. That said, it should not be a problem with newer computer equipment and reasonably good dacs, even for very perceptive listeners.
Last edited:
Hello Ben. Yeah, as per my recent post -Can you describe the difference in sound between these files?
The subjective improvements are akin to reduction in system jitter and quieter power supplies with more extended highs and more extended lows, greater clarity and finesse in sound and quietness between notes etc and above all much better conveyance of groove/emotion factor. Here's those Test Dept - Two Flames tracks again to give you some idea of the kind of differences I'm talking about.
Goop on system earth planes and earth connections changes system sound......something very interesting is going on.This is good, you seem to have some kind of hypothesis (or "theory" if you like), As mentioned in another post, the actual data is played back from RAM. Also as mentioned, MS Windows and Linux are not RTOSs, and the common way to make up for that is making a RAM buffer substantially larger than it would need to be in an RTOS, so that the buffer won't run out (causing the sound to stop) if the processor(s) spends an inordinate amount of time on another task.
I have loopback recordings of standard cable and Gooped cable. The Test Dept tracks linked above are the original file converted to 24bit and the GC file is 24bit loopback recording using Gooped Cable. Of course the loopback recording has added distortion and noise compared to the original but I find that overall it sounds much preferable with changes as described above, and the background noise of the original is subjectively quieter and less apparent in the loopback recording.That's a fascinating hypothesis. I can only wonder how it can be tested.
Dan.
That may depend a lot on particular driver implementation. Also, KSTR has taken measurements to show that cheap dac sound quality can be very slightly affected by where data is stored. He described the measured effect as being less than anyone would likely be able to hear, but the fact remains as other posts have acknowledged that such an effect is not impossible. That said, it should not be a problem with newer computer equipment and reasonably good dacs.
It doesn’t depend on any implementation. On a regular PC there is no way for the data to go from a storage device to a peripheral without passing through RAM. For example, you can’t send data directly from a drive to a USB peripheral without it passing through RAM - even if you have not allocated any buffers in your application.
This is something that has been discussed before. Is there some reason you have in mind to go over it again?
Exactly the same reason we keep going over all the other things. Bybee, feedback, bit perfect copies that somehow sound different, discrete vs IC, the list is endless my friend.
It doesn’t depend on any implementation. On a regular PC there is no way for the data to go from a storage device to a peripheral without passing through RAM. For example, you can’t send data directly from a drive to a USB peripheral without it passing through RAM - even if you have not allocated any buffers in your application.
That is true, but a driver may determine the quality of buffering in some cases. Certainly, there were problems like that in the old days. Even today, I have heard some weird issues related to HQplayer and ASIO drivers on Windows when high sample rate DSD is involved. The problems are intermittent and generally respond to unplugging and replugging the cable to the USB board and or restarting HQplayer.
Then there are KSTR's measurements of cheap USB-powered dac(s) that had the power supply modulated depending on data storage location, and it affected the audio output.
I know its easy to say bits are bits so there can be no errors, it either works or doesn't, but that isn't always the case in reality. You know.
Best post ever! 😀Exactly the same reason we keep going over all the other things. Bybee, feedback, bit perfect copies that somehow sound different, discrete vs IC, the list is endless my friend.
Exactly the same reason we keep going over all the other things...
Because we have short memories? Because they are controversial topics, and that makes them fun to argue about?
yes, fer sure.... some will threaten your manhood. Some will tell you, you are crazy or worse. But go ahead anyway 🙂
Richard, thanks for the tubes, and best wishes on your move to Thailand. I hope your health situation has stabilized. I won't be posting here any more, there is too much unpleasantness and bickering. Regards.
...best wishes on your move to Thailand...
Yes, sorry to see Richard leave the area. Probably a needed change for Richard and Lisa though, hope it works out for the best. I think it probably will. They know Thailand very well, and have friends there.
Because we have short memories? Because they are controversial topics, and that makes them fun to argue about?
I have no idea, do you? 🙂
I have no idea, do you?
The two I mentioned come to mind.
The reason I mentioned short memories is because some of the same tired old arguments that have been debunked on both sides get repeated all over again from the start. We never seem to pick up from where we left off.
It wouldn't be much fun to argue about things that weren't controversial, also it would be quite hard.Because they are controversial topics, and that makes them fun to argue about?
I am fully scientific in my outlook and yes valid proofs are the result of good science.
Then why do you keep sharing unscientific, anti-scientific, and pseudo-scientific posts from unreliable sources? There is nothing scientific about that.
It wouldn't be much fun to argue about things that weren't controversial
Like Goop

Last edited:
Then why do you keep sharing unscientific, anti-scientific, and pseudo-scientific posts from unreliable sources? There is nothing scientific about that.
Because its the only kind of science that backs up his half baked theories, and impossible results.
- Status
- Not open for further replies.
- Home
- Member Areas
- The Lounge
- John Curl's Blowtorch preamplifier part III