[malthis]

Source First!!!
Recently tweaked my PC to death, and thought I'd share my findings with the community: 
Note, this is all external DAC, USB to Matrix mini-i.  WAV only.
 
Windows 8 developer preview (better sounding than Win7!  More transparent)  Don't ask me why, but this is what I've found.  Maybe it's using less resources, therefore, less noise in the system.
 
Pureplayer (http://www.purediy.gr/downloads/pureplayer.zip) which is shockingly more revealing than Foobar.  This is the player I use when nothing but the best presentation will do.  Amazing soundstage.  Everything else sounds flat in comparison.   
 
Fidelizer ( http://www.windowsxlive.net/fidelizer ) allowed the music to come out from behind a veil I didn't even know was there.  Using Windows 8 with "Extremist" settings on Fidelizer was captivating, and hardly caused any problems with Windows operations other than program installations.  Trying it with Windows XP was even more drastic (because WinXP native sounds like crap) but wireless network access fell apart for me.  
 
Internal SSD (this was an amazing difference!).  I tried internal drives, external drives, and USB flash drives, each better than the last.  Then I heard streaming audio that sounded even clearer, and considered NAS.  Forget all that.  When I bought my Samsung 830, one word; smoooooooth.  Without the harsh sound I didn't even know was there, nuances appeared in the music, and I'm listening to everything all over again.  
 
 
That's all i can think of.  I'd love to try external SSD, but I don't know how to do it. Still using USB (want to go optical), or maybe a USB to BNC solution.  What I've done so far has elevated my system far beyond my expectations and beyond that of my CD/SACD player.  I'd love to hear your testimony if you've tried any of these for yourself, or if you have suggestions to further elevate my system

 

[oshia86]

http://en.wikipedia.org/wiki/Placebo

 

[germanium]

I would tend to agree with the placebo post as computer audio just does not work like many here think it does. With computer audio all samples are buffered & released according to the local clock which is unrelated to any clock available from the computer itself. Asynch & adaptive are just 2 different ways of keeping the buffers full. As long as the buffers are kept full there should be no audio problems. If they aren't kept full & the buffers get emtied before the next burst of audio data you will get dropouts which is worse than jitter.
 
The computer cannot affect jitter as the data is not timed in a computer but rather burst fed to the DAC's audio buffers & the buffers then release the audio data according to the local clock that is inside the DAC. As long as the program on the computer does not actually alter audio data it should for all intents & purposes sound identical no matter what program or type interface is used providing that the data is delivered by one of the computers own interfaces & not SPDIF or Toslink where the data is in fact being streamed to the DAC in a serial fashon & not burst fed. These non computer interfaces can have significant jitter issues & with a poor implimentation of toslink can be severe enough to cause bit switching (a 1 where a 0 should be or visa versa). This is what can happen if the timing caused by a slow interface which is also used to carry the clock as well as audio data get too far out of whack. this is usually due to too large a time constant at the input of the interface (SPDIF) chip that is used to seperate the data from the clock combined with a slow transmission method (Toslink). 
 
Hense computers cannot have jitter in & of themselves as in order to have jitter in the audio you have to have a timed event. Data in the computer does not have a timed event that in any way relates to the final output. The timing of these events is solely left to the soundcard. The computer only is in control of the delivery of the data to the soundcard's buffers & doing any proccessing such as volume & effects. In bit perfect mode even these are disabled.
 
Modern DACs are largely immune to input jitter because once again the audio is converted to a different format within the DAC chip (16-24 bits/44.1-192KHz to 1 bit to 6 bit at sample rates well into the MHz) Whenever you do a samplerate conversion you take input jitter largely out of the equation. You are now down to the inherant jitter of the clock itself + any switching latency of the transistors in the DAC chip itself.

 

[Roseval]

Quote:

I would tend to agree with the placebo post as computer audio just does not work like many here think it does. With computer audio all samples are buffered & released according to the local clock which is unrelated to any clock available from the computer itself. Asynch & adaptive are just 2 different ways of keeping the buffers full.

That is a bit too optimistic I’m afraid.
You might have a buffer but you have to timed events, the sender filling the buffer and the receiver draining the buffer. One of the two must do the buffer management.
In case of adaptive sync (USB) it is the DAC doing the buffer management by varying its speed. This is equal to sample rate jitter by design.
In case of asynchronous USB a feedback loop is setup telling the PC how much data to send.
This allows for a clock running at a fixed speed.
Jim Lesurf is one of the few I know how measured the difference

http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html

 

[germanium]

Quote:

That is a bit too optimistic I’m afraid.
You might have a buffer but you have to timed events, the sender filling the buffer and the receiver draining the buffer. One of the two must do the buffer management.
In case of adaptive sync (USB) it is the DAC doing the buffer management by varying its speed. This is equal to sample rate jitter by design.
In case of asynchronous USB a feedback loop is setup telling the PC how much data to send.
This allows for a clock running at a fixed speed.
Jim Lesurf is one of the few I know how measured the difference

http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html

This does not disprove what I said & in fact proves what I said that it is one method of keeping the buffer full. Data still arrives at a rate higher than the actual data rate that the DAC requires & when the DACs buffers are full the data stops until there is sufficient space in the buffer to accept more data. The data still arrives in bursts whether controlled by the computer or the DAC & when the buffer needs filling the data arrives at a pace much faster than the dac needs as a result is able to refill the buffer. The rate at which the buffer is filled is still unrelated to the clock frquency of the DAC whether or not the filling of the buffer is controlled by the DAC or the computer. As a result again you cannot derive jitter from the computer, only from the soundcard can jitter be honestly derived as that is the only place that the data is timed exactly to the needs of the DAC
 

 

[Roseval]

In case of USB audio, the isochronous transfer is used.
In this case the data doesn’t outpace the DAC as a (soft) real-time stream is maintained.
Isochronous transfer has more in common with real-time streams as SPDIF than the normal asynchronous transfer over a typical PC bus.
http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous.
 
 

 

[germanium]

Quote:

In case of USB audio, the isochronous transfer is used.
In this case the data doesn’t outpace the DAC as a (soft) real-time stream is maintained.
Isochronous transfer has more in common with real-time streams as SPDIF than the normal asynchronous transfer over a typical PC bus.
http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous.
 
 

While there is a, soft real time stream maintained  as you put it, the key word here is soft. Bursts of data are sent every 1ms. While usb at it's lowest speed is barely faster than what a CD can transfer at 1x speed @1.5Mb/s  full speed USB1.1 is capable of transfering 12Mb/s, in other words 8.5 times faster than the data is needed. Packets of data are sent every 1ms that are sufficient to keep the dac busy till the next tranfer. The packets are sized to keep pace with the DACs required audio data requirements with a small amount of packets thrown in that are different sized to keep from overfilling the data buffers so overall the data stream keeps pace with the DAC needs. There is still a local clock for the DAC itself & in some cases such as C'entrances case a very low jitter 2 stage clocking system is used (1ps). This system gets phenominal reviews.
 

 

[Adda]

My findings after trying out various players and tweaks is, that as long as I use ASIO all players sound the same and tweaks make no difference.
As long as the buffer is long enough to prevent dropouts it's all good, I haven't bothered with WASAPI, DS or KernelStreaming, since my AudioFire 2 has native ASIO 2.0 support.