USB audio transmission isn’t bit true

[beerandmusic]

another interesting read...also touches on usb 3.1

 

https://www.soundguys.com/usb-audio-explained-18563/

 

[beerandmusic]

nvm

 

 

[tmtomh]

On 12/1/2018 at 9:27 PM, beerandmusic said:

 

SUMMARY:

Everything i believed starting this thread is EXACTLY the same as what i concluded....people tried to read into what i was saying, but did so incorrectly....

 

In Reading article in below link, IFI says EXACTLY what i was saying...that i am not convinced that errors will only cause a dropout, 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 they suggest exactly as i guessed....

 

https://www.audiocircle.com/index.php?topic=148763.0

 

EXCERPT FROM IFI  ==

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.

===

 

Note also from above excerpt, they also state that noise can causes errors and data loss...something else i said but that was rejected....I deduced both of these FACTS by logical reasoning...never read it before, and it went against everything that most people here have claimed......

 

When you get errors, and you will (more so if noise, interrupts, buffer settings, heavy processing, etc....many things can affect error rate) which leads to either 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.... ..

 

None of these facts suggest one cannot 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 in handling the error rate...

 

 

 

22 hours ago, beerandmusic said:

SUMMARY:

Everything i believed starting this thread is EXACTLY the same as what i concluded....people tried to read into what i was saying, but did so incorrectly....

 

In Reading article in below link, IFI says EXACTLY what i was saying...that i am not convinced that errors will only cause a dropout, 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 they suggest exactly as i guessed....

 

https://www.audiocircle.com/index.php?topic=148763.0

 

EXCERPT FROM IFI  ==

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.

===

 

Note also from above excerpt, they also state that noise can causes errors and data loss...something else i said but that was rejected....I deduced both of these FACTS by logical reasoning...never read it before, and it went against everything that most people here have claimed......

 

When you get errors, and you will (more so if noise, interrupts, buffer settings, heavy processing, etc....many things can affect error rate) which leads to either 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.... ..

 

None of these facts suggest one cannot 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 in handling the error rate...

 

You literally cut and pasted the identical, full, long comment again. That is the definition of someone who's not interested in what anyone else says that might in any way conflict with what you already thought when you started. This is deeply anti-social behavior, the web-forum equivalent of sticking your fingers in your ears and going "lalalalala," or shouting over people.

[sandyk]

8 minutes ago, tmtomh said:

That is the definition of someone who's not interested in what anyone else says that might in any way conflict with what you already thought when you started. This is deeply anti-social behavior, the web-forum equivalent of sticking your fingers in your ears and going "lalalalala," or shouting over people.

 

 That can also be said of many threads where the OP reserves the right to ask Admin to remove posts that are critical of, or disagree with the views expressed by the thread starter. A few members rigorously enforce this provision.

This applies to both Objective and Subjective members.

[tmtomh]

6 minutes ago, sandyk said:

 

 That can also be said of many threads where the OP reserves the right to ask Admin to remove posts that are critical of, or disagree with the views expressed by the thread starter. A few members rigorously enforce this provision.

This applies to both Objective and Subjective members.

That may be true; it's also irrelevant unless those members are having posts removed and repeatedly insisting that they welcome disagreement.

[sandyk]

21 minutes ago, tmtomh said:

it's also irrelevant unless those members are having posts removed and repeatedly insisting that they welcome disagreement.

 

You can have dissenting views removed on request . Period !

[Ralf11]

You can't hide from reality

[AudioDoctor]

58 minutes ago, Ralf11 said:

You can't hide from reality

 

Eventually, Robert Mueller, I mean Reality, catches up with you.

[Arpiben]

6 hours ago, sandyk said:

 

Most recent DACs use an asynchronous sink coupled with an adaptive source (the host computer) ?

 

Recent DACs use an Asynchronous Transfer Mode.

It means that the DAC takes the data from its buffer using a first in, first out (FIFO) logic, and controls the timing using its own clock. The timing of the signal is, therefore, completely independent of the computer/DAP hence the asynchronous term.

USB is isochronous ( single clock/timing) inside computer. When dealing with USB data transfer you have different possible modes.

In asynchronous transfer mode DAC controls its buffer size by requesting host a variable packet size in order to avoid buffer Ful/empty states. Hence host is an adaptive source.

[PeterSt]

SUMMARY

?

[PeterSt]

6 minutes ago, Arpiben said:

USB is isochronous ( single clock/timing)

 

I'd make "constant rate" of it. And literally in our USB audio situation "constant rate per same amount of data (sent)".

 

What about an isochronous error rate ? (quest for BaM).

This exists in practice ...

[esldude]

5 hours ago, beerandmusic said:

 

 

 

interesting read here...albeit dated 2012 (smile).

 

 

To qualify as an asynchronous DAC, ... the designer would throw away the source clock and rely only on the DAC’S internal clock. There are scarce few of these around.  scarce in 2012, how about now?  do all dacs "throw away source clock" and use dac's clock?

 

https://www.psaudio.com/pauls-posts/myth-asynchronous-dac/

 

I also read, but don't know if true or not, the question of if host(computer) transmittting in isochronus mode, it doesn't matter if dac is asynchronous or not....

 

Perhaps the driver would indicate if you use the DAC driver vs an os supplied driver?

You might be almost on the verge of nearly possibly maybe getting somewhere.  That part where you say don't know. 

 

Yes, asynch USB's main purpose and advantage was to completely divorce the sample rate clock from the USB input. The clock on the DAC chips of USB DACs is a free running crystal which is the best, lowest jitter way to time out samples.  The rest of the system adapts to keep a small buffer at the right level so this is possible.  This is no longer rare at all, but pretty much the norm.   Combine this fine clocking situation with USB rarely ever getting single bit error and you have a nice solution for digital audio sourced from a computer or other digital devices. 

[PeterSt]

Hey Beer, it is all about the most processor cores at the lowest speed.

 

 

See ? no error in 7 days of time. This is the lowest processor core count I could find in the house, but I bet you: double the cores and the error rate even gets negative. When I half the processor speed (770MHz now) I get a negative error rate as well.

These negative errors are buffered so they can be consumed when an error might occur. It is all about balance.

[beerandmusic]

They are all still running in isochronous mode, meaning a fixed and time sensitive data transfer based on the sample rate and bit depth.

 

https://www.audioasylum.com/cgi/t.mpl?f=pcaudio&m=125491

[beerandmusic]

8 minutes ago, PeterSt said:

Hey Beer, it is all about the most processor cores at the lowest speed.

 

 

See ? no error in 7 days of time. This is the lowest processor core count I could find in the house, but I bet you: double the cores and the error rate even gets negative. When I half the processor speed (770MHz now) I get a negative error rate as well.

These negative errors are buffered so they can be consumed when an error might occur. It is all about balance.

 

don't doubt it in a highly optimized system...have said so many times already in this thread, maybe i should repeat the summary again (smile).

take a worst case scenario, what about in a non-dedicated slow multi-function pc, doing software upsampling, with noise and a crappy usb cable like the one MANSR used for his test, and an old cheap dac (lol).

 

Question is, can noise cause crc errors and can DSD processing and timing complicate matters more?

 

Since you can run tests, try doing a test doing software upsampling and injecting noise and see if you can introduce errors....

 

Most of the people in the OMG MASSIVE IMPROVEMENT THREAD are doing upsampling and reporting clear benefits going over enet.  Are they full of crap, or possibly something else is making a difference with streaming vs usb?

[PeterSt]

5 minutes ago, beerandmusic said:

can DSD processing and timing complicate matters more?

 

No.

[beerandmusic]

1 minute ago, PeterSt said:

 

No.

I edited my last response....please elaborate on all points.   Do you do dsd?

[PeterSt]

6 minutes ago, beerandmusic said:

a crappy usb cable like the one MANSR used for his test

 

Useless test. Stab your 4 tires and see how far you come and provide a report of how good or bad your Mustang now is.

[beerandmusic]

6 minutes ago, PeterSt said:

 

Useless test. Stab your 4 tires and see how far you come and provide a report of how good or bad your Mustang now is.

 

Mansr didn't find the test useless or he wouldn't have done it....i don't find it useless either.

I like to take things to extremes which make things more clear.

If you have a TERRIBLE environment and you have notable problems, but don't see errors in an optimal environment, in all likelihood, there are many environments in between the two, where subtle differences may exist.

If a LOT of noise clearly causes CRC errors, causing dropouts and buzzing, and no noise causes no crc errors, it is likely some noise will cause distortion...which is also what IFI stated.

 

I am confident that you have a high power computer have optimized for noise and have a very nice environment for your testing...that is NO DOUBT TO ME, and in my summary, i have stated and will state again, that I do believe one can create a solid USB solution.

[PeterSt]

