Why not a data bank in the dac?

The Chord QBD-76 DAC has an extremely long buffer. I agree that it seems like a great idea for reducing jitter.

The big disadvantage is that the buffer interposes a time delay equal to half its length. In other words, if the DAC buffers one second of data, there will be a half second delay between when the source (computer or CD transport) outputs the data and when you hear it at the analog output of the DAC. Consequently, when you hit the stop button or change tracks on the music player, you'll continue hearing the previous track for a half second. If you try to scan forward or rewind within a track, you'll overshoot the desired spot by a half second multiplied by the ratio of scanning speed to normal playback speed, i.e., if you fast forward at 10X, you'll overshoot by 5 seconds.

Thanks Bob, That does make sense.
It would be quite bothersome for movies. For music though, it would seem a price I would be quite willing to pay...I think. I like extra time between songs anyway to savor the last one and then be ready to appreciate the next one fresh.
Anyway, too bad its not a practical approach.
I'm still wondering though:
Would it still have that characteristic (the delay or overshoot when fast forwarding & rewinding) if the buffer were big enough to contain the whole disc? Like with the Chris' CAPS server where there is a large SSD that can hold at least an hours worth of HD audio that is downloaded from a NAS, or streamed from internet, or from CD or DVD or whatever, and then play that back freshly clocked.
If that would work, then it wouldn't be any worse than getting up to put in a new disc...except maybe a little longer. If that what it takes to bring the music playback as close to perfect as possible, then so be it.

Also,
It might also be a problem when you have digital active crossovers, or bass management, then you would still need your DAC to be the master and a clock "out" connection so delays could be applied as needed for processing. I don't know. maybe all that is done before the final D/A conversion.

How do you keep the first 27 letters of a post from being repeated.
Thanks,

The serious answer is : type a title yourself in the Subject box (above the typing area).

Doesn't asynchronous transfer use a small amount of memory to buffer the data?

Hey ! now the title has gone at all ! O dear, I hope this isn't my fault.

Chris, can't they come back ? I know you never used them, but I always did ... (and many people do, and IMHO those who do, use it very well !).

Thanks,
Peter

Edit : Uhhhhmmm, what's up ? The title has gone allright, but the injected one (line) is not.

Oops, hope I didn't cause any problems.

The subject of this thread has been on my mind a lot lately and I was wondering if anyone has any further insights.

Would there still be a delay or overshoot when fast forwarding & rewinding if the buffer were big enough to contain the whole disc? Like with Chris' CAPS server where there is a large SSD that can hold at least an hours worth of HD audio that is downloaded from a NAS, or streamed from internet, or from CD or DVD or whatever, and then play that back freshly clocked.
If that would work, then it wouldn't be any worse than getting up to put in a new disc...except maybe a little longer. If that what it takes to bring the music playback as close to perfect as possible, then so be it.

Thanks

John,

Sorry coming to this party late - but there was a similar thread / discussion on this topic before. You might find it interesting to read it here -- http://www.computeraudiophile.com/content/buffer-universal-panacea

If it raises more questions for you come back and ask away...

Eloise

Thanks Eloise,

That thread had the discussion I was looking for. Too bad it ended with an expert stating some facts (which is good) but leaving out his opinion of the different interfaces and jitter reduction solutions (which I would really like to hear). The important thing to remember, i guess, is that the really smart guys, the ones designing the equipment, have to really study this stuff and their conclusions are mainfested in their final product. Its "interesting" to us cause we want the best sound for our systems, but its "essential" to them cause their success depends upon it. You never really know how good a solution is till you try it; and then only time will tell if a concensus will develop or a breakthrough will emerge.

I'm new to computer audio (obviously...and still saving for the big day I can jump in), but I'm quite happy that so much energy is being put into its development and excited about what is...and will be...a wonderful thing.

Too bad it ended with an expert stating some facts (which is good) but leaving out his opinion of the different interfaces and jitter reduction solutions (which I would really like to hear).

Well John,

I think anyone who knows Gordon Rankin probably knows his opinion about interfaces and jitter reduction. Gordon believes in using only one interface: USB interface in asynchronous mode. If you read his ad it says "Why fix Jitter?" I tend to agree with him. While he may not have been the very first to use Async transfer he certainly has brought a lot of attention to the concept. I've noticed that there are many other DAC manufacturers doing Asynch USB or firewire now than there were a just a couple years ago. Some people will say that the transfer alone doesn't make a good DAC. But if you start with jitter then you have to deal with it, usually by minmizing but never eliminating it.

If you do a search for Gordon's posts here or audioasylum you can read more about his opinion on the subject.

Regards,

Larry