pippin;656602 Wrote: > No, it's not that simple and this is also why SPDIF was originally > designed as it is. > The problem is that there is no such thing as a "44.1 kHz" clock. You > have a clocking device in your source and your DAC and both will have a > frequency of 44.1 kHz +/- some deviation and two such devices will NEVER > have exactly the same frequency. > > So as a result, when you re-clock you will inadvertently either run > into buffer under- or overruns. What do you do with these then? You > have to either insert pauses or drop parts of the audio which IS an > altering of the signal. > Pauses might in theory be a bit more simple because you can insert them > between tracks if your buffer is big enough but then the bigger your > buffer the longer the delays you induce into the signal path and that, > in turn, will kill things like multiroom-syncing. > > This whole topic is NOT trivial so the choice the SPDIF designers took > was to use one clock throughout the signal chain and they chose the > source's clock. > > Pippin I would not like to quarrel when we seem to be in agreement and when you are clearly miles more knowledgeable than I am ....but it is 100% obvious from every one of my posts here that I know that there is a problem of matching the data rates of the clocks. I have said so over and again.
I appreciate that originally the designers of S/PDIF created a system in which the clock is transmitted and the dac was expected to extract and use that clock. But as I understand it no one does it that way anymore.... Perhaps I have misunderstood you, but you yourself keep referring to "reclocking" which I understand to mean "generating a new clock". Perhaps this can be done without having a separate oscillator, but as far as I am aware most dacs do have (at least one) independent oscillator in them. The solution may not be trivial to implement but it is not difficult to understand. A variety of solutions have been adopted, but they revolve around generating a clock at the dac end which can be altered slightly to match the long(ish) term average rate of the transmitting clock. (a cursory look at the lavry website http://www.lavryengineering.com/white_papers/jitter.pdf shows that that is what they do using an oscillator whose frequency can be altered to match that of the transmitting device..) Naim on the other hand have an intriguing solution of having a whole load of clocks and using at any given time the one of them which matches the incoming clock rate. They seem to think that swapping clocks is less of a problem than having a variable speed oscillator. As far as I am aware benchmark use asrc driven by a wholly independent oscillator even though that may lead to jitter being traded for data errors. In any event If the two clocks are reasonably close together you actually don;t need to make many adjustments providing you have a buffer. The buffer does not have to be very long. If the two clocks drift by 100 ppm per second a buffer of 50 words only would allow you to change the clock rate once every 10 seconds. (see the Lavry link) Perhaps I have missed some of the subtleties. Anyway I have just realised that we have been taking this thread, which is about soundcheck's mods, completely off-topic. I apologise for this Soundcheck and take my leave, although I would welcome a reply Pippin, if you saw fit, perhaps on the Optical output thread. -- adamdea ------------------------------------------------------------------------ adamdea's Profile: http://forums.slimdevices.com/member.php?userid=37603 View this thread: http://forums.slimdevices.com/showthread.php?t=84742 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
