ZappaMan
Headphoneus Supremus
Here’s a quote from a website:Exactly, but at the end of the day, it is outputting a digital signal. So if it cannot transmit electrical noise, and is not doing any sample processing (no upsampling, no crossfeed, volume - I.e., bit perfect) what Is the dac getting that is different from one source to another?
“
What does "bit perfect" mean?
Before going any further, I need to define the term "bit perfect" as it is used in the blog so as to not confuse my readers. The term "bit perfect" is a technical term that is used to describe any form of digital communication that involves a series of checks and error correction (i.e., checksum), ensuring the data that arrives at the receiver is identical to the data that was transmitted from the source. This is what allows you to download a file from a server halfway around the world and know that it will arrive at your computer identical in every way to the original.
Of course unlike most digital data transfer, music is played in real-time, so even if you are using digital communication devices (i.e. streamers, modems, and routers) that can potentially correct corrupted data, there is often no time to do this, and therefore the corrupted data is passed on to the next component.
When the term "bit perfect" is used in regards to player software, it can be somewhat misleading, since it implies that what is output from the computer has not been altered in any way from the original music data file. This is not the case. All bit perfect means in regards to player software is that the player software doesn't intentionally alter the music data files before decoding and/or streaming them.
If bit perfect player software did in fact assure the music data leaving the computer had no bit errors, then all so-called bit perfect players would sound identical, and this is certainly not the case. What would be more accurate would be to say that a specific music player software can be operated in "bit perfect mode," in which no algorithms were purposely used to alter the original data file.
This is a perfect example of why I sincerely recommend you view the claims of companies that sell music player software (and anything else in the audiophile industry) as "marketing language" as opposed to quantifiable facts.”
https://www.mojo-audio.com/blog/computer-audio-misconceptions/
bobfa has a very informative blog with links to other pages, which discuss the usb audio protocol by the people who created the protocol, so they should know. It’s worth reading if you think, because it’s a computer sending the data, then it’s digital, then it’s identical to the receiver.
https://audiophilestyle.com/blogs/entry/752-usb-universal-serial-bus/
https://www.edn.com/fundamentals-of-usb-audio/
then an interesting quote from above link:
“
.In order to keep a short feedback loop, the trick is to not buffer audio packets and feedback packets unnecessarily. Any additional buffering creates latency in the reporting, and this latency makes it more difficult to keep a smooth flow of traffic. This means that the low-level USB stack and the USB Audio stack should be tightly integrated, without buffering in between. Although this is hard to achieve on an application processor, this is quite easy to achieve if the software is implemented on an embedded processor that has a predictable execution time.”
Last edited: