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

[one4seven]

9 minuti fa, ilmisuratore ha scritto:

serengeti

Lo intravedo sotto quell'albero a sinistra in fondo.... 

[widemediaphotography]

2 ore 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.
 

Con questa definizione non resta nulla da aggiungere!

 

P.S. Volevo fare chiarezza sul termine "flusso audio digitale", che a volte ho usato e con il quale si intende un termine generico associato ad un pacchetto di dati provenienti da una generica sorgente audio digitale, senza specificarne la natura e che sappiamo dipendere dal particolare protocollo di trasmissione.

[Ggr]

1 ora fa, one4seven ha scritto:

Lo intravedo sotto quell'albero a sinistra in fondo.... 

Ti sbagli. In realtà è sotto quello a destra. I bit sono arrivati un po alla rinfusa. C!era jitter.

[AlbertoPN]

I dati sono dati, i dati digitali in codice binario una sequenza di 0 ed 1.

Che quello che c'è a valle legga ed interpreti questi dati, poi, come musica, video, una lettera, un disegno tecnico, delle istruzioni di funzionamento di qualcosa o quello che volete, d'accordo.

Ma i dati sono e rimangono dati.

Dalla USB transitano un flusso di dati, così come dalla porta RJ45, dalla RS232/485 o quella che più vi piace.

Coi loro protocolli, i loro standard, la loro velocità e la capacità di essere mono o bi-direzionali.

Dire che dalla USB esce "musica" perchè veicola (in quel caso) un flusso di dati digitali che successivamente saranno convertiti da un DAC in analogico e quindi in un segnale musicale, è come dire che da un microprocessore esca un flusso di coscienza perché gli è stato dato in pasto un algoritmo (argomento piuttosto attuale).

Una lettura capziosa e soggettiva di quella che è la realtà.

[ilmisuratore]

8 minuti fa, AlbertoPN ha scritto:

I dati sono dati, i dati digitali in codice binario una sequenza di 0 ed 1.

Che quello che c'è a valle legga ed interpreti questi dati, poi, come musica, video, una lettera, un disegno tecnico, delle istruzioni di funzionamento di qualcosa o quello che volete, d'accordo.

Ma i dati sono e rimangono dati.

Dalla USB transitano un flusso di dati, così come dalla porta RJ45, dalla RS232/485 o quella che più vi piace.

Coi loro protocolli, i loro standard, la loro velocità e la capacità di essere mono o bi-direzionali.

Dire che dalla USB esce "musica" perchè veicola (in quel caso) un flusso di dati digitali che successivamente saranno convertiti da un DAC in analogico e quindi in un segnale musicale, è come dire che da un microprocessore esca un flusso di coscienza perché gli è stato dato in pasto un algoritmo (argomento piuttosto attuale).

Una lettura capziosa e soggettiva di quella che è la realtà.

Giusto, ma raccolgo una serie di dichiarazioni esternate da @Gustavino che mettono a repentaglio tutto quanto si è affermato finadesso (le esternazioni riguardano nello specifico il protocollo USB e i chip controller)

In particolar modo le ultime battute in cui prima parla di "flusso audio" e non dati, e successivamente che non esisterebbe integrità del dato USB

 

---- > una periferica usb audio non e' un Harddisk usb

---> bel cippone ma intanto ce devi mette un bel clock e si sente 

----> ti conviene prendere un microprocessore con minore jitter la prossima volta che ci provi 

---> in realta fate entrambi parecchia confusione sulla usb

---> NOOOONEEE quello e' un flusso audio e non di dati che NON puo essere RIPARATO

---> vedi che non sai come funziona una USB !! non esite integrita' del dato nella usb

[AlbertoPN]

si ho capito @ilmisuratore ma se il tuo scopo è solo tirare su flame con @Gustavino al quale mi pare di capire, ricamba di cuore il tuo atteggiamento , datevi appuntamento da qualche parte e risolvetela come meglio credete.

Per tutto il resto c'è Mastercard

[ilmisuratore]

4 minuti fa, AlbertoPN ha scritto:

si ho capito @ilmisuratore ma se il tuo scopo è solo tirare su flame con @Gustavino al quale mi pare di capire, ricamba di cuore il tuo atteggiamento , datevi appuntamento da qualche parte e risolvetela come meglio credete.

Per tutto il resto c'è Mastercard

Non è questo lo scopo, ovvero quello di tirare flames

Lo scopo è fare chiarezza (???) su cose che mi sembrano scontate e che invece si tende a fare cattiva informazione 

 

[Ggr]

I flussi dati che contengono informazioni audio, sono flussi come altri.

C'è chi crede che un flusso dati possa essere in qualche modo corrotto, e causare suoni diversi. Poi però,  

Con lo stesso sistema ( flusso di dati) compra un bell!amificatore online, fa un bonifico da 1.000 euro, super sicuro che non diventerà da 10.000.... strano il mondo...

[ilmisuratore]

4 minuti fa, Ggr ha scritto:

