jesuscheung wrote:
how about the buffering of chord DAC?
read hdd -> buffer
software read -> buffer
software player -> buffer
wasapi -> buffer
cpu cache -> buffer
DAC driver -> buffer
usb driver -> buffer
etc...
don't you think there is enough buffering already?
i see buffering as a trick.
another example, a ST soundcard has a filter after the clock. makes sound crystal clear
another trick.
JC
I'm sure you have some duplicates or irrelevant buffers mentioned there.
Buffering is not bad in itself.
As long as were handling data there is no issue at all with buffering, it is a usefull form of isolation from fluctuations.
As soon as we're hitting the time domain buffering becomes an issue, so as soon as data becomes a stream and at that point there aren't as many buffers in play as you point out there are in existence.
One of the reasons why Gordon would like to have look at Kernel Streaming (I assume he still wants to. Just get those 32-bit version out and go for KS sbgk!!) is indeed bypassing the route used in wasapi to have to copy via cpu to device driver.
Bringing the (re)clocking as close to the target device is also best imho. So get it away from the mobo and its dirty environment and put it into the DAC if it is clean or put it just in front of the DAC if the DAC is not clean.
Have you ever heard the effect of a good reclocker on sound quality?
Then you should know the clock of a signal should be as close to the DA-stage as possible.
Cheers
Aleg