Jump to content
IGNORED

USB audio transmission isn’t bit true


Recommended Posts

PREFACE:  If you are just reading this now, and decide to read through the entire thread,  you will see a lot of ignorance, many trolls, and a lot of blatant disrespect for me and this site, and against TOS.  If you exercise patience, logic, and an open mind,  you will conclude the same as I have, and truth.  At the bottom of this long post, you will find my conclusions, in case you just want to learn without having to read through all the BS that goes on in this thread....just scroll to bottom of this post to CONCLUSION BOLDED BELOW.

 

=====

 

MANY times, and most everyone here has told me that everyone agrees that DACS get their bits with 100% accuracy, that it is just noise that causes difference in SQ.

I have always had difficulty with completely accepting that concept. 

 

One time, when I stated that I had difficulty accepting that DACS get the music bits with 100% accuracy...OP responded that even Gordon Rankin has measured this at the input pin and proven this....

 

So i googled "Rankin accurate bits dac" and perhaps a few  more key words, and i found below:  This does not sound like he says dacs get their bits accurately, but quite the opposite, and more in line with my thinking....anyway, this totally changes my perspective on things, and put my mind to some rest.

 

most notably: What we have here is an explanation with screenshot proof that USB audio transmission isn’t bit true

 

Granted the article is 2 years old, so if someone has a link that suggests audio transmission via USB is "BIT TRUE", please share.

 

Link to entire article at bottom...

 

 

Via email, I posed the following question to Rankin: when I transfer a file over USB to an external hard drive it doesn’t make transfer errors – the file at the destination is the same as the source – so why should sending digital audio over USB be any different?

What came back was an epic reply. Strap yourself in – we’re going for a ride.

“While all of these interfaces (Firewire, SPDIF, USB, Ethernet, Thunderbolt so forth) have specifications. The % differential from one supplier to another in electrical, cabling, device and host seem to vary quite a bit.“

“All data moving between a host computer and a device over USB is done electrically. There are different speeds and different protocols that determine how a device and the host communicate.”

“Any interface between two points cannot be totally error free. If you use a hard drive over USB, Ethernet or Firewire there are transmission errors. That means the transmitting device is told to resend the packet that has the error in it. Most of the time this is one bit in a packet size of length X.”

“Remember, the carrier is modulated on the data so the larger X, the bigger chance of errors. Also the faster the interface the more chance that there will be an error.”

“The three main USB transmission protocols are Bulk, Interrupt and Isochronous. Bulk (used for data transfer to a hard drive) and Interrupt are error correcting. Isochronous (used for audio) is not.”

“Bulk and Interrupt are immediately NAK (negative acknowledgement). The receiver is designed to detect a bad packet immediately and the packet is resent.”

sonicorbiterSE

“For USB audio, the receiving device is basically translating a serial stream of data with a clock interwoven throughout. At the end of the packet sits some sort of block check. If the block check does not match the data then that packet is flagged as an error.”

“With Isosynchronous USB transmission, packets are sent without any error correction / resending. But guess what? This is the USB protocol used for audio frames. The bad news is they are not error free. The good news is these Isosynchronous frames are afforded the highest priority in the system.”

“A couple of years ago, I bought an expensive Tektronix USB setup. I have had protocol analyzers since designing my first USB DACS some twelve years ago. The Tektronix is useful because it allows me to see errors better both in electrical and data packets.”

“The big thing that many people don’t realize is that not all USB ports are created equal. Not all USB cables are created equal and it’s the same for devices and even operating systems. Since getting the Tektronix I have tested probably thirty different USB cables on the fifteen computers in my lab. These computers run a variety of operating systems and the Tektronix results vary between computers even when the cable remains the same. Lets just say it’s not as pretty as I thought it would be.”

“Just a couple of things to think about in regards to USB ports. First, look to see what else is located on that tree. Each USB port can handle 127 devices. Sometimes there are additional ports hidden (inside your computer) and there are internal devices sitting on those ports – this could be the same tree that is hosting your USB DAC”.

usbtree

“You can see in the lower tree, USB Hi-Speed Bus, Hub*, Hub, Apple Internal Keyboard/Trackpad, BRCM20702 Hub, Bluetooth USB Controller. On some computers, Hub* will actually be a external port and if you plugged your DAC in there you’re sharing it with all the devices below it.”

“On the PC, you can use this helpful application from Thesycon.”

“Alternatively, if you know your way around Device Manager you can go through that to find the USB tree. Although neither of these really give you a good indication of which port is on which internal hub, if you ARE able to place your DAC on a direct port you will be best served.”

