USB audio transmission isn’t bit true

[beerandmusic]

10 minutes ago, esldude said:

But note what mansr said.  If a single bit is wrong, an entire packet is discarded.  A huge error ensues.  If you aren't hearing the huge errors, then a bit has not been wrong. It isn't like analog where a little bit of low error causes a little bit of less good digital sound.  You get it, and its fine or OOPS, there was an error.  The errors are not a sound quality problem because they aren't happening for all practical purposes.  

that was in his test case....there are literally a million different possibilities with different hardware and different environments...the point is that error rate can and will affect SQ...but again, I believe can be avoided with a "properly optimized system".  I think USB can be fine, but that it is subject to SQ issues....even when using a non-optimized multi function pc, i had hard time telling if i liked usb better than enet or visa versa...so with a well tuned usb system, i see no practical issues.

[beerandmusic]

4 minutes ago, esldude said:

I don't use fancy USB cables.  Unless you consider a Belden fancy.  I've heard no problems using a netbook for basic music playback thru a USB to SPDIF converter.  I normally use a Lenovo laptop, or Macbook pro for music playback.  Or a low energy Lenovo desktop server.  

Ok, cool...i don't get some people that suggest USB is perfect yet they buy a fancy cable...

I use spdif predominantly for my second system...but that is also used with the computer i am typing on (smile).  sounds fine to me...

[beerandmusic]

1 hour ago, esldude said:

But note what mansr said.  If a single bit is wrong, an entire packet is discarded.  A huge error ensues.  If you aren't hearing the huge errors, then a bit has not been wrong. It isn't like analog where a little bit of low error causes a little bit of less good digital sound.  You get it, and its fine or OOPS, there was an error.  The errors are not a sound quality problem because they aren't happening for all practical purposes.  

 

Another thing comes to mind, why things may not be "obvious" noise as in clicks or "horrendous" like mansrs test case, is because the dacs are designed to interpolate....it may not get the right data, so it interpolates (and may or may not be correct interpolation), leading to subtle differences rather than obvious differences....again, just speculating....(I am sure someone will pop in and tell me i don't know what the helllll i am talking about, and i Probably don't)....but again, the point is that even a single misplaced bit can wreak havoc....sure the dac does its best to correct...but again, imho, better to get it right the first time.

[beerandmusic]

 

MANSR>> Damaged packets are detected and reported by the host controller. It probably depends on the hardware... The XMOS based DAC I tested clearly drops bad packets without padding or interpolating.

 

+1

I would rather a DAC drops errors so the errors are more obvious rather than interpolate, where you may not know...I don't want a DAC to interpolate... I say get it right first, without trying to fix...

 

I am glad that both sides agree that DACS get errors, that USB is subject to error rate because of isosynchronous transmission , and the errors can be a result of a number of different reasons...and it appears even in a very stable environment, that a dac can interpolate such that it would be difficult to hear....either way, a USB interface  is unnecessary, and enet may be preferred by many, including LUMIN, who now even offer a network player with fiber input....now we are talking!

[beerandmusic]

9 hours ago, diecaster said:

 

USB is not subject to errors ...

 

Do you use a fancy usb cable?

Dedicated PC?

Optimized PC?

Quality PC?

 

[beerandmusic]

9 minutes ago, diecaster said:

I didn't say that USB is not subject to errors. I said that "A proper USB setup should not see errors as a matter of course."

 

I have used a variety of computers, including laptop, desktop, and server systems I have used "special" and typical USB cables shorter than 3 meters. I have not used an optimized system but always a quality system. I have used special purpose systems as endpoints. This would include the microRendu, the ultraRendu, and various SoTM endpoints.

 

You don't have to do any "special" to get reliable data transfer over USB. You just don't want to do anything unusual like use 6 meter USB cables or crappy endpoints.

 

Ok, i also see you are using an ultra rendu....I can accept that you have a reliable usb solution....I can agree that "A proper USB setup" should resolve for isosynchronous transmission. 

[beerandmusic]

10 minutes ago, diecaster said:

I am using an ultraRendu now.

Why did you switch from pc direct connect to usb?

[beerandmusic]

10 minutes ago, diecaster said:

You mean why did I switch from direct connect USB (computer to DAC) to a server/endpoint setup using USB at the DAC?

 

There were several reasons. One was that I wanted to stop using my office computer or my laptop to play music. I wanted a dedicated server for Roon so whatever I was doing on my computers did not affect music playback. Another was that I wanted the best sound quality possible and I knew that my noisy desktop and laptop systems talking to the DAC directly over USB was about the worst way to go in that regard. Some kind of special purpose endpoint was the way to go there. Finally, I wanted multiple "zones" to play music with all of them accessing the same music. The best way to do that was to have a Roon Core server with multiple "endpoints".  

 

Besides the last point of multiple zones, couldn't a dedicated pc connected directly to a dac do that?

I am trying to determine all the reasons why an enet solution would be superior to a pc directly connected to a dac and why.

[beerandmusic]

1 hour ago, diecaster said:

The premise in the title of this thread is just plain wrong.

 

People keep misunderstanding what my premise is.  The premise is merely that which Rankin stated....that USB transmission (e.g. isosynchronous) isn't bit true.  Nothing more, nothing less.  I never suggested that someone can't create a stable USB solution. Anyway, i have updated the subject to reflect what Rankin stated.

[beerandmusic]

2 minutes ago, diecaster said:

 

Wow. I am not going through all of that. If you have not gleaned that information from this forum since you have been here....well...I don't know what to say.

 

It's not for me...i learned that 8 years ago.  Anyway, i think we are on the same page as opposed to those that reject enet in their solution.

[beerandmusic]

8 minutes ago, diecaster said:

In fact, the ONLY reason one would even consider using a protocol that did not retransmit bad packets is if you didn't think bad packets were going to be a serious issue.

 

 

Another reason not to re-transmit bad packets is to play real time.

[beerandmusic]

22 minutes ago, diecaster said:

 

Let's assume that "real time" is an issue here (which it is not). If data arriving incorrectly was a common problem, you would hear it. You would for sure use a system that guaranteed data delivery.

 

 

I am just saying that is likely one of many reasons that protocol was chosen rather than "because it is not a serious problem".

 

https://www.edn.com/design/consumer/4376143/Fundamentals-of-USB-Audio

and

https://www.edn.com/design/consumer/4419643/Select-your-USB-audio-MCU-with-care--Scary-stories-from-the-test-bench

 

[beerandmusic]

11 minutes ago, davide256 said:

Given the improvement AL makes and that a device like ISO Regen becomes much less useful with AL, I don't believe that the significant "gremlins" are in USB...

 

Agreed...but I don't really think it is AL specific though....the fact that it is dedicated, low power, stripped down, and optimized are key.  Same can be accomplished with Windows, but it is nice that AL has created a bootable stripped down OS that can run on a dedication box to achieve a fast, easy and inexpensive solution.

[beerandmusic]

I wonder why some designers are moving to bulk-pet over isosynchronous for DSD to shorten the audio latency.

 

https://www.itf.co.jp/prod/audio_solution/bulk-pet/bulk-pet-en

 

It is defined to using Isochronous Transfer to transmit the audio data in USB Audio Class.
Audio data is transmitted in a constant period in Isochronous Transfer.
On the other hand, huge proccessing loading also appears in a constant period on host CPU and device CPU.
This huge processing loading causes the sound quality slight changes.

Bulk Pet is the technology that transmitting the audio data in Bulk Transfer.
In Bulk Transfer, it’s able to control the transmission data volume and transmission frequency.

 

Also...Still no one has injected noise in quad dsd and see if error rate goes up?

[beerandmusic]

What is the theory that 100 different usb cables can give 100 different SQ?

[beerandmusic]

Forget about noise for a moment and pretend all there is, is music being transferred. 

Tone, harmonics, bass, treble, everything that is music is represented by the digital data.

If all of these musical attributes are represented by this digital data, how can losing a bit here or there just cause a drop out and not a difference in tone?  If tone is represented by data, and data is lost how can tone not be incorrect?

Sure, you can say if it recieves too many errors it drops the entire packet, which would result in a dropout....but what is the case in interpolation, where it interpolates rather than drops the entire packet? If the dac never interpolates, why even have the interpolation circuitry.  I mean is there one DAC engineer in the bunch here that can explain this?  Just curious is there a DAC engineer that reads these threads?  Not just a hobbyist, but a professional of a known company?

[beerandmusic]

2 minutes ago, diecaster said:

 

It’s like using 100 different filters. Each is going to sound a bit different. 

So how does a filter give more detail, more sound stage?  The music will be the same (bit perfect) regardless of the filter, correct?

[beerandmusic]

Just now, esldude said:

Well the real car is what you're talking about doesn't happen.  Nothing gets dropped.

Mansr stated when there are errors it is either dropped or interpolated.

[beerandmusic]

12 minutes ago, diecaster said:

 

Look, this has been covered ad nauseam. 

 

The USB cables change the noise and other crap that come along with the digital data. This means the USB receiver sees different signals with different cables so the sound is changed in different ways depending on the USB cable used. 

 

