John Curl's Blowtorch preamplifier part III

Status
Not open for further replies.
I’m sure there’s something here for Scott 😀
 

Attachments

  • 7FD65B1B-38DB-4500-9FCA-63F8C27650A1.png
    7FD65B1B-38DB-4500-9FCA-63F8C27650A1.png
    896.7 KB · Views: 213
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:
Can you describe the difference in sound between these files?
Hello Ben. Yeah, as per my recent post -
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.
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.
Goop on system earth planes and earth connections changes system sound......something very interesting is going on.

That's a fascinating hypothesis. I can only wonder how it can be tested.
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.

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.
 
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.
 
Status
Not open for further replies.