Perché non basta il cavo USB da stampante

[Membro_0015]

Nei pacchetti usb e presente una checksum

[ClaveFremen]

1 ora fa, stanzani ha scritto:

Nei pacchetti usb e presente una checksum

Corretto, serve a rilevare l'eventuale presenza di errori ma non viene effettuata nessuna ritrasmissione né correzione di errore, come specificato chiaramente nel protocollo USB.

 

 

[Membro_0015]

@ClaveFremen se la checksum e errata lo slave non invia un pacchetto ACK e il master ritrasmette

 

12. How does USB protocol detect an error in communication?
USB protocol detects error using CRC (Cyclic Redundancy Check). This is done by the SIE (Serial Interface Engine), thus eliminating the need of CRC check in software and reduces the software overhead. For token packet CRC is 5 bit & data packet CRC is 16 bits.
13. What happens if the SIE receives data that is corrupted?
The SIE discards the corrupt packet if the packet fails the CRC checks. No software intervention is required. An error flag is set indicating that a corrupted packet was received. The SIE will not ACK packets that have incorrect CRC values. For interrupt, bulk, and control transfers the host will try to retransmit the packet if it fails to receive the ACK. In this way these transmissions will not have data loss due to a corrupted packet but may suffer from lower application bandwidth.

[ClaveFremen]

3 minuti fa, stanzani ha scritto:

se la checksum e errata lo slave non invia un pacchetto ACK e il master ritrasmett

Tranne che per i trasferimenti isocroni, gli unici utilizzati da USB audio, in un altro thread sui cavi avevo postato i riferimenti, quando lo ritrovo metto il link.

[ClaveFremen]

Non sembra essere più disponibile il doc della usb.org, mentre cerco ancora (da https://www.edn.com/fundamentals-of-usb-audio/):

 

Isochronous transfers are used to transfer data in real-time between host and device. When an isochronous endpoint is set up by the host, the host allocates a specific amount of bandwidth to the isochronous endpoint, and it regularly performs an IN- or OUT-transfer on that endpoint. For example, the host may OUT 1 KByte of data every 125 us to the device. Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong. The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism.

 

 

[Membro_0015]

@ClaveFremen grazie. qui pero dice

 

 

Characteristics of the Interrupt Transfer mode are:

Guaranteed Latency

Stream Pipe - Unidirectional

Error detection and next period retry.

Therefore, there is an error control and management. However, this is not entirely clear.

 

non cæeæ correzione di errore ma cæeæ rilevamento di errori cosi da permettere allo host di ritrasmettere. Mi par di capire che viene fatto a livello SW )di driver ASIO WASAPI o ALSA o altro=

 

 

https://www.xmos.ai/fundamentals-of-usb-audio/#fundamentals-of-usb-audio

 

la discussione eæ avvincente ma non cæeæntra molto con i cavi da gioielleria mi sembra

 

cordialita'

[ClaveFremen]

13 minuti fa, stanzani ha scritto:

la discussione eæ avvincente ma non cæeæntra molto con i cavi da gioielleria mi sembra

concordo, ma è da dove nasce il thread se leggi il primo post. ;)

 

13 minuti fa, stanzani ha scritto:

qui pero dice

e nel post dopo:

Isochronous mode is used for transfer of audio samples. As you say, there is no error correction, though there is error detection (checksums) which would allow damaged packets to be dropped. Interrupt and control transfer are used for other purposes.

Ho trovato il doc, a pagina 44:

In the USB environment, requesting an isochronous transfer type provides the requester
with the following:
• Guaranteed access to USB bandwidth with bounded latency
• Guaranteed constant data rate through the pipe as long as data is provided to the pipe
• In the case of a delivery failure due to error, no retrying of the attempt to deliver the data

 

13 minuti fa, stanzani ha scritto:

Mi par di capire che viene fatto a livello SW )di driver ASIO WASAPI o ALSA o altro=