“Speed plays an important part in all of this too. You may have heard the terms UAC1 and UAC2 – these are USB Audio Class protocols. UAC1 was designed for Full Speed device and host interaction. A data packet is sent every 1ms. In that packet are up to 1023 frames.”

“In high speed or UAC2 those 1024 frames each contain eight micro frames. Therefore, the amount of data we can send over UAC2 is basically eight times greater than that of UAC1. But with more data at faster speeds comes more errors and system configuration becomes harder. I almost never see an error on a UAC1 device, on a UAC2 device I can pretty much count on errors in both directions.”

theyscon

“For optimum results, at least in theory, it’s best not to use a USB hard drive for your library with a USB DAC connected to the same host device. Think of it this way: your music software is reading from the hard drive in a synchronous manner and then writing to the DAC in that same synchronous manner and, as the DAC has priority, the music software might fault when reading the disk – this can lead to really bad sound.”

“Also, it’s probably best not to put the library on the system disk – because system stuff has really high priority over music playback software and again the music software can fault and bad sound will result. When a music app faults it becomes NON-bit true. One workaround for this is to choose a music app with memory buffering but in my experience even that’s not guaranteed to be 100%.”

“A good example of this is when we transitioned from Full Speed USB to High Speed USB DACs. A lot of the really expensive USB cables from audio companies failed miserably; I doubt many of these cables were even tested for High Speed compliance.”

“To summarise: the problem with USB Audio is that Isosynchronous USB frames are not error correcting. Therefore the sonic outcome of any USB system is dependent on the host to device differential.”

“Twelve years ago, I pretty much thought as many people do today: that USB was the answer to our S/PDIF quandaries. In some ways it is a good deal better. We have Asynchronous Isosynchronous so the device and host know about sample rates, bit rates, clocking options and a host of other things. But cables make a difference, computer brand and quality make a difference and even the device makes a difference.”

“I will try and capture some data errors on the Tektronix. The problem is that it does not accumulate errors. It also does not stop on errors. I have to actually push a button capture it and then pipe that to my screen.”

usb_errors

“What this is showing is the event table or the decoding of the USB Bus as seen by the Tektronix scope. We are using a Tektronix Differential Probe and their USB Analysis package. I made a little Male/Female HS USB board and that is plugged into a MacBook Air. I am using the Faber Acoustics Signal Scope Pro to send a 1KHz Sine wave to a Wavelength Crimson DAC @ 176.4K sampling rate. This is a program I use to test basic DACs of all kinds. This is also a pretty basic setup compared to audio transmission.”

“As per the above, a packet sent by the host to the Crimson has a CRC16 error. You can see that in the error column.”

TL;DR? What we have here is an explanation with screenshot proof that USB audio transmission isn’t bit true – enough evidence to reject any null hypothesis that assumes 1) all bits sent will all arrive intact and 2) re-transmission sorts out any detected errors. The Isosynchronous protocol used for audio data checks for errors but does not do any error correction (by way of retransmission).

Bringing it all back home, the iFi iPurifier 2 likely improves the sound of the Sonicorbiter SE because it minimises transmission errors by making lighter work for the Mytek Brooklyn’s USB receiver chip.

Furthermore, with lower noise on the line, the USB receiver chip no longer needs to kick into a higher, noise-inducing operational gear to ensure that it reads the incoming data correctly.

In other words, USB audio isn’t simply a matter of bits leaving the host PC/streamer and arriving AOK at the DAC. The quality of that which sits in-between matters.

 

https://darko.audio/2016/05/gordon-rankin-on-why-usb-audio-quality-varies/

 

 

CONCLUSION

On 11/30/2018 at 8:03 PM, beerandmusic said:

in re-reading above article, IFI says EXACTLY what i was saying...that i am not convinced that errors will ONLY cause a dropout (as many have suggested), that i can understand that if an entire packet was dropped, you may hear a click or drop... but not if occasional bits....that i suspect distortion.....here IFI suggests exactly as i guessed....

 

==

Isochronous transfer mode uses error-checking but includes no re-transmission in case of Cyclic Redundancy Check (CRC) errors. Electrical noise on USB signals causes CRC errors and thus data loss, as does poor signal integrity.   In mild cases, this leads to audio signal distortions. In the worst cases, clicks and dropouts.

===

 

IFI does know a thing or two about USB!

 

They also say that noise causes errors and data loss...something else i said but that was rejected....and i deduced both of these FACTS by logical reasoning...never read it before, and it went against everything that most people here claimed....

 

In summary, when you get errors, and likely you will if not highly optimized system (more if noise, interrupts, non-optimal buffer settings, and MANY other things can affect) and You will either have distortion, interpolation (possibly incorrect), or dropouts if too many errors (and entire packet is dropped).  It is very feasible that you will have distortion (or unnatural music) and not even know it... people can choose to believe whatever they want...but i know differently....

 

