Audio PCs: Waste of Time?

[sandyk]

Just now, CuteStudio said:

Only the shunt regulator or an LC filter can help the input, all will help the output, but I'm confused - why do we care about the power the SSD gets?

 

 We care about the power that the SSD gets because it matters !!!

We are never going to agree on this because as a software person you can't see any possible reason for the improvement in SQ that can result from markedly improved power to even the OS SSD.

It's no coincidence that my friend Greg Erskine was unable to hear the differences between  comparison .wav files at our listening sessions, despite the others present being able to readily do so. Greg was employed in I.T. and it would appear that his brain refused to let him hear the differences, because he refused to accept that it was possible because of his training.

 

 It may seem more than a little far fetched to you, but even the power supply used can effect how the SQ of a bit perfect file sounds, both when being saved and played. I am able to manipulate how a digital music file sounds by even changing the types of capacitor used in the capacitance multiplier section of the JLH , just as Peter St.( Phasure NOS DAC and XXHE software, is able to change the sound of bit perfect files with his software.

Martin Colloms has already verified the SQ changes I have made while manipulating this PSU  area.

 

[Don Hills]

8 minutes ago, CuteStudio said:

...

It's true that computer engineers find it difficult to accept that one file is noisier than another if they digitally compare to be the identical. Perhaps then you could put this one to rest by explaining where the noise lives in the file. 

 

I.e. we know the digital part of the file is perfect, so anything reading it gets the same data as the original, but if there is nose in there could you explain where it is? TIA!

 

Once that's explained we could then work out how it becomes audible again.

 

Be careful what you ask for. Alex could bore for Africa on this topic.

[CuteStudio]

6 minutes ago, sandyk said:

 We care about the power that the SSD gets because it matters !!!

 

 

Lets leave the discussion of where the noise lives in the digital file to the other post I did. In this one (which is about series vs shunt regulators I had the following question:

 

You also said earlier:

It's about reducing the HF rubbish going back into the main supply due to fast switching transients of an SSD. HDDs are far less problematical in this respect .

 

But here you say it's about smoothing the output - which one is correct?

Only the shunt regulator or an LC filter can help the input, all will help the output, but I'm confused - why do we care about the power the SSD gets?

 

So is the filter about just the output, or the input too?

 

[sandyk]

15 minutes ago, CuteStudio said:

You also said earlier:

It's about reducing the HF rubbish going back into the main supply due to fast switching transients of an SSD. HDDs are far less problematical in this respect .

 

But here you say it's about smoothing the output - which one is correct?

 

BOTH are correct !!! This also applies to reading and writing with an internal LG BR writer where there is a decided advantage to using a highly stable PSU supplying it. The C.A. member (alfe) who actually designed my internal LG GGW H20L BR writer has also confirmed to me that it works better when using an improved PSU, but cost restraints do not permit this in the device itself.

 

JLH internal PSU for LG BR writer.

[CuteStudio]

2 minutes ago, sandyk said:

BOTH are correct !!! This also applies to reading and writing

 

Ah Ok, I see. Using a series regulator would suck for the input so really you just want a Shunt type like in Greg's hidden page reference, so GUTB did in fact fit the wrong one.

 

It does seem like it's very important to clear up where the noise in the file is now, and how it gets back into the music in the DAC, waiting for that, it's new for me. 

 

BTW I note earlier you said that the Raspberry Pi had "Mediocre SQ" which I have been thinking about because it's sounding really very very (very) good indeed. I mean like the singer is right there in the room in front of me good. Sweet flowing treble, real cymbals and lovely bass good.

Perhaps it could be improved upon - most things can after all - but I'm struggling to imagine that right now, and TBH the next improvement would be moving to a digital crossover and Biamp system which wouldn't really involve any change to the Pi at all...

[sandyk]

22 minutes ago, CuteStudio said:

It's true that computer engineers find it difficult to accept that one file is noisier than another if they digitally compare to be the identical. Perhaps then you could put this one to rest by explaining where the noise lives in the file. 

 That's the $64 question!

 If I had to hazard a guess, I would suggest that it may be due to the extra processing required to process a less  than perfect binary waveform (timing,rise and fall times, varying voltage levels etc.)

Have you ever seen the read waveform of a HDD before processing ? You may still be able to find an example using Google.

It's not how the files check out using Binary comparisons, it's how they sound at the output of the DAC!

 

Do you really believe that all the members that hear marked improvements in SQ when the SMPS in their Mac Mini is replaced by a John Swenson designed JS-2 Linear PSU are hearing improvements because the 1s and 0s are no longer the same ?

 Of course they still are the same . They are hearing these improvements without changing anything after the outgoing USB port. Please don't even suggest that it is a placebo effect. It isn't !

[sandyk]

28 minutes ago, Don Hills said:

 

Be careful what you ask for. Alex could bore for Africa on this topic.

 

 That's great coming from an EE who believes that any differences heard between USB input DACs are all due to poor USB input  implementations in the DAC !

Perhaps you should team up with Mansr and create a perfect DAC ?

[sandyk]

18 minutes ago, CuteStudio said:

Ah Ok, I see. Using a series regulator would suck for the input so really you just want a Shunt type like in Greg's hidden page reference, so GUTB did in fact fit the wrong one.

 

 No. Apparently, it was how he implemented it ,where previously he was using a different Linear  PSU.

(See the reply by LTG2010 on the previous page)

It can make a small but worthwhile improvement when you are stuck with just using the internal SMPS.

This has already been verified by several other C.A. members.

[CuteStudio]

1 minute ago, sandyk said:

 That's the $64 question!

Oh :(. I thought that was the easy part.

 

1 minute ago, sandyk said:

 If I had to hazard a guess, I would suggest that it may be due to the extra processing required to process a less  than perfect binary waveform (timing,rise and fall times, varying voltage levels etc.)

In any binary system there is a point when a bit of hardware has to decide if something is a 0 or a 1.

This is irrelevant of timing, rise and fall times or anything else. When the clock falls the decision is MADE.

 

That decision then forms a new voltage level that gets recorded to a register or fifo etc. That decision and information is 'binary', i.e. 0 or 1. There is no grey area or fuzzy logic, once the decision is made even a wobbly 1 is a firm 1 and a wobbly 0 is a firm 0. The register values the decision is stored in can only also hold a binary value, there is nothing else in the system available to store the information, we are mathematically limited to 0 and 1.

 

1 minute ago, sandyk said:

Have you ever seen the read waveform of a HDD before processing ?

 

Yes, I am aware of hardware like that, the decision is still the same, 0 or 1. If the data is misread from a disk then the hardware does a series of retries to get the data, and will rewrite dodgy stuff or mark the sector and copy the data to a fresh sector. If the data simply cannot be read correctly then you get a disk error which is signalled to the OS and you don't get your file: Read Error.

 

Therefore we know the actual shape of the HDD waveform is not at issue because there is that clear decision point of a 0 or 1 that is made, and if it's wrong we'll not get our data. This is quite different from a CD read error that will just give us a fudge instead, with a computer disk the data integrity is critical because all the programs will error if it wasn't 100%, so it's maintained with an iron rule.

 

1 minute ago, sandyk said:

It's not how the files check out using Binary comparisons, it's how they sound at the output of the DAC!

This is where we need to determine - from an information viewpoint - where the noise is hiding in one of the files when it's binary identical to the file that is claimed to sound better. Somehow that data has to exist - right? It exists in a state that the computer cannot detect but you say the DAC can, so how does data that is undetectable to the computer get loaded into the block based USB data packets....   ... if the computer itself can't read them?

 

So we have 4 problems:

1) Where does the noise live when the data is stored?

2) How does it travel when each computer along it's journey can't detect it?

3) How does it travel into the DAC if the audio player can't detect it?