8 minutes ago, beerandmusic said:

can DSD processing and timing complicate matters more?

 

No.

USB does not know anything about what data is flowing over it. Let alone what kind of audio "protocol" it is. The driver has to support it, though (unless DoP).

 

One could argue that the current distribution will be different because of the contents of the data at the detailed level - the bit. So thinking about it, DSD could imply a more smooth distribution.

Does it make that less prone to error ? no. USB complies to standards and those standards must be met (no flat tires allowed). When all that is fine, no errors occur. But it is perfectly allowed to have some. And no, no windows go out. Only when you interpret mansr's text about that wrongly. When one packet is invalidated (or goes through but with plain wrong sample data) you may hear one small scratch. This is because a packet contains audio data of a few ms only (I did not do the math).

[PeterSt]

4 minutes ago, beerandmusic said:

 

Mansr didn't find the test useless or he wouldn't have done it.

 

It is/was useless for those who interpret it with bias (you). For example, for me it is not useless at all. It determines what can be done with USB before it breaks (for audio). So if you want to learn from it, take the good parts with the proper merit (and context).

Two examples:

 

The Clairixa USB cable we make, was tested with 7 meters and is still without error. It was made to do that by applying the best USB specs as I could do.

 

The Lush USB cable we make, is not guaranteed beyond 3 meters and I actually don't like to sell even the 3 meters (ask @Teresa who owns (or owned) one of the two I ever put out). It deliberately voids the USB spec and thus this comes from it. Problem ? no, because it is anticipated.

 

We can "tweak" all in all direction as long as it does what it was made for. You (and everybody) may disagree with that.

 

I now see you think: oh, so that Lush better not be used in that hostile environment ? well, unrelated again because it isn't about noise. It is about impedance and reflections and more voodoo. Noise too, but no noise you envision.

Coil up your cables and tell me where the noise suddenly comes from (nowhere, but still they stop working well).

[beerandmusic]

7 minutes ago, PeterSt said:

 

It is/was useless for those who interpret it with bias (you). For example, for me it is not useless at all. It determines what can be done with USB before it breaks (for audio). So if you want to learn from it, take the good parts with the proper merit (and context).

Two examples:

 

The Clairixa USB cable we make, was tested with 7 meters and is still without error. It was made to do that by applying the best USB specs as I could do.

 

The Lush USB cable we make, is not guaranteed beyond 3 meters and I actually don't like to sell even the 3 meters (ask @Teresa who owns (or owned) one of the two I ever put out). It deliberately voids the USB spec and thus this comes from it. Problem ? no, because it is anticipated.

 

We can "tweak" all in all direction as long as it does what it was made for. You (and everybody) may disagree with that.

 

I now see you think: oh, so that Lush better not be used in that hostile environment ? well, unrelated again because it isn't about noise. It is about impedance and reflections and more voodoo. Noise too, but no noise you envision.

Coil up your cables and tell me where the noise suddenly comes from (nowhere, but still they stop working well).

 

archimago found no errors with a $10 belkin cable and even with 50' extension cable....again, i would like to see if crc errors can be increased by injecting noise on system doing quad dsd processing.

[PeterSt]

23 minutes ago, beerandmusic said:

try doing a test doing software upsampling

 

I may not help you, but I constantly run at the highest speed through USB (you saw 352.8 there but this is only half of the applied frequency which thus is 705.6) and I can promise (and guarantee) you that this is again unrelated to the possible error rate (once the driver allows for this high speed). USB errors spring from other anomalies like capacitance build-up.

 

I just told about isochronous error rate. You thought I was funny. But I was serious;

I can almost set my clock on USB errors once such a thing is in order. Like once per 4 minutes a burst of 100 errors (etc. etc.). Or once per 10 seconds one only.

Now dig in your memory how often you have seen people report something like "regularly" or "once per minute or so", etc. In the end this is all grounding related with no recipe to to solve it. One thing: it can be solved in the device at the manufacturer once you see it coincidentally happening. This time ask @Superdad.

This is not related to noise at all. "Bad situation", is.

[PeterSt]

6 minutes ago, beerandmusic said:

again, i would like to see if crc errors can be increased by injecting noise

 

Stab your tires and go around the block. So if that is your fun.

The answer is Yes.

Now what ?

Nobody likes to drive with punctures.

[PeterSt]

28 minutes ago, beerandmusic said:

it is likely some noise will cause distortion...which is also what IFI stated.

 

BS