Connessione digitale USB, flusso "audio" o flusso dati ???

[ilmisuratore]

Al giorno d'oggi tutti i DAC utilizzano la USB asincrona, ma qualcuno dovrebbe fare chiarezza (tipo @Gustavino) in quanto la definisce un "flusso audio"

Che significa "flusso audio" su un protocollo che si avvale della trasmissione asincrona di pacchetti con tanto di feedback CRC ????

Per caso viene scambiato per un trasferimento di tipo Biphase Mark ? 

Per caso viene scambiato per un protocollo USB sincrono ? (il quale clock dipende dalla sorgente...che può essere un pc tanto quanto uno streamer)

Per caso viene scambiato per un protocollo isocrono adattivo ? (i cui pacchetti vengono inviati con una cadenza fissa ??)

A questo viene messo in dubbio anche l'integrità del dato (prima viene definito "flusso audio" e poi integrità del dato..boh ?) 

Ho cercato di spiegare come funziona il trasferimento usb asincrono, ma a quanto pare la definizione di "flusso audio" riserva delle peculiarità sconosciute 

Chiedo cortesemente al principale interlocutore (Gustavino) di fare chiarezza sul significato di "flusso audio" e di spiegarne dettagliatamente il funzionamento, i problemi e il perchè si mette in dubbio l'integrità del dato (dato su un "flusso audio" ?)

Tutti invitati per chi vuole discuterne

[walge]

@ilmisuratore

stai chiedendo la luna, credo.

L'argomento fu discusso su AUdioreview in tempi lontani ed in modi precisi

 

Walter

[ilmisuratore]

9 minuti fa, walge ha scritto:

@ilmisuratore

stai chiedendo la luna, credo.

L'argomento fu discusso su AUdioreview in tempi lontani ed in modi precisi

Walter

Hai ragione, ma oltre ad avere le idee chiare sul tema USB asincrono, il controllo dell'integrità sui dati avverrebbe perfino con il protocollo isocrono (anche se non è previsto il CRC con ritrasmissione del dato perso)

La curiosità riguarda a quello che interpreta Gustavino con le sue frasi, un po strane...tipo "flusso audio" e successivamente "non c'è integrità del dato" 

 

Isochronous transfer mode uses error-checking but includes no re-transmission in case of Cyclic Redundancy Check (CRC) errors. Electrical noise on USB signals causes CRC errors and thus data loss, as does poor signal integrity. In mild cases, this leads to audio signal distortions. In the worst cases, clicks and dropouts
 

[ilmisuratore]

Facciamo finta che le mie spiegazioni fossero inesistenti, e raccogliamo qualche dichiarazione presa dal web...

 

il protocollo più performante in termini di reiezione del Jitter per un transfer digitale liquido pc/dac è quello asincrono con clock master locale, sia firewire che usb.
E' un trasferimento dati" senza possibilità di perdita errori/segnale, poichè funziona rigorosamente secondo istruzioni all'host...ad ogni ricezione confermata del pacchetto ne viene chiesta un altra.
Il protocollo asincrono implementa un feeedback di controllo sulle istruzioni, l'arbitraggio del bus e assenza di underrun/overrun con clock direttamente nel device.
 

[one4seven]

Purtroppo, in ambito audio digitale, ci si confonde ancora, nel 2024, con le connessioni analogiche.

Nell'audio digitale, non esiste un flusso audio, se riproduco un file, come non esiste un flusso cartaceo se mando in stampa una lettera.
Esistono solo dati.
Eh però... a sto punto, temo che non si capirà mai.

 

[ilmisuratore]

Alla teoria possiamo anche unire i FATTI

Basta ragionare su questa prova dalla quale si RI-ottiene il medesimo codice binario di partenza, su un circuito il cui trasferimento riguarda diversi passaggi, il primo di tipo asincrono, il secondo di tipo sincrono, il terzo nuovamente asincrono e che porta alla fine una perfetta integrità dei DATI

La qualità dei clock conta zero in quanto le alterazioni di timing vengono bufferizzate e riordinate

Come dire: le cose funzionano perfettamente, ma qualcuno (Gustavino) le mette in dubbio

 

 

[Felis]

"flusso audio" mi fa molto spago del telefono senza fili. 

[ilmisuratore]

9 minuti fa, one4seven ha scritto:

Purtroppo, in ambito audio digitale, ci si confonde ancora, nel 2024, con le connessioni analogiche.

Nell'audio digitale, non esiste un flusso audio, se riproduco un file, come non esiste un flusso cartaceo se mando in stampa una lettera.
Esistono solo dati.
Eh però... a sto punto, temo che non si capirà mai.

Bisogna vedere cosa intende per "flusso audio" appunto...

Ma siccome spesso fa questa discriminazione (tra flusso audio e dati) mi sa che si sarà confuso (forse)

[jackreacher]

13 minuti fa, ilmisuratore ha scritto:

Bisogna vedere cosa intende per "flusso audio" appunto...

Ma siccome spesso fa questa discriminazione (tra flusso audio e dati) mi sa che si sarà confuso (forse)

Ciao, questo lo penso pure io. In effetti bisognerebbe parlare solo ed esclusivamente di "flusso dati" né più né meno.

