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

[ilmisuratore]

 

Audiophilleo dichiara questa configurazione

 

 

ASYNCHRONOUS USB

Apart from all the marketing hype, asynchronous USB transfer mode simply means that a "downstream" audio device, the Audiophilleo in this case, controls when the computer sends data through its USB interface and how much at a time. 

 

[ilmisuratore]

 

Bah...Gustavino ride, mette faccine, decontestualizza discorsi, prende immagini dal web senza capire quello che c'è scritto

Mi sto stufando...

 

Asynchronous USB capable DACs are few and far between. Currently Ayre, Wavelength, and dCS are the major manufacturers with asynchronous products on the market. In my opinion the reason for this lack of

async DACs is simply because it's very difficult implement this technology. There is a specific skill set required to implement asynchronous USB and it's not common place in high-end audio. Implementing async USB requires a manufacturer to write its own software for the TAS1020 chip and invest thousands of hours on this part of the DAC alone. The limited number of manufacturers who've decided to take on this task instead of going with a plug n' play chip are doing it because they think the performance gains far outweigh the development pain.

Asynchronous USB essentially turns the computer into a slave device as opposed to adaptive USB which does the opposite. Thus, an asynchronous USB DAC has total control over the timing of the audio. One very important feature of asynchronous USB mode is bidirectional communication between the computer and the DAC. The computer sends audio and the DAC sends commands or instructions for the computer to follow. For example the computer's clock becomes less accurate over a given period of time and can send too much data too quickly and fill up the buffer. Asynchronous DACs will instruct the computer to slow down, thus avoiding any negative effects of a full, or empty, buffer which can manifest itself into audible dropouts and pops or clicks. According to Wavelength Audio the tail is no longer wagging the dog when using asynchronous USB mode. Plus all of this is done without additional device drivers or software installation.

 

[captainsensible]

@ilmisuratore In asincrono sostanzialmente il clock del ricevitore è indipendente da quello della sorgente.

Il ricevitore fa il controllo del flusso dei dati che gli arrivano e non c'è ritrasmissione dei pacchetti corrotti.

CS

[ilmisuratore]

21 minuti fa, captainsensible ha scritto:

@ilmisuratore In asincrono sostanzialmente il clock del ricevitore è indipendente da quello della sorgente.

Il ricevitore fa il controllo del flusso dei dati che gli arrivano e non c'è ritrasmissione dei pacchetti corrotti.

CS

Bravo !!! (cominciavo a sentirmi solo )

E' esattamente quello che sto cercando di far comprendere al Gustavino...vale a dire: il protocollo può essere definito isocrono sul trasferimento dati che seguono una linea di pacchettizzazione con dimensioni fisse e con intervallo di tempo regolare ogni 125us o 1ms (a seconda del progetto/richiesta), ma configurato in modo asincrono a livello di clock

Un nodo, detto Cycle Master, è incaricato di inviare un pacchetto di sincronizzazione, detti pacchetti sono solo segnali di arbitraggio e servono ad arbitrare il sistema e dare un ordine alle trame

Il clock interno -indipendente- come giustamente hai menzionato fa la lettura dei campioni e il pilotaggio dei convertitori

Il clock interno è usato anche per generare i Cycle Start Packet di arbitraggio del bus
Il computer '"prende atto"' dell'arbitraggio del bus e invia le sue trame secondo quello che è richiesto dal collegamento
Nota: eventuali irregolarità di trasmissione del bus saranno assorbite
dalle FIFO e/o buffer

[ilmisuratore]

39 minuti fa, captainsensible ha scritto:

non c'è ritrasmissione dei pacchetti corrotti.

Essendo prevista soltanto in rarissimi casi d'implementazione Async Bulk, gli unici dati veramente corrotti (causa underrun/overrun) risalgono a circa l'anno 98/2000, quando per cause relative ai problemi d'implementazione del driver, ci si imbatteva in chiare interruzioni del suono e/o clic e scoppiettii

