They really aren't. Oh boy, it ain't even close.
For starters S/PDIF is a (potentially lossy) real-time protocol, UAC ("USB Audio Class", the audio transport layer protocol for USB) isn't (necessarily).
In simple terms this means that S/PDIF streams out your bits at a constant rate. For that, your raw audio data gets chopped into packages of up to 24 bytes in size. (That's done on a a per-channel basis, usually alternating between the two.) The data packet will then be prepended with an 8 byte long metadata header containing info like the source number, the channel number, clock accuracy, copy restrict/permit, and word length, among other things, to result in a package of 32 bytes in total. That 24 bytes long chunk of audio data prepended by its 8 bytes long metadata header then gets sent out to the receiver as a 32 bytes long package, immediately followed by the next package, ad infinitum.
The connection between the sender and the receiver is strictly unidirectional (meaning: one way) and happens in real-time, meaning that there is (usually) little to no caching involved on either end of the line, and if an error is encountered by the receiver (which can be tested for by using the parity bit that is embedded in the packet's metadata header), the receiver has no way to call back to the sender and ask for a do-over. It'll then either have to discard the package, or play the audio with the potential error left unchanged.
S/PDIF is also what's called a hybrid signal, meaning that the data it transmits is digital (the signal states are either interpreted as "high" or "low", but no shades of gray in between), but the timing of the signal is entirely analog.
Normally, the data rate of the bus is not related to the bits that are being sent. But with S/PDIF, the send rate IS the data rate. Meaning that the sender switches the signal to a high or low state as needed for the data that is to be transmitted, and the receiver samples that signal's state at a fixed interval. The clocking for this signal is determined by the sender. If the sender's clock is unable to sustain a highly regular clock interval, any fluctuation in the "rhythm" of the signal will manifest itself in the receiver as jitter. The bigger your clocking mismatch is between the sender and the receiver, the higher your chance for errors. Same goes for cable quality and length, shielding, etc.
In terms of protocol, there's no difference in fiber vs. metal cable. All that changes is the medium, everything else remains the same.
UAC, in contrast, is an entirely different animal and hugely depends on which protocol is used in particular (UAC 1, 2, or 3), and how the clocking mechanism is implemented in the receiving device.
Information can be sent via USB in one of four different modes: Either als control transfer (where a device "asks" for data and gets responded to in due time, sort of how networks usually work), as interrupt transfer (where the sender sends an interrupt signal that tells the receiver to start listening no matter what else it is currently doing), bulk transfer (where one device opens a connection and then streams a finite amount of data to the receiver, like print jobs) and through isochronous transfer (often used for audio streams).
"Full-speed" USB devices communicate with a data rate of 12MHz. But they don't send the data constantly. Instead, it gets chopped into smaller chunks, called frames, that are then sent out in 1kHz intervals — or 1,000 frames a second. That leaves room available for other USB devices to communicate with another over the same cable.
For isosynchronous transfer, your computer (or other source device) first loads large chunks of audio data into memory, and then spools the data to the output port in a continuous stream of 1,000 thousand frames a second. No metadata headers are sent beyond whatever is required for the handshake during establishment of the connection between the sender and the receiver. The rate at which the data is sent is determined by the oscillator responsible for the USB bus (i.e. the host device's USB controller), so that no mismatch between the sender and the receiver can exist. This rate is also entirely independent of anything else that is going on inside the sender (i.e. the PC) or the receiver (i.e. the DAC) This constant stream keeps going whether there is actual audio data available or not. In theory, this guarantees a constant flow of data. In practice, you can end up with "holes" in your transmission if the sending device's processor gets hogged by other processes and can't keep up suppling new frames to the USB cache in time to be streamed out.
For isosynchronous transfers, there are three methods of clock synchronization available: Synchronous, adaptive, and asynchronous.
For synchronous clock synchronization between the host and the client, the bus signal itself is used. For that the receiving device uses the 1kHz rate at which it receives data frames, from which it then derives its own clock. That's almost always
very jittery and is thus no longer really being used in audio. But it WAS the standard when UAC first arrived, which is why
@Baldr insisted for so long (and rightfully so) that USB sounds like ass when compared to the somewhat more stable S/PDIF clocking mechanism.
In adaptive clock synchronization, the client provides its own clock. A control circuit has to be implemented that constantly measures the incoming data rate and determines from that an average to which it adjust the client's clock. Since the clock is now independent of the bus signal, it is not as susceptible to jitter. But the two device clocks can still drift apart, which will lead to sampling errors. To avoid that, the client keeps sampling the incoming data rate and will constantly attempt to adapt to that jitter or drift, but the result is that while you're less likely to drop any information in the frequency domain, your audio stream's accuracy will absolutely suffer in the time domain. This is, to my understanding, how USB-to-Unison connections work.
For the third method, asynchronous synchronization, a third, external clock is used to get the data out of the sender's buffer at a constant and controlled rate to the receiver, and it will manage the buffer size to ensure that there's always enough data available to stream. This makes the entire thing independent from the bus clock and any jitter that might be inherent to that, and thus ensures the highest possible accuracy in the frequency as well as the time domain. This is, to my understanding, how Unison-to-Unison connections work.
Seriously, if it sounds better to me... only my wallet suffers. I'm so cheap that I squeak; audio equipment is my only vice.