Un po' diverso il discorso della lettura di un cd audio codificato correttamente secondo il red book, dove ai "dati" (musica) sono aggiunte altre informazioni per la correzione degli errori e quant'altro (dati per il giusto funzionamento ma non musica).

[ilmisuratore]

2 minuti fa, jackreacher ha scritto:

Ciao, questo lo penso pure io. In effetti bisognerebbe parlare solo ed esclusivamente di "flusso dati" né più né meno.

Un po' diverso il discorso della lettura di un cd audio codificato correttamente secondo il red book, dove ai "dati" (musica) sono aggiunte altre informazioni per la correzione degli errori e quant'altro (dati per il giusto funzionamento ma non musica).

Concordo

[maxgazebo]

52 minuti fa, ilmisuratore ha scritto:

Facciamo finta che le mie spiegazioni fossero inesistenti, e raccogliamo qualche dichiarazione presa dal web...

il protocollo più performante in termini di reiezione del Jitter per un transfer digitale liquido pc/dac è quello asincrono con clock master locale, sia firewire che usb.
E' un trasferimento dati" senza possibilità di perdita errori/segnale, poichè funziona rigorosamente secondo istruzioni all'host...ad ogni ricezione confermata del pacchetto ne viene chiesta un altra.
Il protocollo asincrono implementa un feeedback di controllo sulle istruzioni, l'arbitraggio del bus e assenza di underrun/overrun con clock direttamente nel device.
 

Si, infatti è il motivo per cui è impossibile che un cavo CAT o uno switch di rete possa avere doti sonore...è pura suggestione legata a concetti audio analogici, a vecchi meccanismi mentali di segnali nel dominio del continuo, a sinusoidi che ballano nei fili soggette a impedenze, reattanze, suscettanze...

[Max440]

Discussione interessante.

Ovviamente, un flusso audio è quello che esce dalle uscite analogiche (RCA o XLR che siano) del lettore cd o del dac, ovvero una corrente, con relativi valore di tensione e relative forme d'onda, che poi va ad interagire, in base ai parametri di impedenza di uscita del lettore cd o dac e di impedenza di ingresso del pre/ampli, con una "amplificazione in potenza", creando il segnale che poi "smuove" le membrane (o quant'altro) degli altoparlanti.

Ma, che io sappia, un flusso digitale è un flusso dati, a prescindere che contenga la codifica di un suono, di una immagine, di un video, etc ...

Attendo spiegazioni più dettagliate da chi ne sa di più.

Thanks,

Max

[appecundria]

.

[maxgazebo]

@appecundria ok, in questo senso si parla di trasporto dell'informazione, che prescinde dal mezzo utilizzato

[ilmisuratore]

17 minuti fa, Max440 ha scritto:

Discussione interessante.

Ovviamente, un flusso audio è quello che esce dalle uscite analogiche (RCA o XLR che siano) del lettore cd o del dac, ovvero una corrente, con relativi valore di tensione e relative forme d'onda, che poi va ad interagire, in base ai parametri di impedenza di uscita del lettore cd o dac e di impedenza di ingresso del pre/ampli, con una "amplificazione in potenza", creando il segnale che poi "smuove" le membrane (o quant'altro) degli altoparlanti.

Ma, che io sappia, un flusso digitale è un flusso dati, a prescindere che contenga la codifica di un suono, di una immagine, di un video, etc ...

Attendo spiegazioni più dettagliate da chi ne sa di più.

Thanks,

Max

Un flusso dati, quali ad esempio l'output della USB (che li trasmette tramite i fili verde e bianco D+ e D-) viene veicolato su una portante analogica ad alta frequenza (la forma d'onda che la rappresenta è un onda quadra) e questa determina lo stato I/0 e la codifica del segnale 

Lo stato I/0 a sua volta viene decodificato e indirizzato come valori di tensione, interpolati correttamente (affinchè venga ricostruita la forma d'onda originaria del segnale analogico) e clocckati secondo le specifiche richieste della frequenza di campionamento ed infine traslati allo stadio analogico di uscita come, appunto segnale audio (e non piu dati)

[ilmisuratore]

Questo è quanto viene rappresentato dal flusso dati USB, vale a dire la portante D+ D- 

 

[Ggr]

L!argomento è tanto interessante quanto elementare da capire..

Non c'è nessun mistero I dati sono dati. 

Il problema eprenderne atto e farsene una ragione . Quella è una causa persa  chi vuol credere alle favole dei druidi,ci crederà sempre.

[ilmisuratore]

24 minuti fa, Ggr ha scritto:

L!argomento è tanto interessante quanto elementare da capire..

Non c'è nessun mistero I dati sono dati. 

Il problema eprenderne atto e farsene una ragione . Quella è una causa persa  chi vuol credere alle favole dei druidi,ci crederà sempre.

Ma soprattutto...

 

The USB specification calls for the use of Cyclic Redundancy Checksums (CRC) to
protect all non-PID fields in token and data packets from errors during transmission

 

Ora, sperando che Gustavino non sia scappato per le pianure del serengeti, aspettiamo la sua versione, visto che ha palesemente "confutato" delle cose che sono in forte contraddizione con le specifiche dei protocolli e interfacce