Mi ci sono imbattuto diverse volte, in special modo con lo standard IEEE 1394...o comunemente piu conosciuto come interfaccia FireWire

Oggi le cose funzionano egregiamente

[Ramsete2]

Io so solo una cosa, se il forum vietasse l’inserimento degli screenshot @Gustavino sarebbe fottuto…

[loureediano]

Il problema come detto da altro, sono le bocche da sfamare.

I cavi usb milionari, i super switch, i femto clock e non ulti i i cavi ethernet da miliardi di euro e tutti i gadget di contorno chi li comprerebbe?

[widemediaphotography]

La pratica, quella che si riscontra effettivamente sulla base di esperienze oggettivabili, vale a dire registrabili e misurabili,  è in grado di affermare con certezza cosa abbia di migliorabile la connessione USB, la S/DIF o la I2s.

Dal punta di vista pratico trattandosi di connessioni  digitali, sulle brevi distanze non ci sono reali problemi e differenze apprezzabili all'ascolto.

 

• S/PDIF è quella nata assieme alla musica digitale, aveva alcuni limiti e problemi ed è stata notevolmente migliorata tanto da poter affermare, che il trasferimento avviene con livelli di jitter assolutamente trascurabili. Questo perché l'estrazione dell'audio dal CD, avviene in tempo reale e non può esistere rilettura durante la riproduzione. Mi pare che i test dell'OP lo confermino. Lo stesso test, con HW diverso (scheda RME PCIe), l'avevo eseguito un paio di anni fa e con i medesimi risultati.
• I2s (come interconnessione) esterna nasce per migliorare sulla carta i punti deboli di S/PDIF, ne ho scritto nei post precedenti. Funziona e ci mancherebbe, ma necessita di un'interfaccia nuova che sostanzialmente fa quello che già fa il DAC, non ha uno standard nemmeno per i plug, e non è adatta per lunghe distanze, non ha verifica e controllo errori (ma serve?). In pratica I2s vuole risolvere un problema che non esiste!
• USB è il protocollo seriale che nel mondo informatico ha sostituito la porta seriale, come per  la firewire, e nasce per le interconnessioni tra device dove sostanzialmente si scambiano dati (a volte solo per trasporto di energia senza dati come nei caricabatteria). Il suo protocollo è complesso perché prevede una serie di modalità che si istituiscono tra Host (PC) e Device (anche tanti contemporaneamente con funzioni differenti, ad esempio DAC, stampanti, Hard disk). Dalla versione 2.0, che consente un data transfer adeguato è utilizzato anche per la fruizione di audio digitale. IL POMO DELLA DISCORDIA di questa discussione. Esistono fondamentalmente 4 modalità di Transfer che vengono stabilite (viene scelto il driver SW) quando l'Host(PC) riconosce il Device (DAC). Quando si veicola l'audio HD viene scelta la modalità Transfer  Isocronica in modalità  Asincrona, dove i pacchetti vengono inviati dal DEVICE secondo regole stabilite dal Device (non c'è clock), ma viene omessa la verifica degli errori per una questione di velocità. Nella modalità Asincrona il clock per la ricostruzione del Flusso Audio è proprio del DAC.  Il file è già integro, non deve essere estratto da un supporto fisico (CD) in tempo reale e pertanto non serve clock dall'Host. Se si deve trovare un punto debole nella USB (vale anche per I2s) è che attraverso la linea Ground viaggiano anche i disturbi dovuti ai loop di terra e di sistema, ma è compito del DAC ripulire il segnale di ciò che non serve e nella pratica, quella oggettivabile, confermata da test e misure accurate di laboratorio, si dimostra che un buon DAC è praticamente immune dai disturbi di cui prima, già per device di poche centinaia di euro! Aggiungere una modalità che preveda, come nella modalità bulk anche il controllo errori... non lo si fa per una questione di retrocompatibilità, e soprattutto perché al momento non se ne sente la necessità. 

Ho riassunto  a parole mie, cercando di far capire anche ad un semplice appassionato come stanno le cose.

Non ho inventato nessun protocollo audio, ma qualcosa penso di averla capita in ambito audio digitale ed esistono al mondo migliaia di persone che ne sanno più di me... Lo accetto serenamente.

[ilmisuratore]

11 minuti fa, loureediano ha scritto:

Il problema come detto da altro, sono le bocche da sfamare.

I cavi usb milionari, i super switch, i femto clock e non ulti i i cavi ethernet da miliardi di euro e tutti i gadget di contorno chi li comprerebbe?

Il test svolto sull'integrità dei dati, nonché le capacità di veicolare un segnale digitale con una ENOB elevata (esattamente quella che viene mantenuta dalle specifiche) vede l'utilizzo di un cavo USB ordinario...a guardarlo molto simile a quello di una stampante 

Il ragionamento è che se un cavo USB ordinario svolge perfettamente il lavoro di trasferimento, al massimo si potrà soltanto peggiorare con l'utilizzo di oggetti che in qualche modo alterano appositamente i dati e/o la ENOB 

La cosa ancora più raccapricciante è che la sorgente che generava il clock era alimentata tramite USB del computer...come la stessa interfaccia in SLAVE... anch'essa autoalimentata dal computer, quindi il rumore in ingresso non ha minimamente intaccato l'originalità del segnale, sia quello di partenza, né tantomeno quello di arrivo

 

 

[mikefr]

A Gustavì,e rispondi a ste due domande che ti ha fatto @ilmisuratore ........................

[maxgazebo]

52 minuti fa, loureediano ha scritto:

Il problema come detto da altro, sono le bocche da sfamare.

I cavi usb milionari, i super switch, i femto clock e non ulti i i cavi ethernet da miliardi di euro e tutti i gadget di contorno chi li comprerebbe?

Nessuno, infatti il mercato ha bisogno del consumatore che spende soldi per vari motivi, basta che li spende...stesso discorso per gli orologi, p.e....non avrebbe senso comprarsi il Rolex, basterebbe un Casio digitale, che anzi è pure più preciso, guarda tu...

[ilmisuratore]

1 ora fa, widemediaphotography ha scritto:

Mi pare che i test dell'OP lo confermino.

La spdif utilizza un protocollo di tipo biphase Mark, l'unica pecca è che assieme al data signal veicola anche il clock di riferimento 

Questo fatto responsabilizza la qualità del ricevitore PLL del DAC, quindi le sorti del risultato finale dipendono da quanto jitter viene veicolato dalla sorgente e quanto ne viene recuperato dal jitter recovery del ricevitore 

Alla fine sorgente e DAC sono complementari 

Il test svolto non vede DAC nel percorso del segnale per cui il trasferimento dei dati non viene intaccato minimamente nemmeno con l'interfaccia ritenuta più scarsa possibile... ovvero la toslink con la quale avviene anche un doppio processo di conversione optoelettrica

[widemediaphotography]

1 minuto fa, ilmisuratore ha scritto:

La spdif utilizza un protocollo di tipo biphase Mark, l'unica pecca è che assieme al data signal veicola anche il clock di riferimento 

Questo fatto responsabilizza la qualità del ricevitore PLL del DAC, quindi le sorti del risultato finale dipendono da quanto jitter viene veicolato dalla sorgente e quanto ne viene recuperato dal jitter recoverry del ricevitore 

Alla fine sorgente e DAC sono complementari 

Il test svolto non vede DAC nel percorso del segnale pee cui il trasferimento dei dati non viene intaccato minimamente nemmeno con l'interfaccia ritenuta più scarsa possibile... ovvero la toslink con la quale avviene anche un doppio processo di conversione optoelettrica

Esattamente, perché al tempo la disponibilità di cip performanti a buon mercato era scarsa e Sony e Philips sono state "costrette" , per risparmiare e rendere più fruibile la nuova tecnologia, a far viaggiare il clock assieme ai dati. Questo processo se non ben eseguito comporta generazione di jitter che a sua volta può essere incrementato dal DAC nella successiva fase di conversione. Come ho spiegato all'uscita della porta ottica del player  YAMAHA CD-s303 ho acquisito un file waw sovrapponibile da quello estratto con un masterizzatore PC, che sappiamo essere a zero bit errore. 

[ilmisuratore]

@widemediaphotography

Il test effettuato ha un importanza rilevante... parecchia, poiché dimostra che nel dominio digitale facendo uso di oggetti ordinari, interfacce ordinarie (vedi la toslink e quel cavetto a corredo orribile) e alimentazioni raccapriccianti... avviene un trasferimento perfetto e senza perdita di dati 

Poi, una volta riordinati sul PC se ne può fare uso come si vuole, anche attaccando un DAC da un milione di euro, che attingerà ad un codice binario perfettamente integro e congruo con il file musicale di origine 

[Ggr]

1 ora fa, mikefr ha scritto:

A Gustavì,e rispondi a ste due domande che ti ha fatto @ilmisuratore ........................

Veramente sono 3. Ne ho fatto una anche io...😃

[widemediaphotography]

@ilmisuratore Quella della prova sull'uscita ottica rimane a mio avviso un test fondamentale che ha una serie di indiscutibili ripercussioni che smontano alcuni miti. 

Infatti essendo l'uscita ottica galvanicamente isolata e quel player Yamaha alimentato con un alimentatore switching esclude la possibilità che un alimentatore lineare possa apportare dei benefici all'uscita della sorgente digitale. Il File di uscita è sovrapponibile al file estratto da PC, senza che esca dall'Uscita USB; quindi uguale al master! La seconda implicazione è che se il DAC fa bene il suo lavoro non ci sono differenze tra Spidif/coax/opt  USB, I2s. Le scelte vanno ricercate sulla possibilità di decodifica dei file HD dove su Spdif sono più limitate, in particolare la Toslink ottica che normalmente si arresta a 24/96Khz

[ilmisuratore]

10 minuti fa, widemediaphotography ha scritto:

@ilmisuratore Quella della prova sull'uscita ottica rimane a mio avviso un test fondamentale che ha una serie di indiscutibili ripercussioni che smontano alcuni miti. 

Infatti essendo l'uscita ottica galvanicamente isolata e quel player Yamaha alimentato con un alimentatore switching esclude la possibilità che un alimentatore lineare possa apportare dei benefici all'uscita della sorgente digitale. Il File di uscita è sovrapponibile al file estratto da PC, senza che esca dall'Uscita USB; quindi uguale al master! La seconda implicazione è che se il DAC fa bene il suo lavoro non ci sono differenze tra Spidif/coax/opt  USB, I2s. Le scelte vanno ricercate sulla possibilità di decodifica dei file HD dove su Spdif sono più limitate, in particolare la Toslink ottica che normalmente si arresta a 24/96Khz

Possiedo al momento del materiale per poter condurre anche quest'altro esperimento, ovvero: prelevare la qualità del segnale dallo stadio uscita analogico del DAC interponendo all'ingresso digit sia la coassiale, sia la toslink veicolati da una sorgente autoalimentata dal PC

Lo scopo sarebbe quello di confrontare le prestazioni tra RCA coax e quello della toslink ottica, nonchè l'eventuale traslazione di disturbi visto che la sorgente è alimentata in switching e con una VBUS abbastanza rumorosa

Mi sa che lo faccio...

[Ggr]

6 minuti fa, ilmisuratore ha scritto:

prelevare la qualità del segnale dallo stadio uscita analogico del DAC

Che poi è davvero l'unica cosa che conta.

Ingressi diversi, stessa uscita, si vedono le differenze ( se ci sono )...