bhaagensen;549277 Wrote: > IMO many are viewing the nature of the problem wrongly or perhaps > limited - and hence understand things in a far too complicated manner. > See my next comment for more on this. > > > > Yes the clock solution *to the jitter problem* is in theory also as > good as it gets. However, the point is that the real cause of *the > jitter problem* (not jitter itself) are the limitiations of S/PDIF as a > data-communication protocol - the problem cause has *nothing* to do with > timing or jitter - only data. Specifically, S/PDIF only allows for > one-way communication - hence there is no way for the receiver to tell > the sender that it is sending data too fast or slowly (again nothing > with jitter, only data-transmission rate) relative too the speed at > which the receiver consumes data. In that way the receiver becomes tied > in time (synchronusly) to the sender. The receiver must adopt its rate > of consumption to whatever the transmission speed of the sender is. > This is often done using algorithms such as ASRC. Or as Naim does - > buffer sufficent amounts of data and clock them out at a fixed > independent rate chosen such that the buffer does not over- or > underflow. > > When saying that an asynchronous protocol could easily solve the > problem, it means that *the cause* of the problem is removed - and not > that the problem is still exists and the effects then cleverly removed > again by "asynchrosness". Its not there to begin with. Its not the > asynchroness in itself that solves it. Its because asychrosness by > definition implies two-way communication. That way the receiver is free > to consume data at any (fixed) rate it chooses to. If that rate does not > match that of the sender, it can just send a message to the sender > telling it to take a break or speed up a bit. Of course, using a buffer > as a bucket to level things. > > Its easy peasy. Its a bucket with a hole in and a faucet to fill it > with. Its *very* difficult to set the faucet once and for all to ensure > the bucket never fills or empties. However if you are allowed to adjust > the faucet, anyone can do it! And nowadays, anyone and anything can > also do it in data-communication. > > > > > Yes, I stress that the purpose of this thread is not to discuss yet > another time, whether anyone heard, or not, jitter when testing source > X with DAC y. > > I asked whether it could be simulated in DSP, and that remains my topic > of interest. However I do find it interesting to discuss solutions to > the cause of the problem now that seemingly Naim in a way has a > pseudo-solution that is implemented in a real life product. > > Btw again: The reason S/PDIF is a crappy protocol is *not* that it > introduces jitter. It is because it only allows for one-way > communiction. (and by consequence is unreliable, has very little error > handling etc). > > Btw2: There is really nothing new here. This is exactly why jitter is > not a problem with our Squeezebox'es over TCP/IP, ethernet, wlan, etc.
Naim are not the first to effectively defeat jitter in a practical context. There is nothing truly "voodoo" about their approach. It's simply an approach that gives good results. Good for them. There are plenty of other approaches that work well too! (Although personally I still believe that the DAC-clocked transport is the best, I am prepared to agree that other approaches may be as good in the real world) ...And I don't agree with your analysis. S/PDIF is problematic ONLY because of the practical difficulty of accurately extracting an ultra-precise clock signal from the "analogue" representation of the bitstream. Assuming a good transport signal, with proper cabling and a good enough S/PDIF receiver (+ PSU design) this can be tackled effectively. But you are only looking at transport-induced jitter. There is still intrinisc DAC jitter to consider. -- Phil Leigh You want to see the signal path BEFORE it gets onto a CD/vinyl...it ain't what you'd call minimal... Touch(wired/XP) - TACT 2.2X (Linear PSU) + Good Vibrations S/W - MF Triplethreat(Audiocom full mods) - Linn 5103 - Aktiv 5.1 system (6x LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Townsend Supertweeters, Blue Jeans Digital,Kimber Speaker & Chord Interconnect cables Kitchen Boom, Outdoors: SB Radio ------------------------------------------------------------------------ Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85 View this thread: http://forums.slimdevices.com/showthread.php?t=78790 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