4) If the noise is not explicitly send out - how does it know where it's going?

 

1 minute ago, sandyk said:

Do you really believe that

I don't believe.

Anything.

 

Belief is a stronger mechanism that mere facts and data therefore I stay away from it.

All i can say is that I have no idea of any details of any test setup where people claim to hear it. 

All I do know is the facts and the 3 logical and physical problems as listed above, which must be solved in order for the difference to be real. I'm not saying it's rubbish, my opinion is irrelevant anyway;

 

but I'm saying that logic and facts are denying the effect. Can you see my problem? If the CPU has no awareness of this data how can it clock it into the registered to be sent anywhere? So if it doesn't clock it anywhere, how does it reach the destination. To download a file (for instance over wifi at home to play) each packet is specifically addressed and send by the CPU. How does the noise even know where to go? Say I have 10 computers on the network and am streaming to one - why doesn't the noise go to a different computer?

 

[sandyk]

23 minutes ago, CuteStudio said:

BTW I note earlier you said that the Raspberry Pi had "Mediocre SQ" which I have been thinking about because it's sounding really very very (very) good indeed

 

 Many DIY Audio members thought the same about their SBT's before John Swenson presented a good Linear PSU design for it. This is an area that Marce should also investigate with his own SBT

[sandyk]

20 minutes ago, CuteStudio said:

