Is Digital Audio Transmission Analog? [video]

[danadam]

Will the DAC cache/buffer to make sure such errors can be recovered easily (seems advisable)?

Not sure what you mean here. USB Audio is using isochronous transfers and those don't offer retransmissions, so I don't see how it can recover. The most it can do is to try to interpolate something based on previous, correct frames, but given how rare USB transmission errors are, I doubt that anyone does that.

 

[pablolie]

Not sure what you mean here. USB Audio is using isochronous transfers and those don't offer retransmissions, so I don't see how it can recover. The most it can do is to try to interpolate something based on previous, correct frames, but given how rare USB transmission errors are, I doubt that anyone does that.

Of course it can, it's up to the higher layer. USB couldn't care less whether it is asked to retransmit or not. Of course you can ask for a retransmission over USB as the device/app using the transport layer. USB in no way does prevent it. It would completely violate protocol layer basic principles if it did.

".. To request a USB retransmission, a host computer typically doesn't need to explicitly send a dedicated "retransmission" command; instead, the USB protocol automatically handles retransmissions when a data packet isn't acknowledged by the device, causing the host to resend the data packet until a successful acknowledgement is received... "

Or the receiver has the freedom to not care, by the way. That's the thing with protocol layers. You are free which functionality to use or not at the higher layer. Maybe you think you have a better approach. ISO layers basics.

And it happens all the time. Google thinks they can better TCP with Quik etc etc.

 

[danadam]

The USB 2.0 Spec says:

5.6.5 Isochronous Transfer Data Sequences
Isochronous transfers do not support data retransmission in response to errors on the bus. A receiver can
determine that a transmission error occurred. The low-level USB protocol does not allow handshakes to be
returned to the transmitter of an isochronous pipe. Normally, handshakes would be returned to tell the
transmitter whether a packet was successfully received or not. For isochronous transfers, timeliness is more
important than correctness/retransmission, and, given the low error rates expected on the bus, the protocol is
optimized by assuming transfers normally succeed.

5.12.7 Error Handling
Isochronous transfers provide no data packet retries (i.e., no handshakes are returned to a transmitter by a
receiver) so that timeliness of data delivery is not perturbed.

8.7 Error Detection and Recovery
... Isochronous transactions,
by virtue of their bandwidth and latency requirements, do not permit retries and must tolerate a higher
incidence of uncorrected errors.

 

[pablolie]

The USB 2.0 Spec says:

you have freedom of implementation on top of it. always.

".. not all DACs are created equal, with higher-end models often employing "asynchronous" functionality where the DAC controls the timing of the data stream for improved audio quality .. "

note I take the" improved audio quality" with a grain of sand.

hope u don't think I am attacking you, everything you said is correct from a USB standard point of view. but there are layers on top of it and choices than can be made to optimally suit your implementation, always.

 

[kemmler3D]

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

As @danadam posted (cool!) dropped USB frames would sound like a series of pops/clicks.

If you randomly flip bits and don't drop the frame, it should sound like random noise.

Each sample is a 16-bit number.

If you flip zeroes to ones in a binary number, you're changing the value of the number at random. A string of random numbers played back as audio is just white noise, so if the errors are relatively uniform, that's effectively what should happen... but depending on the timing and how the bits are flipped you probably wouldn't end up with nice steady noise, rather probably more like random drops, clicks, pops, etc.

 

[danadam]

".. To request a USB retransmission, a host computer typically doesn't need to explicitly send a dedicated "retransmission" command; instead, the USB protocol automatically handles retransmissions when a data packet isn't acknowledged by the device, causing the host to resend the data packet until a successful acknowledgement is received... "

".. not all DACs are created equal, with higher-end models often employing "asynchronous" functionality where the DAC controls the timing of the data stream for improved audio quality .. "

Where are those from?

"asynchronous" is one of the modes of isochronous transfer.

There are four kinds of USB transfer:

• bulk: with error detection and error correction
• isochronous: real-time, with error detection but without error correction
• interrupt: to poll a device to check if something happened (e.g. device was muted)
• control: like bulk, used for querying device capabilities and status

There are three modes of isochronous transfer:

• synchronous
• asynchronous
• adaptive

you have freedom of implementation on top of it. always.

Maybe, with custom drivers, though I'm rather sceptical. Did anyone actually do it?

hope u don't think I am attacking you,

No, it's fine

 

[pablolie]

As @danadam posted (cool!) dropped USB frames would sound like a series of pops/clicks.

If you randomly flip bits and don't drop the frame, it should sound like random noise.

Each sample is a 16-bit number.

If you flip zeroes to ones in a binary number, you're changing the value of the number at random. A string of random numbers played back as audio is just white noise, so if the errors are relatively uniform, that's effectively what should happen... but depending on the timing and how the bits are flipped you probably wouldn't end up with nice steady noise, rather probably more like random drops, clicks, pops, etc.

all true.

I have never worked with USB intricacies, but since it fits (like any protocol) into ISO layer principles, I know you can always add a trick or two at the appropriate layer.

where I work (internet core networking) I have never encountered a mysterious bit error that the upper protocols couldn't handle. those bit errors caused by neutrons and solar flares that corrupt stuff. but sources I entirely trust have.