NOTE: None of these facts suggest you can't have a good usb solution.  I do believe one can have a stable optimized USB solution, and that some DACS will do a better job than others....but in my opinion, USB is unneeded....look to the future...I put together a fiber solution (including used gigabit switch, sfp, cables, and fiber media conversion to UTP for under $200....and you can scale up all the way to the new LUMIN X1 which includes fiber input. 

 

Network players are a way of the future, and there already exist many solutions at all price points and with lots of promise for many more on their way!!

For anyone planning a new audio system, I highly suggest you consider looking in this direction (e.g. network player isolated from music server via fiber).

 

image.png

Link to comment

Not quite sure why you have such a problem with noise or interference effects being the culprit for degraded sound ... IME this is everything in terms of optimising SQ - running after digital misbehaviour as causing issues is a fast road to nowhere ...

 

Poor analogue qualities of the digital transmission can cause sound quality to be less, but this is because the analogue circuitry is being affected directly by those waveforms, or by the receiving or capture circuitry having to "work harder", and the analogue qualities of waveforms within the latter then doing the damage ... digital errors mean nothing in themselves.

Link to comment
8 minutes ago, fas42 said:

Not quite sure why you have such a problem with noise or interference effects being the culprit for degraded sound ... IME this is everything in terms of optimising SQ - running after digital misbehaviour as causing issues is a fast road to nowhere ...

 

Poor analogue qualities of the digital transmission can cause sound quality to be less, but this is because the analogue circuitry is being affected directly by those waveforms, or by the receiving or capture circuitry having to "work harder", and the analogue qualities of waveforms within the latter then doing the damage ... digital errors mean nothing in themselves.

 

I accept noise of all types affect SQ, but everyone kept suggesting that the DAC gets the music bits perfectly, but that noise affects the dac in processing.  This suggests that the DAC doesn't even receive the music bits with accuracy due to noise....big difference.  Some suggest that dacs can resolve for most noise, that's all dandy, but if the music is already inaccurate before it gets to the DAC input pin(s), there is no way to fix it at that point, if it is already corrupted.

Link to comment

The actual bits will be accurate - if interpreted as data, digital IOW. It's all about how one looks at a waveform - the identical signal, it can be looked at as information, or as an electrical 'picture' - how the circuitry that follows reacts depends on which way it's looking at things.

 

A visual analogy: a piece of paper full of numbers is photocopied multiple generations, and the toner is running out. The final 'picture' looks 'orrible - but if someone carefully views the poor result every single number can be accurately determined, and a 100% correct new version of that page can be recreated, with perfect clarity ... that's the 'magic' of digital.

Link to comment
5 minutes ago, fas42 said:

The actual bits will be accurate - if interpreted as data, digital IOW. It's all about how one looks at a waveform - the identical signal, it can be looked at as information, or as an electrical 'picture' - how the circuitry that follows reacts depends on which way it's looking at things.

 

A visual analogy: a piece of paper full of numbers is photocopied multiple generations, and the toner is running out. The final 'picture' looks 'orrible - but if someone carefully views the poor result every single number can be accurately determined, and a 100% correct new version of that page can be recreated, with perfect clarity ... that's the 'magic' of digital.

 

The actual bits won't be accurate at the input pin(s) to the dac....that is what many/most people try to sell you here, but it is untrue. A lot of things are logical to me now in realizing this.

Link to comment
15 minutes ago, fas42 said:

Again, the bits at the input pin can be super clean, or electrically very ugly - how well the DAC handles that depends upon the circuitry inside the DAC, how 'robust' the implementation is.

 

incorrect..it can't fix what is corrupted...they can use algorithms and work on what they got only....read the article.

 

