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
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
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

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
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
22 minutes ago, sandyk said:

 

It isn't with Coax SPDIF which when properly implemented can still outperform USB  which hasn't had a heap more $ spent on it to improve the Signal Integrity of the Data sent to the DAC.

Unfortunately, if you need DSD you often have to rely on this flawed transmission medium which was never designed for A  and V.

 

You don't have to rely on usb for DSD, which is why i haven't for over 8+ years.

 

I am not going to even suggest that you can't have quality DSD with usb where everything is optimized properly....i would never say that.

 

I just know that I preferred native DSD over enet, compared to my noisy pc over usb....(again, i switched to enet 8 years ago before talk of usb noise and usb toys)

 

That isn't even the point of this thread...my only point is that the music bits do not always arrive at the dac without corruption, which is what most people have tried to sell.

 

Link to comment
13 minutes ago, fas42 said:

 

While you keep trying to have the digital corrupting as "the answer of everything"

 

I certainly know it is not the answer to everything, and in actuality is miniscule to the system on a whole.

I just had a problem accepting what people were trying to sell, and making sense of it in my own mind...the reason i couldn't make sense of it, was simple...it wasn't true.

 

After reading this, i understand a lot more that i had so much frustration with, because people kept suggesting that no matter what, that the DAC gets the DATA accurately....when in reality that is totally untrue...I am not saying what i learned will make even 1% difference in the end game...but the fact that I can accept some theories now, and reject other theories, got me past a hurdle in a more full understanding.  I now can accept why buffer settings matter, why enet makes a difference, and many MANY other issues I had, that now i see clearly things that bugged me the most.   Kind of like like when i came to the realization of why God wants praise...it was one of the biggest difficulties I had when i was a non-believer...once I found the answer to that one thing, everything became more clear....I am not sharing that for the purpose of sharing religion, I am sharing that so that you can understand what I am saying....that everything became more clear to me....btw, God doesn't want praise..that is a gift for us.

Link to comment
8 minutes ago, mansr said:

He did. You provided the evidence. It's not interesting that he once observed an error. Only the error rate is meaningful.

not disputing the error rate....just that it is not always bit perfect.

Again, everything is relative..i am not going to argue what is audible or not either, or that upsampling software can make a larger difference.... just that there can be a difference.

If there can be even one bit difference in a pcm recording in an ideal environment...there are potentially larger differences in different environments..

 

For me, it changed the whole ballgame....for everyone else, maybe not so much.

Link to comment
14 minutes ago, mansr said:

Of course there will be an error if you wait long enough. Nobody sane has ever claimed otherwise. What is claimed, and rightfully so, is that the error rate in practice is low enough as to be utterly irrelevant.

 

Yama Specs stated for Isosynchronous or bulk or both?

 

Most everyone agrees that killing processes makes a difference in SQ...what is theory?  Is it possible that if yyou have a ton of processes that in bulk you would resend, but not in Isosynchronous?

I don't really know, and don't really care to...I am not disputing error rate, just that it exists, which allows my theories to make sense....as long as it is fully accepted by everyone, that error rate does exist and can differ based on a number of factors.

 

Hell, it would be nice if both sides could meet on one thing ....after all, it is about harmony (grin)

 

 

 

Link to comment

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

 

For the record, I believe both sides (usb or enet) are at or near a plateau inre digital front end, and if properly optimized, no one could tell one from the other in a DBT.....but then again, i believe we were there years ago.

 

The ONLY real OMG MASSIVE IMPROVEMENT observations that exist (inre digital front ends) are by the people that are finally getting where we have already been for many years....i don't even expect an OMG with optical, but i am going to do it anyway.

 

I still believe more gains can be realized in optimizing DSD...mainly because i think there are more things to pay attention to.

 

Link to comment

GORDON: 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.

 

ME>>Probably why some usb toys had more effect on some dacs more than others and why some usb toys had no effect.

Guessing Noise "can" cause more errors.  Killiing processes "can" cause less errors.

Maybe most engineers don't see it, because they already have taken preventative measures in their environment.

Just because many people do not see any errors, they are not seeing everyone's enviornment....

 

