Hacker News Reader

Comment by SAI_Peregrinus | Hacker News Reader

Audio doesn't use floating-point, it's all fixed-point. So there's no rounding error, only quantization error, and that can be controlled to whatever degree of precision is needed.

1s don't have weight compared to 0s, electrical "high" has mass compared to 0V. Which is "1" and which is "0" (if any) depends on the particular electrical specification of the protocol. E.g. with Ethernet signals are differential, ±3V, with 0V only ever reached momentarily as the + and - switch. There are also lots of cases where the "active" (i.e. "1") is the 0V value, and the "passive" (i.e. 0) is the nonzero voltage. Most reset signals are active-low.

View on HN

There's 32-bit audio that sometimes named as floating point.

Haha, you're all making the same misunderstanding as the post I was replying to. The context of the "bits are not bits" is in relation to memcpy, and his lack of understanding that it's not comparing bits to bits, but the method used to transfer said bits.

Which is exactly my point with 0.1 + 0.2. Depending on the methods it will give different outcomes, some more precise than others. Guess it wasn't as obvious as I initially thought.

1s and 0s in the same order are the same, but some data may be lost in the transfer and I don't see why that has to be explained, here of all places. And that's where the Dunning-Kruger reference came from, he thinks it's the bits, when in-fact he would mention the transport had he had more domain knowledge.

1s and 0s in the same order are the same, but some data may be lost in the transfer

Please explain? If the 1s and 0s are still in the same order, what data has been lost?

Please try to read it as I say it I don't know how to be clearer.

0001 == 0001. But 0001 + 0001 does not necessarily end up being 00001. Do you see my point now? You're missing the forest for the trees. 2 things are being discussed, not the outcome. Transport and bits, at the same time, but as separate things. Another analogy in another comment was analog wires, also good, break that and the resistance changes etc etc etc.

This many comments for something so simple. Breathe and stop going out of your way to misunderstand me. Ironically exactly how this thread even started. You clearly understand the subject since you already explained floating point arithmetic.

I'll give it one last shot: The person being referred to as flat-earth level stupid mentions bits, while he should've mentioned transport. And not taking into account his lack of domain knowledge and using the wrong lingo to misunderstand him and calling him stupid when he is right, just not wording it correctly is the problem.

If I understand you correctly, you're asserting that it's possible for transport-layer protocols to cause hiccups in the output because bits might get flipped.

Except all of the transport-layer protocols before the DAC are working in digital logic and have checksums applied to them. A bit flip is going to be detected and corrected or the packet will be dropped and resent. So the transport isn't going to have any impact on the bits whatsoever (barring effects like a packet arriving too late to emit the sound on time).

".. some data may be lost in transfer.. "

I won't go into your description of why those may be lost in transfer, others have commented on that, but NO, data may not be lost in transfer. Send data whichever way you want, over Ethernet, fiber, pidgins (POaC, RFC 6214) - it doesn't matter, as long as it's TCP and it's transmitted faster than the audio output - the transport and bits and all that doesn't matter. It's all buffered at the endpoint before being slowly (relatively speaking) ending up in your audio speakers if it's audio, or if something else - in its final destination, every single bit in its correct place.

Reply on news.ycombinator.com