Besides noise, what is "the other crap"?  It is my understanding is all that exists is music and noise (albeit different kinds of noise...so lets just call it noise).

If the music is the same regardless of the noise how do you get more music (e.g. more detail) by using a "noise limiting" cable?  You can't create more music than what exists...and does that mean if you eliminate the noise FIRST, that a noise limiting cable does nothing?  And again, all the more reason to use fiber and forget usb to isolate noise.

[beerandmusic]

16 minutes ago, esldude said:

And that it happened about one time every 30 hrs of listening maybe.

There are lots of different environments, and lots of different hardware, and different dac engineering, etc..etc.......my guess is that if someone is not using a dedicated pc, if it is noisy, it is certainly feasible some environments will have more errors, and interpolation can happen, and give subtle differences, that the listener doesn't even realize there is an issue because of interpolation.

[beerandmusic]

5 minutes ago, yamamoto2002 said:

Musiland USB devices also uses bulk transfer.

 

USB shares one bus to all USB devices connected to one host controller. In order to transfer 96kHz 24bit 2ch PCM (4.6Mbps) on USB 1.x FullSpeed bus (12Mbps) (it is about 40% of USB bus bandwidth capacity), It is necessary to use a mechanism to allocate some length of time slot sorely for the audio data transfer before audio transfer starts and return it after use, isochronous transfer mechanism do the job.

 

If bulk transfer is used, the amount of the data transferred varies on the bus traffic, it depends on other devices' transfer activity, maybe USB memory data transfer occupy 80% of the USB bus capacity. in this case, your bulk transfer USB Audio DAC cannot send 40% of the capacity audio data properly and playback stops or other glitch happens.

 

But now host controller becomes USB 3.0 (5,000 Mbps), it has plenty room for spare, so bulk transfer can be used for USB Audio data transfer scenario unless USB bus is intentionally saturated

+1

Thanks for sharing...you clearly know a lot more than most here. 

To clarify in layman's terms, USB 3.0 because of higher speed, along with bulk transfer, is ideal?

Can processing quad DSD on USB 2.0 be an issue if not properly managed?...e.g. is there ever a bigger concern with processing quad DSD as opposed to 44.1 PCM?

 

PS are you a dac engineer?  Do you see any advantage in doing fiber (e.g. the new LUMIN X1 with fiber input)?

[beerandmusic]

18 minutes ago, yamamoto2002 said:

 

 

Quad DSD(23Mbps to 45Mbps) on USB 2.0(480Mbps) should not be an issue. I've tested it and it runs fine.

 

 

 

Ok, thanks...I am hoping to find opinion from DAC engineer perspective regarding quad dsd, noise, error rate, and interpolation.  Bulk seems like it would make sense where real time isn't concern...but still think fiber and enet ideal....e.g. get it right first and don't worry about fixing or simplify dac receiving engineering.

[beerandmusic]

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

[beerandmusic]

Here also suggests that noise can corrupt the data, not just dac circuitry processing...

From mojo audio:

 

=====----

 

All computer communication works on a system of checks and error correction (check sum). If a packet of data doesn’t pass the check, a new packet of data is sent to replace the original. The lower the power supply noise, the lower the amount of data corruption, the lower the amount of corrupted data to correct, and the greater the system resources.

 

... When a low-noise power supply is used with a computer-based music server or streamer the result is more liquid and articulate sound, combined with greater depth, detail, and dynamics.

 

====----

I still would like test run on quad dsd signal and purposely inject noise and see if error rate is increased....

 

 

^^^^disregard...i am not sure i buy some of the stuff mojo audio states in that article (lol).

 

 

 

[beerandmusic]

I made a comment earlier...not sure if in this thread or another, but that since we know we can never achieve 100% accuracy, why even worry.  Even if we had 100% accuracy (in regards to flat file on disk), that we wouldn't even know it, like OMG that sounds perfect, since we are very close to a plateau of sort already...

It is very possible, even if we had 100% accuracy, we may find that we like an algorithm provided by one dac over another as more "enjoyable", and you can have the most expensive components to try to achieve accuracy, yet generating internal noise...or you can have a simpler circuit with a good algorithm that makes the music pleasing...again, not even knowing what noise or error rate exists before the DAC did it's magic.....

 

Here, Barrows says something very similar here:

==========

 I find with DACs, the trick is getting all the details, while at the same time having a natural sound.  It does appear,so far, that this approach of reducing the processing inside the DAC itself, is promising in this regard.  Apparently the forthcoming model from PS Audio is addressing the same concerns....

====