Digital Transport Quality (and why it *may* matter).

[gregorio]

Because you continue to conflate data transmission (defined by serial, parallel, synchronous, and asynchronous data) with the actual data stream itself.

So that’s a “yes” then? If you fail to transmit the digital data that is still digital data transmission. Thx, got it.

No, I'm not failing, it is you who are conflating the connection cable with the protocols of the system

The data protocol defines the connection cable, the signal it transfers and the error correction/detection codes. Good luck trying to hammer a USB cable into an Ethernet port. Maybe an audiophile USB cable would work?

USB has modes that don't use ECC.

The inclusion of error correction and/or detection code is a requirement of the USB spec and always has been as far as I’m aware. Version 2.0 for example upgraded to 5bit CRC for all start of frame packets and USB 3.1 to 32bit CRC. Even the consumer S/PDif protocol incorporates CRC (and parity bits).

G

 

[Davesrose]

So that’s a “yes” then? If you fail to transmit the digital data that is still digital data transmission. Thx, got it.

You are really incorrigible. You still continue to refuse to acknowledge accepted concepts of how binary data is transmitted from one component to another: again, it's either serial or parallel.

The data protocol defines the connection cable, the signal it transfers and the error correction/detection codes. Good luck trying to hammer a USB cable into an Ethernet port. Maybe an audiophile USB cable would work?

The data protocol changes the data signal: it does not change the fact that data gets sent in a single stream or multiple streams.

The inclusion of error correction and/or detection code is a requirement of the USB spec and always has been as far as I’m aware. Version 2.0 for example upgraded to 5bit CRC for all start of frame packets and USB 3.1 to 32bit CRC. Even the consumer S/PDif protocol incorporates CRC (and parity bits).

G

No it isn't...again, it depends on the mode. And if we want to just focus on audio protocols, isochronous USB transfer mode is used, which believe it or not, does not use ECC!

 

[gregorio]

You are really incorrigible. You still continue to refuse to acknowledge …

Yes you are, you still refuse to acknowledge that if you fail to receive the correct information then you have not transmitted/transferred the data.

The data protocol changes the data signal:

Hallelujah brother! Yes, it defines the signal level, eye pattern specs and of course cables and connectors, etc.

No it isn't...again, it depends on the mode. And if we want to just focus on audio protocols, isochronous USB transfer mode is used, which believe it or not, does not use ECC!

“The USB protocol, or Universal Serial Bus, uses Cyclical Redundancy Checks during transmission to protect all non-PID fields in token and data packets from errors. In USB 2.0, the token and start-of-frame (SOF) packets include a 5-bit CRC (CRC5), while the data packet includes a longer 16-bit CRC (CRC16) to provide adequate support for data payloads reaching up to 1024 bytes.” - Emphasis mine.

You are maybe getting confused with the Isynchronous USB mode (which is sometimes used for audio) which does not contain any error correction code but does contain the error detection CRC code (as does all USB data/modes, except Packet ID fields).

G

 

[Davesrose]

Yes you are, you still refuse to acknowledge that if you fail to receive the correct information then you have not transmitted/transferred the data.

No, you are showing more of those tendencies when you refuse to use accepted terminologies and have blatently false assertions (example, claiming USB always has ECC). Again, here is the definition of a data transmission:

https://www.cdnetworks.com/enterpri...Data Transmission?,part of a wireless network.

"As we know, data transmission methods can refer to both analog and digital data but in this guide, we will be focusing on digital modulation. This modulation technique focuses on the encoding and decoding of digital signals via two main methods parallel and serial transmission."

Hallelujah brother! Yes, it defines the signal level, eye pattern specs and of course cables and connectors, etc.

What do you mean hallelujah? You've been wanting to argue with me that they're all one thing since my post #88 (when ECC can be part of the signal, not whether that signal is serial or parallel)

“The USB protocol, or Universal Serial Bus, uses Cyclical Redundancy Checks during transmission to protect all non-PID fields in token and data packets from errors. In USB 2.0, the token and start-of-frame (SOF) packets include a 5-bit CRC (CRC5), while the data packet includes a longer 16-bit CRC (CRC16) to provide adequate support for data payloads reaching up to 1024 bytes.” - Emphasis mine.

You are maybe getting confused with the Isynchronous USB mode (which is sometimes used for audio) which does not contain any error correction code but does contain the error detection CRC code (as does all USB data/modes, except Packet ID fields).

G

No, I'm not the one getting confused. It's you who were confused with your assertion that USB always uses CRC. It's primarily used in file transfers, not video and audio using isochronous transfers.

https://www.keil.com/pack/doc/mw/USB/html/_u_s_b__isochronous__transfers.html#:~:text=Isochronous Transfers are used for,delivered at the desired rate.

https://learn.microsoft.com/en-us/w...usbcon/transfer-data-to-isochronous-endpoints

 