I flussi dati che contengono informazioni audio, sono flussi come altri.

C'è chi crede che un flusso dati possa essere in qualche modo corrotto, e causare suoni diversi. Poi però,  

Con lo stesso sistema ( flusso di dati) compra un bell!amificatore online, fa un bonifico da 1.000 euro, super sicuro che non diventerà da 10.000.... strano il mondo...

Spero che al prossimo bonifico che riceverà Gustavino gli si corrompano i dati cosi' da ricevere un ingente somma di denaro

Poi però dividiamo a metà !!! 

[Gustavino]

6 hours ago, ilmisuratore said:

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

non so te maio ho una vita...innanzi tutto asincrona non dice nulla ,la trasmissione e' sempre iso ! nella asincrona si ha la cura di aver un buon clock locale  cosa che in un pc notoriamente non avvine !

[ilmisuratore]

1 minuto fa, Gustavino ha scritto:

innanzi tutto asincrona non dice, nulla la trasmissione e' sempre iso , nella asincrona si ha la cura di aver un buon clock locale  cosa che in un pc notoriamente non avvine !

Il clock del PC non viene interessato

Il clock del controller USB serve per dare ordine alle trame (pacchetti di dati, e NON "flusso audio")

Il clock locale nel DAC serve a sincronizzare il segnale secondo le specifiche della frequenza di campionamento, ovvero clock master di riferimento

Non hai specificato cosa intendi per "flusso audio" della USB a differenza dei dati

[Gustavino]

40 minutes ago, ilmisuratore said:

Il clock del PC non viene interessato

Il clock del controller USB serve per dare ordine alle trame (pacchetti di dati, e NON "flusso audio")

Il clock locale nel DAC serve a sincronizzare il segnale secondo le specifiche della frequenza di campionamento, ovvero clock master di riferimento

Non hai specificato cosa intendi per "flusso audio" della USB a differenza dei dati

non hai capito nulla mi tocca spiegartelo comincia da qui

[Gustavino]

questa e' facile ed e' collegata alla discussione del Bricasti ,Ravenna e lan, there in no time to resend data if anything goes wrong

[ilmisuratore]

Gustavino, stai descrivendo le caratteristiche del protocollo isocrono...si conoscono dai tempi dell'interfaccia Firewire di cui se ne faceva ampiamente utilizzo

Nonostante ciò (senza menzionare il protocollo asincrono) anche il protocollo isocrono prevede il controllo sull'integrità dei dati

Come la giri-giri ti contraddici in quanto per te non c'è garanzia di integrità del dato, quando in realtà le cose funzionano in modo egregio (anche senza super-clock mirabolanti)

Se il costruttore dichiara USB asincrona si deve seguire tale percorso

Se il costruttore dichiara USB isocrona si deve seguire un altro percorso

In realtà (tranne la USB sincrona) entrambi funzionano in modo eccellente

Tu paventi disastri e cerchi mirabolanti super-clock la cui efficacia è NULLA

[Gustavino]

25 minutes ago, ilmisuratore said:

Gustavino, stai descrivendo le caratteristiche del protocollo isocrono...si conoscono dai tempi dell'interfaccia Firewire di cui se ne faceva ampiamente utilizzo

Nonostante ciò (senza menzionare il protocollo asincrono) anche il protocollo isocrono prevede il controllo sull'integrità dei dati

Come la giri-giri ti contraddici in quanto per te non c'è garanzia di integrità del dato, quando in realtà le cose funzionano in modo egregio (anche senza super-clock mirabolanti)

Se il costruttore dichiara USB asincrona si deve seguire tale percorso

Se il costruttore dichiara USB isocrona si deve seguire un altro percorso

In realtà (tranne la USB sincrona) entrambi funzionano in modo eccellente

Tu paventi disastri e cerchi mirabolanti super-clock la cui efficacia è NULLA

continuii a non capire  che la comunicazione audio e' sempre ISO a prescindere dove clocki se sul pc (synch) o sul dac (async)

[Gustavino]

[ilmisuratore]

16 minuti fa, Gustavino ha scritto:

continuii a non capire  che la comunicazione audio e' sempre ISO

No, hai selezionato un chip Xmos che dichiara espressamente le relative caratteristiche di trasferimento, che può essere anche isocrono

Un TAS1020B ad esempio funziona in tutt'altro modo (vai a leggere le specifiche) asincrono bulk

Infatti ti ho scritto di selezionare prima il tipo di protocollo e discuterne specificamente

Il test che ho condotto (integrità sui dati) utilizza un XMOS 208 e nonostante i tuoi paventati "problemi" non accade nulla

Si ottiene un integrità dei dati alla perfezione, bit-to-bit

La richiesta del mirabolante super-clock e la perdita dei dati è una tua fissa (oltre che fantasia)

Il test lo puoi leggere quando vuoi, e linkato nei primi post

[Mighty Quinn]

@ilmisuratore

Statten'attint uajo' 

È partita la sagra degli screenshot del Nostro