Again, point is not how much, and now it seems even the most objective opinons acknowledge error rate exists, which at least satisfies me, even if everyone agreed that there is no difference in SQ regardless of noise, processing, etc...the simple fact that these things can change error rate, allows my logic.

 

 

 

 

 

 

Link to comment
24 minutes ago, tmtomh said:

 

This is what this thread - and most of the other threads you start - really is about: You've found information that you think confirms what you want to believe, and you've no interest in any new or additional information that would complicate or negate what you think you know - all you care bout is "piece in your own mind." That's fine - but it's got nothing to do with a discussion forum. Just say it into a mirror and you'll achieve the same effect as posting it here.

on the contrary, i have been told by people on both sides that "maybe what i say makes no sense, but it makes them think (wink)"....again, my philosophy is that everyone has different gifts....and i am ok that your philosophy is different than mine...i have advice for you, but I am not allowed to share it.

Link to comment
51 minutes ago, esldude said:

So dacs get the bits in completely accurate order more than 99.999999999999% of the time. Apparently more often than that some human has the mal conceived idea this rate of reliable performance is a problem. 

 

Now that everyone agrees that usb does not deliver the bits with 100% accuracy, let's ponder the following:

 

Why does killing processes and changing buffer size improve SQ?

 

If all that exists is music and noise, how exactly does that translate into noise and influence the processing?

 

Is it that the dac can't handle the noise or is it that the noise causes an error, and that some dacs having to process for that error causes things like (more detail, more soundstage, ...etc..)?

 

RANKIN:

  Isosynchronous frames are afforded high priority in the system, but interrupts can affect priority.... 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.

 

You may believe or not believe what Rankin says...but i think he knows USB more than most people here...perhaps not all, but most.

 

Curious why people believe one enet solution sounds different than a usb solution at all...shouldn't all enet and usb solutions sound the same given same os, same power, same everything else?  So no matter what the os settings are, no matter what power supply you use, no matter what OS or how many processes you have, the music is always recieved 99.99999999999999999999% accurate...and this mysterious noise signature that makes every usb and every enet solution unique can affect the DAC processing, but cannot affect the music...yet it is consistent...like more bass, more detail, more soundstage, not in a malfunctioning way, but all the time...I guess that is logical to some people.

 

Anyway, I made my point, the audio engineers can discuss as to why there are consistent differences by things like killing processes, changing buffer settings, etc...

I am not going to suggest that it is a problem or what the real issues are, because it is not my expertise...my only point of this thread is that I know now that DACS do not always receive data with 100% accuracy...and that different things can affect that accuracy. 

 

Read and understand the article and point out where Rankin is wrong and why...after all who cares what I say, i don't know crap, and am only quoting Rankin who likely knows more than "most" people here inre Audio....instead of being offended by my word "most", show your knowledge is greater than Rankin and disprove him....By ridiculing or responding to me, you are only showing your own ignorance, since i will be the first to admit I don't know anything about audio engineering.

 

Link to comment
5 minutes ago, JohnSwenson said:

I have done same tests that Gordon did and get similar results. Under some conditions you can get lots of data errors (many per second) with USB audio, under other conditions you can get no errors for days.

 

The biggest correlation I got was with cable length. With a cable greater than 3m you have pretty good chance of getting a large number of errors. Under 2m errors are few and far between (days between errors).

 

Between 2m and 3m is where the fun happens, you can trade off cable length and cable quality. For example with Supra cables you can go with significantly longer cables than cheap cables. In this range hardware has significant impact. For example my SuperMicro motherboard is error free with longer cheap cables than my cheap laptop.

 

I also did a lot of listening to the audio with different error rates on the USB. At low error rates the sound is identical. As error rates increase you start hearing the infamous clicks and pops. If you are getting say a click per minute, the sound quality in between clicks doesn't change. As the clicks come more often they get so annoying its impossible to tell if the sound quality is changing or not. At some point the errors come so often the system just shuts down, it can't handle that many errors. (a 5m cheap cable has a high probability of doing this).

 

So my conclusion was that if you stay with cables less than 2m you can be pretty sure you are essentially error free.

 

These rare bit errors do not seem to cause any sound change (other than a possible click).

 

John S.

 

thank you sir....one smart cookie in the bunch. 

Any testing inre quad dsd upsampling?

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...