...gettin' rid of my crappy cables anyway.
LOL

PRML - Partial Response Maximum Likelihood - is a methodology used to interpret "digital" from an analog medium such as a HDD drive. This also allows for some interesting tricks for data writing/reading. In reality, digital won't be a perfect step function even at creation which is why it relies on large thresholds and a clock. The receiver is just as important as the transmitter and in most cases transmission losses are accounted for in design.

They were trying to drive the address and memory busses directly from the CPU chip with no buffering drivers.

 
That's a really boneheaded mistake, heh.
 
PRML sounds a lot like removing DC bias. I've had to deal with receiver sections that tended to bounce around a bit after a transmission. Since a most detection routines focus on the zero crossover point, you don't really care what the amplitude is - but any bias in the signal and all bets are off.
 

SuperG
PRML sounds a lot like removing DC bias. I've had to deal with receiver sections that tended to bounce around a bit after a transmission. Since a most detection routines focus on the zero crossover point, you don't really care what the amplitude is - but any bias in the signal and all bets are off.
 

 
Way more black magic than that. Removing DC bias for digital signals is generally simple and has been done on all computer stuff since forever, usually with 8b/10b encoding. You take each 8 bits of data and encode it in to a 10-bit word. There are multiple 10-bit words for each 8-bit payload, with different 1/0 configurations and so by varying what you choose you can maintain 0 DC on the line. Ethernet, PCIe, etc all used this. Newer versions tend to use more complex encoding schemes like 64b/66b (10 gig net) and 128b/130b (PCIe 3 and USB 3.1) which use a complex polynomial scrambler to generate the data. Same idea, less overhead (though also a bit less rigid controls on DC offset).
 
So, PRML, this is largely a technology seen on magnetic disks and tape, though other things use it. What you do is rather than trying to write out binary data in a simple fashion where a value (voltage level, magnetic flux, whatever you are using) over a certain level is a 1 and under another level is a 0, you instead produce a fairly complex analogue waveform by just doing your best to modify what's there. When this gets read back in it looks at the wave it has and figures out based on the transition what is the maximally likely data sequence that corresponds to that wave. Sound like the kind of thing that would work for crap and you'd use to recover a bit of degraded data but actually is extremely reliable.
 
The net effect of PRML (or rather EPRML these days) is that you can have a much weaker signal level, and much more noise, and still get data out of it reliably. In terms of harddrives, it allows for more dense data storage. 

Yet, just as differences in SPDIF Cables and/or sources, as well as DACs (and their combinations), can be shown to produce not just audible but reliably measurable differences, USB audio is subject to its own set of limitations and problems.

This is a strawman argument. USB data transfer has almost nothing in common with S/PDIF. With the latter, there is some uncertainty over when a bit is a bit, and cheap cables can exacerbate this. But there is no such ambiguity in USB data transfers.
 
It would appear that the magic black box they're advocating is a so-called "active USB cable". It means there are amplifiers at each end, which helps with impedance matching and signal strength. It could also increase the maximum length of a USB cable.
 
However, it's only necessary when it's necessary, which is to say it's mostly unnecessary. If your computer's USB ports are to spec, and you're using quality cables, it's unlikely that active cables would offer any noticeable improvement. Could it reduce CRC errors? Maybe. Would that make your audio sound better? Absolutely not.

Also in terms of "active USB cable" all that is is a cable with a 1-port USB hub in it. You can get them extremely cheap at Monoprice, if you so desire.

bitflipper
This is a strawman argument. USB data transfer has almost nothing in common with S/PDIF. With the latter, there is some uncertainty over when a bit is a bit, and cheap cables can exacerbate this. But there is no such ambiguity in USB data transfers.
 

It is indeed.  
 
SPDIF is a single, synchronous ground referenced signal, whereas USB uses a differential signal, not to mention it time-shares the medium between host and peripheral.
 
Most importantly, when folks talk of USB, they are usually referring to data at the logical level, where checksums and crc's and maybe even redundancy codes live.  When we talk SP/DIF, we're usually talking about a synchronous signal at the analog level, where clock recovery is crucial. These are two completely different universes.
 
 
 

So if I get all this right, as long as I hear audio at the receiving end, my cable's good. If I don't, my cable may be bad.
 
Replace with Ethernet. Why isn't Ethernet being developed more for audio?

soens
So if I get all this right, as long as I hear audio at the receiving end, my cable's good. If I don't, my cable may be bad.
 
Replace with Ethernet. Why isn't Ethernet being developed more for audio?

Pretty much.
 
Of course, you could still have a problem and not know it. If you are getting a lot of transmission errors, that could be limiting throughput and you might never know it was happening. But the same is true for Ethernet, Firewire and disk drives. Good cables are paramount throughout the computer system.
 
Audio over USB is a bit of a kludge, as it was not designed for real-time data. But Ethernet is even worse. Its reliability comes from being able to re-send munged data, receive packets out of sequence, and find alternate routes. None of that helps much with audio, where getting the data in a timely manner supersedes even data quality.
 
Where Ethernet shines is when you're moving many channels of data at once and can have only one cable to do it, such as a digital snake.

bitflipper
Audio over USB is a bit of a kludge, as it was not designed for real-time data. But Ethernet is even worse. Its reliability comes from being able to re-send munged data, receive packets out of sequence, and find alternate routes. None of that helps much with audio, where getting the data in a timely manner supersedes even data quality.

I have always thought that USB was designed to send (more or less) real-time data.
And for Ethernet: it can solve collisions but that can be hardly called re-sending data, it supports no packet sequences (without touching Jumbo frames topic) and so it does not know which packets are out of it, and I would really appreciate in case someone can point me to alternate routes supporting Ethernet device. Are you meaning TCP/IP infrastructure?