Is Digital Audio Transmission Analog? [video]

[voodooless]

We always ask audiophiles to test their ears. Maybe we should put ASR members to test too. https://www.klippel.de/listeningtest/ Is there a point to worry about -80db distortion if I can't hear -80db in distortion listening tests? If you can hear -80db distortion, I would like to know.

It's not just distortion that is poor with these products, it's also the SNR. No, I'm not too bothered about distortion being audible. I'm bothered by the lack of engineering excellence.

For example, I was able to hear the polling rate of my mouse or hear a high pitched noise when my gpu is working hard while MiniDSP 2x4 was connected to my PC. This is not the case with Motu M2 I am using right now.

That's just pure luck sometimes. These people were not so lucky with their M2 configuration... So, yes, galvanic isolation may help prevent ground loops, but a cheap USB isolator can fix that if needed, even on a €$ 99 DAC, that is as audibly transparent as any other.

 

[audio_tony]

The goal of the galvanic isolation is basically to cut off the noise coming from the source, PC for example.

The goal of galvanic isolation is to prevent ground loops, and not quite as your explanation above.

Most good quality CD players from the 1980's had a small transformer on the coaxial output for this very purpose, although as most CD players were double insulated (and as such had no ground connection) ground loops were typically not an issue, although the CD player could still have a path to ground via the RCA interconnects for example (if the amp was earthed).

Some DACs also had an input transformer although those were not very common.

 

[mmuetst]

I know this is an old topic, but I'am looking for a sample where bits get bad. @amirm made such examples using a very long bad USB cable. Are there examples on Youtube for example where bits are damaged in audio and how that sounds.

 

[Cbdb2]

It's not just distortion that is poor with these products, it's also the SNR. No, I'm not too bothered about distortion being audible. I'm bothered by the lack of engineering excellence.

That's just pure luck sometimes. These people were not so lucky with their M2 configuration... So, yes, galvanic isolation may help prevent ground loops, but a cheap USB isolator can fix that if needed, even on a €$ 99 DAC, that is as audibly transparent as any other.

Tried searching that site for others with that problem. I could only find those 2. And the first one fixed it by replacing his GPU (are yiu sure an isolater would have worked?) With such a popular unit (must have sold thousands) Ild say this is a rare problem.

 

[rationaltime]

I know this is an old topic, but I'am looking for a sample where bits get bad. @amirm made such examples using a very long bad USB cable. Are there examples on Youtube for example where bits are damaged in audio and how that sounds.

Though I know some things about how USB works, I am not an expert
on the USB interface.

Many different USB uses and standards have evolved over the years.
Here is the standard case.

The USB channel is not an audio interface in the following sense.
USB uses packet based data transfer. Data to be sent is encoded
with added extra data to form a data packet with header information.
Each packet also includes a kind of error detection. If errors are
detected, the receiving device should drop that packet and send a
message to the sender to retransmit that packet by header ID. If
the buffer in the receiver is not large enough to absorb the packet
loss then in the case of audio data there would be gaps in the audio
stream. I expect that is how you would perceive "damaged bits"
in the audio. If packet loss were excessive, the receiver should
signal the transmitter, "Stop. Let's renegotiate the data rate".

Operating on the principle that noisy communication is better
than no communication, audio data receivers could just accept
bit errors and include the errors in the audio data. However,
USB is designed for data communications. I expect the interface
designers would not be ready to accept corrupt data.

In my experience long USB cables did not work even for what
should be a low speed interface. I used two inexpensive USB to
cat 5 translators to make the interface work. No more problem.
My suggestion is for data transfer over longer distances use
USB to cat 5 translators. That should provide good signal to
noise on the cable.

 

[voodooless]

The USB channel is not an audio interface in the following sense.
USB uses packet based data transfer. Data to be sent is encoded
with added extra data to form a data packet with header information.
Each packet also includes a kind of error detection. If errors are
detected, the receiving device should drop that packet and send a
message to the sender to retransmit that packet by header ID. If
the buffer in the receiver is not large enough to absorb the packet
loss then in the case of audio data there would be gaps in the audio
stream. I expect that is how you would perceive "damaged bits"
in the audio. If packet loss were excessive, the receiver should
signal the transmitter, "Stop. Let's renegotiate the data rate".