Per la natura stessa del protocollo non c'è il tempo per gestire le ritrasmissioni, non potresti più garantire il real-time:

 

15 minuti fa, ClaveFremen ha scritto:

Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong.

 

[Membro_0015]

3 minuti fa, ClaveFremen ha scritto:

non potresti più garantire il real-time:

Vero ma per il solo audio la latenza non è un problema se è dell'ordine dei secondi

 

Comunque mi sono... Schiarito. Io ho lavorato nel sw coi bulk endpoint e non finisco mai di imparare

 

Ciao

[Ifer2]

@stanzani Secondo me se tu che non conosci bene come funziona il protocollo usb 🙂.
A conferma da quanto da me esposto ti riporto quanto spiegato da un paio di famosi progettatori di cavi che sicuramente ne sanno più di te e di me di:
"Jim Aud, Purist Audio Design
When thinking about a digital signal over USB, it can seem natural to think of it as a straightforward expression of 1's and 0's. However, it is more nuanced than that. Below a certain voltage, the signal says: "this is a 0." Above a certain voltage, it says "this is a 1." So, a 1 may be a 3.2 volt signal, and a 0 might be a 2.9. Since data transfer happens fast and often, it doesn't take much to skew a 1 to a 0, or a 0 to a 1. The digital signal isn't this series of neatly packaged squares, all labeled 1 or 0. They are in the ballpark, but they aren't completely uniform."
E ancora sull'accostamento ad un cavo analogico bilanciato:
"Rob Woodland, Curious Cable
So, the first step is to view the USB cable as an analog cable rather than digital. In this sense, the closest analog relative is a "balanced" interconnect cable. Both feature differential mode transmission."
Questa è la fonte, se vuoi imparare qualcosa in più sui cavi usb 😉
https://positive-feedback.com/audio-discourse/why-usb-cables-can-make-a-difference/

[Membro_0015]

@Ifer2 stai chiedendo all'oste se il suo vino è buono... Descrizione qualitativa imprecisa  e umanistica comunque. I libri di elettronica sono tutt'altra cosa ma non sono alla portata di tutti... Cosa che ci può stare purché non si salga sul pulpito

[Ggr]

Tra l'altro condita con molti condizionali. Si potrebbe sentire....potrebbe causare..tutti a parlare di jitter, omettendo di dire che la temporizzazione che passa nel cavo usb vale niente per il dac, che una volta ricevuto il pacchetto dei dati, lo processa con il suo click e non con quello che gli arriva dalla sorgente.

Peraltro, tutti concordano sulla schermatura dai disturbi, e su questo convengo anche io che possono farsi sentire, quindi il cavo meglio schermato, potrebbe ( condizionale come loro) suonare meglio.

Siamo al normale buon senso. Cavi ben costruiti schermati e che rispecchiano le specifiche. Questo serve. Come in tutto.

[Membro_0015]

13 minuti fa, Ggr ha scritto:

tutti concordano sulla schermatura dai disturbi, e su questo convengo anche io

Sulla interposizione di un isolator e tra host e dac convengo anch'io. La udibilita dipente da quanto è incompetente la messa a terra dell'impianto ma nulla a a che vedere su jitter protocollo etc. Un bel pezzo pseudoscientifico scritto sotto dettatura dell'ufficio marketing

[gimmetto]

Il 17/10/2022 at 21:03, leonida ha scritto:

non so se per te il concetto di esistenza sia strettamente legato all'esistenza di una chiara e ripetibile  sensazione, o viceversa alla possibilità di una misurazione come condizione prioritaria per poter avallare e confermare quanto tu abbia chiaramente sentito.

...la seconda che hai detto!

[gimmetto]

4 minuti fa, stanzani ha scritto:

Un bel pezzo pseudoscientifico

Tò, l'hi end...

[Ifer2]

@stanzani considera che quei progettatori sono dei tecnici che spiegano in un'intervista questioni tecniche in modo comprensibile a tutti.

I libri di elettronica li hanno letti e sicuramente anche ben capiti