All the issues I had make sense now...including why enet better, why reclockers and other usb toys work (although i wouldn't trust them...better to get it right first time)....etc.etc...everything makes sense that i had problems with.


 

Link to comment
5 minutes ago, mansr said:

The error rate of USB is actually very low in normal circumstances. This can be trivially tested by capturing the output of a USB to S/PDIF converter.

 

"very low" equals relative

 

not sure of handshaking with spdif, but in this article they suggest that audio handshaking is different and that packets are not resent with audio to verify accuracy (like in digital transmission)...if there is an error it just goes along.... for a valid test you would need to do a comparison to the flat file...and that doesn't even take into consideration upsampling.

 

I also still think that upsampling to high speed can/will make a difference to accuracy.

 

In all likelihood, data was corrupted even before it leaves the computer...why else do you think changing things like buffer size makes a difference in SQ....

 

The only assumption you can make is that data is accurate as a flat file....or at least only as accurate as the digital recording placed the bits....all processing and internal noise and everything can and will corrupt the digital stream.

Link to comment
15 minutes ago, fas42 said:

A visual analogy: a piece of paper full of numbers is photocopied multiple generations, and the toner is running out. The final 'picture' looks 'orrible - but if someone carefully views the poor result every single number can be accurately determined, and a 100% correct new version of that page can be recreated, with perfect clarity ... that's the 'magic' of digital.

 

 We aren't talking about the printing on a piece of paper where the letters aren't always 100% evenly spaced and it doesn't matter if the letters are a little blurred. Just try copying the contents of a forum page to notepad and you will often see just how imprecise looking this can be after digital copying, with some letters almost touching each other in many cases.

They still can't even prevent some letters that you type coming out in the wrong order.  In many cases it should be blindingly obvious that you couldn't possibly have spelled the word that way.

 

We are talking about audio, which for highest sound quality depends on precise timing and lack of blurring due to noise artifacts.

 

How a Digital Audio file sounds, or a Digital Video file looks, is governed to a large extent by the Power Supply area. All that Identical Checksums gives is the possibility of REGENERATING the file to close to that of the original file.

PROFILE UPDATED 13-11-2020

Link to comment

every so many posts, i will requote:

 

Gordon Rankin: What we have here is an explanation with screenshot proof that USB audio transmission isn’t bit true

 

how often, how bad, is relative to OS, software, hardware, processes, noise, etc...

The same can be said for enet, but it has different checking and resend technology, and likely more accurate, but still can be muffed by reasons given.

 

 

The bigger question is, so where does that leave us....i would start that it is with enet that i found i preferred 8 years ago even before advent of usb toys, and probably why i preferred using a used $50 sony bluray player as a dlna endpoint streaming native dsd, even more so than a noisy pc connected to a very high priced DAC.

Link to comment
9 minutes ago, mansr said:

A bit error rate of 1e-12 should be achievable. With 192 kHz 24-bit stereo audio, that's one error every 30 hours or so. Nothing anyone would notice.

Are you kidding....there are so many golden ears on this site that have OMG revelations every other day....they would all make great professional reviewers.

 

in all seriousness....it's distortion...how much is relative....either way, i have reached peace in my own mind.

Link to comment
18 minutes ago, beerandmusic said:

and probably why i preferred using a used $50 sony bluray player as a dlna endpoint streaming native dsd, even more so than a noisy pc connected to a very high priced DAC.

 

 Despite your best efforts, a typical Desktop PC in a metal case is still more than capable of making mincemeat of UHF DTV channels with a nearby DTV indoor antenna, even when it is connected via 4 screening layers of an RG6 cable,  yet according to the usual suspects here it can't even degrade Digital Audio from  inside the P.C. in the slightest.

 

Dream on !!!

 

How a Digital Audio file sounds, or a Digital Video file looks, is governed to a large extent by the Power Supply area. All that Identical Checksums gives is the possibility of REGENERATING the file to close to that of the original file.

PROFILE UPDATED 13-11-2020

Link to comment
5 minutes ago, sandyk said:

 

 Despite your best efforts, a typical Desktop PC in a metal case is still more than capable

 

no doubt a pc can, all things considered....

 

5 minutes ago, sandyk said:

 yet according to the usual suspects here it can't even degrade Digital Audio from  inside the P.C. in the slightest.

 

perhaps only on transmission....but that occurs before leaving the pc...why do you think data is ever resent.

Don't play with buffer settings when upsampling

Link to comment
8 minutes ago, yamamoto2002 said:

If you have a digital input device, and your DAC have a digital output, you can test if the DAC accurately output data bits or occasionally output corrupted data, by yourself with WasapiBitmatchChecker. Connect DAC digital out to digital recorder input and perform loopback test...

 

Following screenshot shows 12 hours of PCM data is sent using my $60 USB audio device and every output bits are correctly received by a PCM digital recording device. This test takes 12 hours to finish :)

 

USB specification says, in the worst case 1 bit in 1000 000 000 000 bit may be corrupted.

 

 

WasapiBitmatchChecker106ss.thumb.png.1894281c6d612b2cc014e9e93b6e95ec.png

 

I don't doubt it for PCM and well tuned pc.... still it's a bit...

 

try doiing same test with crappy pc while doing intensive cad work and upsampling to quad dsd with low resources and lots of noise and purposely screwing up HQP buffer settings..

 

I am not disputing that we are close to a plateau....which is why i always give the "OMG massive improvement" threads much of my disbelief.

 

What about rankins testing in initial post...

 

I am not here to suggest how relative accuracy is or isn't just that it is not bit perfect and even you came to same conclusion.

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...