The USB Audio spec does not retransmit on errors. There is simply not enough time for that because you want to keep delays to a minimum.

 

[mmuetst]

Though I know some things about how USB works, I am not an expert
on the USB interface.

Many different USB uses and standards have evolved over the years.
Here is the standard case.

The USB channel is not an audio interface in the following sense.
USB uses packet based data transfer. Data to be sent is encoded
with added extra data to form a data packet with header information.
Each packet also includes a kind of error detection. If errors are
detected, the receiving device should drop that packet and send a
message to the sender to retransmit that packet by header ID. If
the buffer in the receiver is not large enough to absorb the packet
loss then in the case of audio data there would be gaps in the audio
stream. I expect that is how you would perceive "damaged bits"
in the audio. If packet loss were excessive, the receiver should
signal the transmitter, "Stop. Let's renegotiate the data rate".

Operating on the principle that noisy communication is better
than no communication, audio data receivers could just accept
bit errors and include the errors in the audio data. However,
USB is designed for data communications. I expect the interface
designers would not be ready to accept corrupt data.

In my experience long USB cables did not work even for what
should be a low speed interface. I used two inexpensive USB to
cat 5 translators to make the interface work. No more problem.
My suggestion is for data transfer over longer distances use
USB to cat 5 translators. That should provide good signal to
noise on the cable.

Thank you for your response, but I am just looking for an example audio file in which it is audible that data is missing or that a 0 has become a 1 or vice versa.

 

[pablolie]