but I'm saying that logic and facts are denying the effect. Can you see my problem?

 OTOH, I am saying that 6 separate DBTs correctly performed are verifying the effect, just as Barry D did with the comparison CD-R that I sent him.

 Obviously , something was a little different about the data burned for consecutive pairs of .wav files on the comparison CD,  despite what the checksums said when it was ripped to HDD again. 

Incidentally, I sent him the CD to play the comparison tracks directly, not rip them to HDD again. Nevertheless, he and his wife still heard small differences after ripping them to HDD again.

 

"Therefore we know the actual shape of the HDD waveform is not at issue because there is that clear decision point of a 0 or 1 that is made, and if it's wrong we'll not get our data"

 

Actually, low level system noise is also saved along with the Data according to John Swenson who has worked in HDD fabrication, although he thought the level was probably not high enough to affect the data.

 

Perhaps you software guys should get together to try and fix this long standing bug that occasionally sees words of letters being out of sequence despite being typed correctly ?   I sure as hell didn't type DC a moment ago, I typed CD.

You can see the same weird type of thing in posts worldwide .

Perhaps it has been put into the "Too Hard" basket ?

[Richard Dale]

47 minutes ago, CuteStudio said:

 

 

BTW I note earlier you said that the Raspberry Pi had "Mediocre SQ" which I have been thinking about because it's sounding really very very (very) good indeed. I mean like the singer is right there in the room in front of me good. Sweet flowing treble, real cymbals and lovely bass good.

Perhaps it could be improved upon - most things can after all - but I'm struggling to imagine that right now, and TBH the next improvement would be moving to a digital crossover and Biamp system which wouldn't really involve any change to the Pi at all...

 

You can improve the power supply to a Raspberry Pi over a phone charger. I use either a 5 volt iFi iPower or  iFi iUSB3.0 Nanos for my various Pis. The iUSB3.0 can both power the Pi and clean up the USB output that goes into the DAC.

[sandyk]

10 minutes ago, Richard Dale said:

 

You can improve the power supply to a Raspberry Pi over a phone charger. I use either a 5 volt iFi iPower or  iFi iUSB3.0 Nanos for my various Pis. The iUSB3.0 can both power the Pi and clean up the USB output that goes into the DAC.

 

Richard

 How much sound quality improvement does it make ?

If it is substantial, perhaps somebody in the U.K. can lend Graham an  iFi PSU ?

 

Alex

[Richard Dale]

9 minutes ago, sandyk said:

 

Richard

 How much sound quality improvement does it make ?

If it is substantial, perhaps somebody in the U.K. can lend Graham an  iFi PSU ?

 

The iFi iUSB3.0 Nano certainly has made a large difference in the systems where I use them. For instance I use a Raspberry Pi with Moode Audio/iFi Silencer/Chord C-USB/iUSB3.0 Nano/Nordost Heimdal USB cable into a Chord 2Qute in my main system, and I really think it is an excellent combination. If I had a more expensive DAC, then something like a Sonore microRendu with linear PSU may well be better still, but it is a lot more money.

 

 Using just an iFi iPower makes some improvement, although not nearly as much, but is more portable.

[hurka]

Allo Sparky sbc(much better than pi)+ diy ultracaps psu 5v(200F)

 or Sotm sps 500 7v regulated to 5v (lt1963or lt3045) play sd card or cf card,sparky upsampling to 385khz,>iso regen>tx usb ultra>singxer F1 all powered sps500.

 

[nbpf]

8 hours ago, CuteStudio said:

Yes, I am aware of hardware like that, the decision is still the same, 0 or 1. If the data is misread from a disk then the hardware does a series of retries to get the data, and will rewrite dodgy stuff or mark the sector and copy the data to a fresh sector. If the data simply cannot be read correctly then you get a disk error which is signalled to the OS and you don't get your file: Read Error.