[gregorio]

No, I'm not the one getting confused. It's you who were confused with your assertion that USB always uses CRC. It's primarily used in file transfers, not video and audio using isochronous transfers.

Ah, so it is you who are confused. Firstly, are you really claiming the quote is wrong? All non-PID packets have CRC regardless of the transaction mode! Isochronous transactions do not allow error correction in the form or requesting resends but do always include CRC! No point in continuing if you’re going to argue against the published facts.

On the extremely remote possibility that anyone else is even vaguely interested, here is the actual full USB2.0 specification published by usb.org. On pages 45 and 46 please note the protocol overheads for both full and high speed isochronous transactions and the inclusion of dual Cyclic Redundancy Checks (CRC).

G

 

[Davesrose]

Ah, so it is you who are confused. Firstly, are you really claiming the quote is wrong? All non-PID packets have CRC regardless of the transaction mode! Isochronous transactions do not allow error correction in the form or requesting resends but do always include CRC! No point in continuing if you’re going to argue against the published facts.

On the extremely remote possibility that anyone else is even vaguely interested, here is the actual full USB2.0 specification published by usb.org. On pages 45 and 46 please note the protocol overheads for both full and high speed isochronous transactions and the inclusion of dual Cyclic Redundancy Checks (CRC).

G

No you have been confused insisting all data transmission uses ECC. I've kept bringing up ECC RAM vs non ECC. A simple example of ECC not being used is a serial keyboard connection. You're being disingenuous in not acknowledging CRC is not being used with isochronous transfers (where there it might be in the host controller, but there is no error detection in the transfer). My Microsoft link has quite a bit of information about how isochronous transfer mode is used in Windows API, and there's also another section on data recovery.

 

[gregorio]

No you have been confused insisting all data transmission uses ECC.

No I haven’t and I’ve even explained it to you but don’t let that get in the way of enjoying a good argument. Aren’t you going to argue against Shannon or the USB specs anymore? Surely usb.org’s own specs must be wrong, why don’t you link to some more articles to prove it?

G

 

[Davesrose]

No I haven’t and I’ve even explained it to you but don’t let that get in the way of enjoying a good argument. Aren’t you going to argue against Shannon or the USB specs anymore? Surely usb.org’s own specs must be wrong, why don’t you link to some more articles to prove it?

G

Post #96, you maintained ECC is always integral with it. I can continue to repost definitions of data transmission being serial or parallel data streams...but it's like talking to a wall. And I can keep posting about how isochronous transfer mode doesn't use error detection (and that Microsoft's documentation as it relates with modern API apparently is meaningless). Have a good evening.

 

[gregorio]

And I can keep posting about how isochronous transfer mode doesn't use error detection …

Yes you can but then of course you’ll just keep being wrong.

“Isochronous transfers do not support data retransmission in response to errors on the bus. A receiver can determine that a transmission error occurred.” - page 47 USB2.0 Specifications, link provided previously. But hey, don’t let the facts stop you!

G

 

[Davesrose]

Yes you can but then of course you’ll just keep being wrong.

“Isochronous transfers do not support data retransmission in response to errors on the bus. A receiver can determine that a transmission error occurred.” - page 47 USB2.0 Specifications, link provided previously. But hey, don’t let the facts stop you!

G

Keep on cherry picking. My sources and this quote are not in conflict with one another. Notice the word "can" and not "will". My links are still correct that there is not error detection in the transmission. As I said, my Microsoft documentation goes over data recovery. I won't be surprised that you're still also going to go back to maintain that a data stream is always integral to ECC (no matter what situation).

 

[gregorio]

My links are still correct that there is not error detection in the transmission.

Yes of course, a receiver can detect errors but not with error detection. Carry on!

G

 

[Davesrose]

Yes of course, a receiver can detect errors but not with error detection. Carry on!

G

There you go cherry picking the transmission stage instead of what can happen in the receiver Have a good one!

 

[gregorio]

There you go cherry picking the transmission stage instead of what can happen in the receiver

Yep, we’re not talking about transmitting information at all, hence why I didn’t mention Shannon, the USB protocol, S/PDif protocol or audiophile ethernet switches/cables, etc. Glad we got that sorted but carry on arguing anyway!

G

 

[Davesrose]

Yep, we’re not talking about transmitting information at all, hence why I didn’t mention Shannon, the USB protocol, S/PDif protocol or audiophile ethernet switches/cables, etc. Glad we got that sorted but carry on arguing anyway!

G

Oh that's right....no matter what protocol, term, or concept there is about digital data, it's actually Shannon.

 

[gregorio]

no matter what protocol, term, or concept there is about digital data, it's actually Shannon.

No, no, nothing to do with Shannon. Shannon was wrong, Stereophile, Rob Watts and some guys from the Cables subforum proved he was wrong and the USB protocol is wrong and in fact all digital protocols!

G