AndrewFG;362840 Wrote: > Don't get me wrong. I don't dispute that lossless is lossless. The word > "lossless" is a definition of meaning and it simply CANNOT be > disputed... > > I am not talking about theory, I am talking about practice. I am simply > stating that, in real world systems, as you insert more "processing > stuff" onto a lossless chain, you will eventually reach a level where > things start to go pear shaped, and eventually the chain fails. e.g. > the CPU can't handle the processing load, and has to drop or reschedule > stuff in order to keep up; or the network has to drop packets. > > Even with your VERY large scale computer systems, I bet that it is > eventually quite possible to add enough overhead to the system, to > bring it down. C'mon you know this yourself :-) > > And when things like this do happen, the lossless chain becomes > transformed into something that starts to look an awful lot like > "lossy", where the only question is whether it becomes a total loss > (the system freezes or crashes), a partial loss (dropped bits or > packets), or a time loss (the data gets through eventually, but not in > real time).
Andrew, We are talking about two different things. I'm talking about "lossless" in the sense that no data is discarded or altered in the software chain so that what is presented to the DAC is what was in the original source. This has been proven in practice (not theory) by using HDCD or DTS material which simply won't work properly if the bits are altered. Yes, the software stack might be so deep that the CPU struggles and the systems slows to an unusable crawl. I say that's not lossy - it's broken. The music will eventually stutter and stop. The ethernet protocols ensure network retransmission of lost/corrupt packets containing many bytes (individual bits themselves can't be "dropped" as that is not a unit that the computer deals in at an access/transport level). The buffer in the SB is quite big and will cater for a lot of packet retransmission for wi-fi purposes - again though, if the buffer empties prematurely or fails to fill this is broken, not "lossy". Finally, there is nothing "real-time" about any of this (unlike a CD player). The entire process is asynchronous. Timing issues can only begin to arise downstream of the SB (e.g jitter). I replied to your OP because I thought you were concerned that the software path length might affect "sound quality" and I've tried to explain that it doesn't. That is completely different to saying that running too much software on the server PC might bring the system to it's knees performance-wise. Regards Phil -- Phil Leigh You want to see the signal path BEFORE it gets onto a CD/vinyl...it ain't what you'd call minimal...SB3+Stontronics PSU - Altmann JISCO/UPCI - 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, Kimber & Chord cables Outdoors: Boombox+Creative Sub (If I remember to turn it on...) ------------------------------------------------------------------------ Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85 View this thread: http://forums.slimdevices.com/showthread.php?t=55442 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