This certainly holds for disk read and write and for file transfers over TCP/IP, USB, etc. but I am not sure that it also holds for stream processing. In order to come up with a "misread" judgement on a stream segment, the reader of the stream (target OS) and the sender of that stream (source OS) would have to agree on the segments to be mdsum checked. This is of course possible, but does it actually take place in USB streaming? I am not saying that it doesn't, I simply do not know.

[Miska]

7 hours ago, nbpf said:

This certainly holds for disk read and write and for file transfers over TCP/IP, USB, etc. but I am not sure that it also holds for stream processing. In order to come up with a "misread" judgement on a stream segment, the reader of the stream (target OS) and the sender of that stream (source OS) would have to agree on the segments to be mdsum checked. This is of course possible, but does it actually take place in USB streaming? I am not saying that it doesn't, I simply do not know.

 

For network streaming over TCP connections, you get automatic error checking and correction.

 

Most DACs use USB Audio Class which uses isochronous transfer mode which doesn't use error correction. Some DACs use bulk mode transfer instead which has error correction, like the original M2Tech hiFace, Mytek Stereo192-DSD DAC, exaSound DACs and the new TEAC UD-505/NT-505.

 

Transfer errors certainly tend to produce clearly audible artifacts. And some DACs I have just go nuts in such case and start producing plain white noise.

 

[nbpf]

3 minutes ago, Miska said:

 

For network streaming over TCP connections, you get automatic error checking and correction.

 

Most DACs use USB Audio Class which uses isochronous transfer mode which doesn't use error correction. Some DACs use bulk mode transfer instead which has error correction, like the original M2Tech hiFace, Mytek Stereo192-DSD DAC, exaSound DACs and the new TEAC UD-505/NT-505.

 

But then, for devices that use the USB Audio Class protocol (I understand that most USB to SPDIF interfaces and USB DACs do so) it seems that, in contrast to the argument put forward by CuteStudio:

 

"Therefore we know the actual shape of the HDD waveform is not at issue because there is that clear decision point of a 0 or 1 that is made, and if it's wrong we'll not get our data. This is quite different from a CD read error that will just give us a fudge instead, with a computer disk the data integrity is critical because all the programs will error if it wasn't 100%, so it's maintained with an iron rule."

 

it is actually possibe that a poor shape of the waveform that carries the digital information from the server  to the interface or DAC induces non-recoverable errors.

 

From this perspective the quality of USB cables, USB interfaces, etc. can, at least in principle, have an impact on the sound quality beyond that mediated by electromagnetic radiation or extra CPU load induced by error correction. 

 

[Lebouwsky]

53 minutes ago, nbpf said:

"it is actually possibe that a poor shape of the waveform that carries the digital information from the server  to the interface or DAC induces non-recoverable errors."

 

 

Thank you for this clear explanation, this makes sence to me. Is it possible to quantify these errors? I can imagine a test where whaves are being send, loged and compared to the original. One can even quantify it in different circumstances where the waveform gets poorer and poorer.

[nbpf]

34 minutes ago, Lebouwsky said:

 

Thank you for this clear explanation, this makes sence to me. Is it possible to quantify these errors? I can imagine a test where whaves are being send, loged and compared to the original. One can even quantify it in different circumstances where the waveform gets poorer and poorer.

I do not know, I have very little understanding of the protocols involved in USB streaming. I was just trying to point out what seemed to me a possible logical mistake in CuteStudio's argument.

 

I guess that a rigorous error quantification would require sending a sample to the target using standard USB file transfer protocols (with error correction and mdsum check) and then compare it to the result of streaming the same sample using isochronous transfer mode or whatever protocol is under examination.

[Miska]

4 hours ago, nbpf said:

But then, for devices that use the USB Audio Class protocol (I understand that most USB to SPDIF interfaces and USB DACs do so) it seems that, in contrast to the argument put forward by CuteStudio:

 

"Therefore we know the actual shape of the HDD waveform is not at issue because there is that clear decision point of a 0 or 1 that is made, and if it's wrong we'll not get our data. This is quite different from a CD read error that will just give us a fudge instead, with a computer disk the data integrity is critical because all the programs will error if it wasn't 100%, so it's maintained with an iron rule."

 

it is actually possibe that a poor shape of the waveform that carries the digital information from the server  to the interface or DAC induces non-recoverable errors.

 

From this perspective the quality of USB cables, USB interfaces, etc. can, at least in principle, have an impact on the sound quality beyond that mediated by electromagnetic radiation or extra CPU load induced by error correction. 

 

 