USB these days supports up to 40Gbps (it's more of a theoretical limit, but hey, ridiculously waaaay more than audio needs), so any audio stream is a microscopic load. Several layers of protocols deal with error checking. Stay withing cable length recommendations (10ft) or use some repeater.

USB checks signal integrity, too.

The receiver *may* request retransmissions.

Audiophiles worry waaaaay too much about highly improbable bit errors and jitter and voodoo stuff with USB. Again, several layers are there to ensure success. And audio data will never ever be even remotely a performance challenge to USB these days.

 

[testp]

Thank you for your response, but I am just looking for an example audio file in which it is audible that data is missing or that a 0 has become a 1 or vice versa.

im not an expert on this but if audio is sent as information packages, then if some of them are not reconstructable in the other side (after error correction), then that would not make noise as such, rather unable to proceed error? or if continued with the construction then maybe clitches not noise.

at best maybe it is possible to saturate the transmiting cable (use voltage cable crossed with usb cable) and see if this adds noise and gets through into dacs because of dac subpar filtering or such <- this is just a guess scenario, not even sure this is possible

 

[mmuetst]

im not an expert on this but if audio is sent as information packages, then if some of them are not reconstructable in the other side (after error correction), then that would not make noise as such, rather unable to proceed error? or if continued with the construction then maybe clitches not noise.

at best maybe it is possible to saturate the transmiting cable (use voltage cable crossed with usb cable) and see if this adds noise and gets through into dacs because of dac subpar filtering or such <- this is just a guess scenario, not even sure this is possible

I am not looking for an explanation of USB and its operation, I am looking for an example file that shows what happens when data is no longer correct. It must be something in which pops and clicks must be heard

 

[pablolie]

I am not looking for an explanation of USB and its operation, I am looking for an example file that shows what happens when data is no longer correct. It must be something in which pops and clicks must be heard

I don't think you'll find a case for USB being the source for audible audio degradation. As someone else said, you could experiment with exposing the USB cable or device to strong magnetic fields or so and see what happens, but it seems pretty pointless to me.

Any issues are far more likely to be associated with software/protocol errors due to drivers and such, and not the USB physical stuff.

 

[testp]

I am not looking for an explanation of USB and its operation, I am looking for an example file that shows what happens when data is no longer correct. It must be something in which pops and clicks must be heard

but understanding usb transfer you understand what you are looking for, only damaged packages happen in transfer, so if you are looking for pops and clicks, this where it will begin, end result (with pops/clicks) is not recorded audio file but your own dac output. basically you cant use someone else's dac output recording in your own usb transfer

 

[mmuetst]

but understanding usb transfer you understand what you are looking for, only damaged packages happen in transfer, so if you are looking for pops and clicks, this where it will begin, end result (with pops/clicks) is not recorded audio file but your own dac output. basically you cant use someone else's dac output recording in your own usb transfer

So I'm looking for a sample where it deliberately goes wrong. This is to show as an example what happens when the data is not correct.
@amirm once made such a recording deliberately (see the video in this topic) using the bad very long USB cable. But I'm just looking for an example sound fragment in which the same thing is audible. Maybe someone has put something like that on Youtube or you can download a sound fragment.
I know that this normally does not happen.

 

[mmuetst]

I don't think you'll find a case for USB being the source for audible audio degradation. As someone else said, you could experiment with exposing the USB cable or device to strong magnetic fields or so and see what happens, but it seems pretty pointless to me.

Any issues are far more likely to be associated with software/protocol errors due to drivers and such, and not the USB physical stuff.

Same answer, skip the USB part, I just want a sample where the sound is deliberately degraded. I want to use this example to let other people hear what can be heard when the data is no longer correct. Just as an example

 

[pablolie]

Same answer, skip the USB part, I just want a sample where the sound is deliberately degraded. I want to use this example to let other people hear what can be heard when the data is no longer correct. Just as an example

You can open any file in your music library with any editor and type in some gibberish randomly and see what happens. You can also introduce single or multiple bit errors by being more careful with the edits in hex. In either case, you're not really emulating anything that's ever likely to happen.

 

[mmuetst]

You can open any file in your music library with any editor and type in some gibberish randomly and see what happens. You can also introduce single or multiple bit errors by being more careful with the edits in hex. In either case, you're not really emulating anything that's ever likely to happen.

I just tried it with notepad++ but it's easier said than done. The music just starts later because Foobar2000 finds the first part corrupt.
What is a good hex editer?

 

[pablolie]

I just tried it with notepad++ but it's easier said than done. The music just starts later because Foobar2000 finds the first part corrupt.
What is a good hex editer?

Well, that tells you something about data corruption.

It's more complicated *because* of all the error checking and correcting done end to end. Ideally you interpret headers and frames and -again- hope the application stack doesn't go "what the h*ll is this?".

WinHex is pretty good (there are zillions). Gaining familiarity with file formats (and how they are processed up and down the stack) will probably be the most useful part of this experiment. It will showcase how hard it is for errors to make it through undetected.

Far more critical applications than music are successfully serviced with the same protocol stack, I always find it entertaining when audio "experts" think there's anything in music files that tests the stack with music files.

 

[MatrixS2000]

I am not looking for an explanation of USB and its operation, I am looking for an example file that shows what happens when data is no longer correct. It must be something in which pops and clicks must be heard

This will be heard as click or a pop. If you want to experience it, I could create you a music file with one sample modified randomly. I illustrated what happens when bits are randomly changed here.

 

[danadam]

I am not looking for an explanation of USB and its operation, I am looking for an example file that shows what happens when data is no longer correct. It must be something in which pops and clicks must be heard

In USB 2.0 audio data is sent in frames 8000 per second. This means that for 44.1 kHz audio a single frame will contain 5 or 6 stereo samples. Each frame also contains a checksum, which is used to verify data integrity. If something happens and error is detected, the whole frame should be discarded (I think).

Now, I don't know what a DAC will do in such case. I'm guessing it will "fill the void" with samples of value 0. If that's the case then here's a simulation how it would sound if 0.1% USB frames were getting malformed:

2.04 MB file on MEGA

mega.nz

 

[pablolie]

...
Now, I don't know what a DAC will do in such case. I'm guessing it will "fill the void" with samples of value 0....

USB doesn't in any way specify what devices should do at their higher layers. It provides a pretty good basic transfer function, and that's it. It's up to the DAC designer to implement that behavior. Will the DAC cache/buffer to make sure such errors can be recovered easily (seems advisable)? Will it croak as soon as its real time buffer is starved (which it would with audio applications)? There are several layers of stuff that allow for generous freedom of implementation.

It's pretty much the exact same with Ethernet or IP.