so not claiming impossibilities. Just saying the frequency of those occurances is utterly overestimated in audio, as well as its effects.

I have not once heard of a bank transaction or missile launch failure or health data that was faulty because of basic corruptions in layer 1 to 4 that went undetected. I don't see how the USB protocol stack condemns us irrevocably to errors even the layers above at the application layer cannot check and correct as needed.

and anyone that designs a USB DAC without appropriate buffering... well. I know I can configure buffering in my DAC for that "if drops occur" stuff in the manual. buffers are only there for 2 reasons... avoid possible starvation due to jitter, and allow for retransmissions.

 

[pablolie]

Where are those from?

"asynchronous" is one of the modes of isochronous transfer.

There are four kinds of USB transfer:

• bulk: with error detection and error correction
• isochronous: real-time, with error detection but without error correction
• interrupt: to poll a device to check if something happened (e.g. device was muted)
• control: like bulk, used for querying device capabilities and status

There are three modes of isochronous transfer:

• synchronous
• asynchronous
• adaptive

Maybe, with custom drivers, though I'm rather sceptical. Did anyone actually do it?


No, it's fine

You are a bit stuck on USB protocol basics. There is other stuff. Look at applications like Jriver Media Center and the additional direct control they allow for in configuration. Buffers too. There's more than the basic USB basics to it. There is a protocol stack ecosystem above USB. WASAPI apis. ASIO drivers. etc. Who'd bother implement that if the USB basic restrictions rule the audio universe?

 

[danadam]

Related thread on rme forum: How does ADI-2 DAC handle USB transmission errors?

 

[pablolie]

Related thread on rme forum: How does ADI-2 DAC handle USB transmission errors?

And you keep thinking USB basics. Again - lots of implementation freedom on top. ISO layers basics. I check out.

 

[bennetng]

Maybe, with custom drivers, though I'm rather sceptical. Did anyone actually do it?

Like this?

Bulk Pet（English） | インターフェイス株式会社

In Japanese (the original language, I suppose):

独自USB伝送技術 Bulk Pet(バルク ペット) | インターフェイス株式会社

Example products:

Update: Bulk Pet support for Mac with Apple M1 chip | News Details | TEAC | International Website

Update: Bulk Pet support for Mac with Apple M1 chip

teac.jp

 

[danadam]

Like this?

Yes, that's something I was thinking about. Interesting find, thanks.

I wonder if they did it just "because we can" or does it solve some actual problems for them

 

[wwenze]

Bulk Transfer Mode in Musiland Monitor Devices

After some reports at head-fi indicating that the Musiland device driver uses bulk mode transfer, I decided to do some USB port snooping of my own by downloading one of the many USB protocol analyz…

hifiduino.wordpress.com

I actually have this thing, never felt more reliable than normal, still gives pops when I'm doing capturing in OBS so I gave up and went back to good ol' PCH.

 

[phofman]

And you keep thinking USB basics. Again - lots of implementation freedom on top. ISO layers basics. I check out.

Yes, but then such a device is not USB-audio compliant and requires a custom driver on the host. From the POV of resending - isochronous mode is similar to UDP while bulk mode to TCP. The usage is similar too.

Actually I have had a few broken USB extension cords (well within the 5m limit) which drop frames at USB2 (probably imperfect contact issues). Very annoying when troubleshooting a USB device software stack and the drop-outs in the received audio stream are not caused by the receiver SW issues, but by the cable.

 

[mmuetst]

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

Thanks, this is what I'm looking for. I was already working with a HEX editor to create such a file. Managed to cause one hiccup

 

[danadam]

Once again: USB is used for audio in asynchronous mode in *many* DACs

No one said otherwise. I have 6 such DACs on my desk right now (FiiO K3, FiiO JA11, Dragonfly Red, Tanchjim Space, JCally JM20, ADI-2 Pro).

What was said is, that this is an asynchronous mode of isochronous transfer. This only means that there is a separate clock used in DA process, which is not dependent on USB transmission clock. It doesn't mean that any packets are retransmitted on errors.

No proprietary drivers needed either.

Sure, but I doubt it does any retransmissions.

 

[pablolie]

No one said otherwise. I have 6 such DACs on my desk right now (FiiO K3, FiiO JA11, Dragonfly Red, Tanchjim Space, JCally JM20, ADI-2 Pro).

What was said is, that this is an asynchronous mode of isochronous transfer. This only means that there is a separate clock used in DA process, which is not dependent on USB transmission clock. It doesn't mean that any packets are retransmitted on errors.


Sure, but I doubt it does any retransmissions.

Apologies, it was my mistake we were talking past each other at times. :-( You are right.

 

[pablolie]

... isochronous mode is similar to UDP while bulk mode to TCP. The usage is similar too.
...

Note many transport protocols can and do implement retransmission and more of top of UDP. Check out Quic, Google's "better" TCP. My point is you can implement whatever you want on top of basic frame/packet/etc basic transport protocols.

 

[phofman]

My point is you can implement whatever you want on top of basic frame/packet/etc basic transport protocols.

Absolutely, but then it will not be a USB audio class 1/2 device and it will require custom drivers.