Yes, USB-connected HDD's, CD-ROMs, DVD-ROMs and such use bulk mode transfer, so they have error detection and correction. This is not the case for USB Audio Class. But I would try to avoid USB HDD's and storage media for normal use and only use USB HDD's for occasional connection for backup purposes. For storage it is better to use either NAS, or if not possible Thunderbolt or eSATA drives.

 

From this perspective, however, it is not about "sound quality". If there's a transfer error, you hear a snap, pop or other clear artifact. Not something that can be described by usual audiophile vocabulary of sound qualities. Same for S/PDIF or AES/EBU too. Digital transfer errors tend to have clear artifacts. Just like with faulty or poor HDMI cable you get clear noise in the picture, like bright pixels appearing in random places (I've seen that couple of times).

 

There is no notable extra CPU load induced by error correction or something that would create audible differences in such cases, apart from stuttering on the playback. Biggest reason why hardware changes may have impact on DAC output happen outside of the digital world through analog processes that are caused by completely normal operation of the hardware. If you need to worry about effects of error checking and correction, you have much more to worry about normal operation. Not something that happens maybe once per week or something.

 

For digital cables, I'm usually against audiophile products, because there are so many uncertified and/or non-compliant cables out there that actually create problems rather than solving. Most digital cables and connectors have very specific compliance requirements, and modifications to the cable or connector structure tends to break the compliance. For USB cables, look for ones that have the official USB HiSpeed Certified logo (USB2) or USB SuperSpeed Certified logo (USB3). For network cables, in usual cases it is best to stick with UTP CAT6 cables. STP cables which many audiophile network cables are, create ground links through the shield and thus spoil the galvanic isolation it would otherwise provide (because ethernet is transformer isolated by default).

 

[nbpf]

11 hours ago, Miska said:

 

Yes, USB-connected HDD's, CD-ROMs, DVD-ROMs and such use bulk mode transfer, so they have error detection and correction. This is not the case for USB Audio Class. But I would try to avoid USB HDD's and storage media for normal use and only use USB HDD's for occasional connection for backup purposes. For storage it is better to use either NAS, or if not possible Thunderbolt or eSATA drives.

 

From this perspective, however, it is not about "sound quality". If there's a transfer error, you hear a snap, pop or other clear artifact. Not something that can be described by usual audiophile vocabulary of sound qualities. Same for S/PDIF or AES/EBU too. Digital transfer errors tend to have clear artifacts. Just like with faulty or poor HDMI cable you get clear noise in the picture, like bright pixels appearing in random places (I've seen that couple of times).

 

There is no notable extra CPU load induced by error correction or something that would create audible differences in such cases, apart from stuttering on the playback. Biggest reason why hardware changes may have impact on DAC output happen outside of the digital world through analog processes that are caused by completely normal operation of the hardware. If you need to worry about effects of error checking and correction, you have much more to worry about normal operation. Not something that happens maybe once per week or something.

 

For digital cables, I'm usually against audiophile products, because there are so many uncertified and/or non-compliant cables out there that actually create problems rather than solving. Most digital cables and connectors have very specific compliance requirements, and modifications to the cable or connector structure tends to break the compliance. For USB cables, look for ones that have the official USB HiSpeed Certified logo (USB2) or USB SuperSpeed Certified logo (USB3). For network cables, in usual cases it is best to stick with UTP CAT6 cables. STP cables which many audiophile network cables are, create ground links through the shield and thus spoil the galvanic isolation it would otherwise provide (because ethernet is transformer isolated by default).

 

Thanks for the detailed explanations, I very much appreciate!

 

In my system server (MinimServer) and renderer (upmpdcli) run on the same device. This is a fitPC3 running a minimal Debian distribution or a Raspberry Pi 3 running a minimal Raspbian. There is no data transfer over LAN at replay time (apart for  control, via BubbleUPnP or Linn Kazoo) and the connection to the DAC is via SPDIF through a USB to SPDIF interface. Thus, I am particularly interested in understanding how USB Audio Class (two, in my specific case, I believe) works and in improving the quality of the SPDIF feed to the DAC. I commonly use Supra cables for the USB connection between server and USB interfaces. I have been testing the Schiit Eitr and the Mutec MC-3+ USB against my M2Tech hiFace Evo. The latter is powered by a 9V/2A Teddy Pardo LPSU.  

 

