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

[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 

[ilmisuratore]

10 minuti fa, Mighty Quinn ha scritto:

@ilmisuratore

Statten'attint uajo' 

È partita la sagra degli screenshot del Nostro 

Abbiamo tecnologie consolidate che -funzionano-

Sono perfettamente verificabili e misurabili

No...!!! bisogna condirle con le solite menate del super-clock che funziona in modo asincrono slegato dal clock che da ordine alle trame

Perfino il DAC della lavandaia oggi monta oscillatori femto..sempre che poi si avverta la differenza con quelli al picosecondo (a parole, ma se dovessimo passare ai fatti bisognerebbe salire almeno fino alla soglia delle centinaia di nanosecondi...centinaia...)

[Revenant]

@ilmisuratore la vuoi smettere di continuare a confutare con dati certi tutte quelle belle fantasie che fanno tanto contenti gli audiofili e, di conseguenza, tante persone che vivono creando prodotti di alto costo e di bell'aspetto?

C'è un mercato economico dietro a tutto ciò, si sfamano famiglie.

Non rompere l'incantesimo...

[Mighty Quinn]

@ilmisuratore

Quelle che tu affermi sono in genere tesi di una banalità rivoltante 

( è ovvio che nessuno sentirà mai il jitter di un normalissimo dac, ma nemmeno cento volte quello di un normalissimo dac, probabilmente 1000-10000 volte tanto forse forse...)

La tua forza contrattuale sta nel fatto che sei capace di supportare in modo divulgativo quasi tecnico le banalità che sostieni 

E ciò le rende ancor più insopportabili 

In determinati quartieri 

Perché non riescono nemmeno a giocarsi la carta della provocazione sperando nel fallo di reazione 

Na traggedia inzomma 

 

[ilmisuratore]

6 minuti fa, Mighty Quinn ha scritto:

@ilmisuratore

Quelle che tu affermi sono in genere tesi di una banalità rivoltante 

La tua forza contrattuale sta nel fatto che sei capace di supportare in modo divulgativo quasi tecnico le banalità che sostieni 

E ciò le rende ancor più insopportabili 

In determinati quartieri 

Perché non riescono nemmeno a giocarsi la carta della provocazione sperando nel fallo di reazione 

Na traggedia inzomma 

[Gerardo61]

Seguo 🤣

[Gerardo61]

18 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.
 

Chiedo anticipatamente venia per la domanda, ma sono un ascoltatore semplice con poche competenze elettroniche.

Viste le evidenze qualitative dell'usb, perché qualcuno si ostina con l'i2s?

Grazie 🙏

[ilmisuratore]

1 ora fa, Gerardo61 ha scritto:

Chiedo anticipatamente venia per la domanda, ma sono un ascoltatore semplice con poche competenze elettroniche.

Viste le evidenze qualitative dell'usb, perché qualcuno si ostina con l'i2s?

Grazie 🙏

Mi sembra più una moda che una necessità 

La i2s tecnicamente è nata per trasferire segnali di clock a brevissima distanza

Un segnale di clock è molto sensibile e basta poco per essere alterato 

Quando vedo collegamenti in i2s lunghi qualche metro ed estratti perfino da interfacce HDMI...allora credo che ci si voglia fare soltanto del male

[Gerardo61]

1 minuto fa, ilmisuratore ha scritto:

La i2s tecnicamente è nata per trasferire segnali di clock a brevissima distanza

Un segnale di clock è molto sensibile e basta poco per essere alterato 

Grazie di cuore per l'informazione. E' quello che pensavo e la tua spiegazione mi ha tolto ogni dubbio.

Buona giornata

Gerardo 

[widemediaphotography]

1 ora fa, Gerardo61 ha scritto:

Chiedo anticipatamente venia per la domanda, ma sono un ascoltatore semplice con poche competenze elettroniche.

Viste le evidenze qualitative dell'usb, perché qualcuno si ostina con l'i2s?

Grazie 🙏

Qualcuno per vendere qualcosa, in un mercato congestionato deve inventarsi qualcosa, ma che se non apporta nessun beneficio deve almeno funzionare, facendo proprio leva sul livello  di competenza dei clienti che in genere è basso, specialmente se facoltosi; ergo BINGO!

Risaputo che solo  agli albori S/PDIF aveva qualche problema di jitter, in cui il clock audio viene veicolato con i dati per ragioni di limiti della tecnologia del tempo, qualcuno come PSAudio  cosa ha pensato di fare...

 

1) Prendo il BUS e il protocollo usato nei DAC creo una nuova interfaccia per  interconnessione ESTERNE in cui il clock viene separato e veicolato in una linea a parte (quello che fa già il DAC). 

2)Basta omettere di scrivere che questo protocollo, nato per le interconnessioni interne, non è dotato di verifica e correzione di errori e che non esiste uno standard per i connettori e quindi ognuno si arrangia come crede.

 

A parte una maggior velocità I2s, dettata dal fatto che ha lo stesso BUS utilizzato all'interno dei DAC, I2s non è  quindi adatto per le connessioni esterne, specialmente se non cortissime, non prevede controllo di errori e non esiste uno standard definito nemmeno per i connettori.

Il vantaggio teorico è quello di eliminare un problema che nella pratica è stato risolto almeno 20 anni fa. Intatti, qualunque meccanica infima di qualunque player miserrimo nel 2024, fornisce all'uscita della PORTA TOSLINK, che è isolata anche  galvanicamente (I2s non lo è), un flusso a zero jitter o di un livello misurabile solo in laboratorio che ha zero effetti sull'ascolto.