Yes, jitter is real, but in a competently designed DAC, it’s a solved problem. Competently designed doesn’t mean expensive. Some of the newer DACs produced in China that sell for ~$/£/€100 are measurably equal to “high-end” units costing tens of thousands.
Ah, that expensive cables or server can improved non-audio data is absurd, but for audio it is not absurd. I understand!
No! As you say noise=analog, it can not be accociated with the digital signal. Like wind is not accociated with digital signals over Wifi.
You should not confuse the signal with the transport medium. Buying the FedEx driver a better car will the improve the sound quality of the CD he delivers. But with a digital transport you expect such an improvement.
1 Like
Are these protocols designed to filter out Analog noise before it is transferred or at the receiving end?
I’m not suggesting there are any extra (or missing bits), and I’m not questioning ethernet protocol, I’m just interested in the possibility of noise transfer to the DAC (via Digital signal cable or USB). Does the signal arrive at the DAC in a perfect square digital sine wave?
Yes, in SPDIF real time transmission jitter is real. In a paket based transmission fe. with TCP like Roon uses it, there is no jitter, because the protocol depends not on timing. Pakets needs not even come in in the right order. The only timing issue you can have, is that pakets come in too late, then you have dropouts, not jitter.
So qed., no jitter in modern digital audio transmission. That is science, isn’t it great!
1 Like
It doesn’t matter how it arrives, since the bits need to be put in a memory buffer before the actual D/A conversion can be done. Once in memory, would you agree that all the noise and all the jitter and anything else that happened on the transmission line is gone?
1 Like
What??? These protocols are software and cannot flter anything analog.
It is like asking if the face recognition of my smartphone can remove pimples in my face or doing benchpress in VR game let grow my muscles.
Your arguments shows exactly the problems in digital noise believing: analog knowledge is used to explain the digital world.
Digital transmission is only numbers. You can write these numbers on a piece of paper and type them in on the receiving end and you will have perfect sound, indepent if dust was on the paper.
2 Likes
Agreed as far as TCP is concerned. Although, as I was an early adopter of Linn streamers, the joy of audio via TCP was often ruined by dropouts! Local network being the issue, not TCP, but extremely frustrating none the less.
1 Like
These are not my words, I was merely quoting what had already been written above.
That’s what “all or nothing” means it digital. You don’t get a “smaller soundstage” or “less air” or “looser bass” or “lost resolution” when things go wrong, you get dropouts.
2 Likes
And you know, at the internet a lot of stuff is written and lot of it is not true.
It’s not just on the internet my friend. Misinformation is everywhere, just the internet is the quickest way to deliver it!
2 Likes
One would hope, but that would also assume that we have reached the end of the line as far as memory buffer technology. Is it 100% perfect?
If we look at human history, nothing ever stands still, there is always progress to be made.
Perfect in what way? In storing bits? Of course. All digital data must go through memory buffers when transmitted, received or stored on persistent media. In the particular case of a DAC, if the memory went bad and started flipping significant bits, you’d surely notice.
Unfortunately, there was quite a lot of ‘nothing’.
This is where my questioning of (non TCP) digital transfer comes from. If I was experiencing dropouts due to TCP not allowing imperfections through, and now I don’t have any dropouts (via USB), are those imperfections making it to my DAC. If memory buffers were 100% perfect surely they would catch the same issues that TCP prevents, and I would be experiencing signal dropouts. Or is it signal degradation? Does all or nothing only apply to TCP?
The issues you had with TCP were most probably caused by either some network misconfiguration or lack of bandwidth. I’ve never experienced audio dropouts with TCP, even on 100Mbps connections.
I never got to the bottom of the problem before I gave up on it as it was completely ruining my enjoyment of music. My network was all professionally installed and checked, but my assumption at the time was that it was a local issue. I got little help from Linn, other than blaming my network.
The I guess it was Linn. If TCP and the memory buffers it relies on were that bad, we wouldn’t have internet, and we wouldn’t be having this chat.
No. It arrives as packets of bits. Again, you need to distinguish between the various levels of the protocol.
I think you’re on the right track there. It’s a bandwidth issue. TCP will do re-transmission till the correct packets arrive, and memory buffers (which do something else) will store the bits correctly, but remember that the various bits of the music are being sent in order. So TCP delivers them and puts them in the buffer, and the player software takes them out of the buffer and runs them through the DAC, but what happens if the network is really bad and TCP takes a long time to get the right packets through and put them in the memory buffers? If they empty completely, because the network is slow, the player software doesn’t have anything to run through the DAC, and you get a dropout. Sufficient network bandwidth (the rate at which the network, TCP here, can transmit bits correctly) has to consistently be high enough to support the music streaming rate. Luckily, most networking speeds are 10-100 times more than sufficient, all the time.
Bandwidth variations are quite common on WiFi networks, but most aren’t severe enough to impact music streaming.
Is this the same via usb, aes and spdif, or just TCP?
It’s the same for all interfaces, although some support a wider range of formats than others.