In your second remark

 

"From this perspective, however, it is not about "sound quality". If there's a transfer error, you hear a snap, pop or other clear artifact. Not something that can be described by usual audiophile vocabulary of sound qualities. Same for S/PDIF or AES/EBU too. Digital transfer errors tend to have clear artifacts. Just like with faulty or poor HDMI cable you get clear noise in the picture, like bright pixels appearing in random places (I've seen that couple of times)."

 

you argue that transfer errors would result in audible artifacts (snap, pop, etc.) rather than impaired sound quality. Why is it so? I understand that a PCM stream consists of 16bit words at the rate of 44100 words per second. If a compromised square wave form leads to errors on single bits, say, for instance, 1 error every 32 bits, this would not necessarily result in pops, snaps, etc. Errors in the lower bits of a word would have a minor impact on the amplitude carried by that word. Errors in the higher bits would have a larger impact, of course but I would expect the process of generating an analog amplitude to anyway involve a lot of interpolation between a large number of words and perhaps some smoothing. How could such errors generate pops? I would have rather expected that severe artifacts like pops and snaps the are consequence of synchronization failures, incompatible formats or very severe transmission errors.

 

[sandyk]

37 minutes ago, nbpf said:

you argue that transfer errors would result in audible artifacts (snap, pop, etc.) rather than impaired sound quality.

 

 Sometimes these minor errors may not even be noticed.

With a saved recording, a snap/pop etc. at the same point of the recording each time can also be caused by a Glitch due to some other running program which results in a small discontinuity in the waveform as seen in an audio editing program.

You can sometimes correct this with the audio editing program by using "Pencil "to bridge the small missing part, or paste another section of the waveform across it, perhaps from the other channel at that point in time.

[Miska]

7 hours ago, nbpf said:

you argue that transfer errors would result in audible artifacts (snap, pop, etc.) rather than impaired sound quality. Why is it so? I understand that a PCM stream consists of 16bit words at the rate of 44100 words per second. If a compromised square wave form leads to errors on single bits, say, for instance, 1 error every 32 bits, this would not necessarily result in pops, snaps, etc. Errors in the lower bits of a word would have a minor impact on the amplitude carried by that word. Errors in the higher bits would have a larger impact, of course but I would expect the process of generating an analog amplitude to anyway involve a lot of interpolation between a large number of words and perhaps some smoothing. How could such errors generate pops? I would have rather expected that severe artifacts like pops and snaps the are consequence of synchronization failures, incompatible formats or very severe transmission errors.

 

Because the error happens somewhere randomly, likely to cause relatively large error in the signal. Or it could land in control data areas. As I said earlier, some DACs obviously have not been tested for these and they got nuts and start output for example white noise and only stop/restart cycle recovers.

 

In any case, if you use certified and standard compliant cable and don't have serious ground current or hardware design issues, the error rate is likely more towards one bit per week of 24h playback or so. If you have so much errors that it causes "impaired sound quality", then you have some serious hardware issues.

 

If you are worried about this, look for example for the original M2Tech hiFace if you want S/PDIF output. Or some DAC that uses bulk-mode transfers. Or alternatively go for ethernet playback instead of USB.

 

[nbpf]

10 minutes ago, Miska said:

 

Because the error happens somewhere randomly, likely to cause relatively large error in the signal. Or it could land in control data areas. As I said earlier, some DACs obviously have not been tested for these and they got nuts and start output for example white noise and only stop/restart cycle recovers.

 

In any case, if you use certified and standard compliant cable and don't have serious ground current or hardware design issues, the error rate is likely more towards one bit per week of 24h playback or so. If you have so much errors that it causes "impaired sound quality", then you have some serious hardware issues.

 

If you are worried about this, look for example for the original M2Tech hiFace if you want S/PDIF output. Or some DAC that uses bulk-mode transfers. Or alternatively go for ethernet playback instead of USB.

 

Thanks, I am not worried, just curious. Then, if compliant cables and decent hardware design ensure so low error rates, the argument put forward by CuteStudio does hold in practice and we can assume that, under normal conditions, the USB Audio Class protocol grants nearly error-free data transmission. Under these assumptions, audible differences between different USB sources can only be explained in terms of radiated electromagnetic energy and/or spurious electric currents in the USB connection affecting the DAC (or USB to SPDIF interface) downstream, right? Or am I missing something?