Prova di -Bit Perfect- tramite interfaccia USB a "lungo termine" (14.400 secondi, ovvero: 4 ore di fila)

[Gustavino]

Just now, ilmisuratore said:

E come ti ho detto basta un attimo per liberarsene 

Tu ovviamente nell'alto della tua sapienza non lo sai (ma nemmeno meriti di venirne a conoscenza)

basta che sei convinto te

[ilmisuratore]

3 ore fa, Gustavino ha scritto:

non esiste il protocollo Asynch ,Asynch e' la sincronizzazione del unico protocollo audio usb che si chiama Isochono ,NON ha la correzione degli errori
vedo che fatichi ancora ti rimetto la mia chiara spiegazione :

Lo standard UAC2 invia dati SOLO utilizzando la modalità di trasferimento Isochrono. Questa è pensata per la trasmissione di dati high-bandwidth, time-sensitive, in cui i pacchetti persi/danneggiati non sono critici.
—-Isochrono
La modalità di trasferimento isocrono NON include un checksum, né alcun meccanismo di correzione/rilevamento degli errori. È anche unidirezionale. Pertanto, non esiste un modo integrato per il PC mittente di sapere se i dati sono stati ricevuti, né per un ricevitore di rilevare dati errati, tanto meno di correggerli o richiederne il reinvio.
 

UAC2 risolve parzialmente questo problema includendo il proprio CRC all'interno del protocollo stesso (vale a dire un livello superiore rispetto al meccanismo di trasferimento). Ciò aggiunge la possibilità per il ricevitore di rilevare se i dati in arrivo sono errati. Ma poiché non esiste la correzione degli errori, né un meccanismo di ripetizione/reinvio, limita significativamente ciò che può essere fatto quando vengono ricevuti dati errati.

La parte isochrona è il trasferimento dati USB di basso livello ,all'interno di tale specifica, sono disponibili tre metodi di sincronizzazione tra il pc ed il dac, di cui uno è asynch diffuso da 15anni circa . Quindi, a un layer superiore, il contenuto audio si muove in modo async su un trasporto isochrono di basso livello.
 

Async funziona tramite feedback , i dati sul bus USB vengono inviati in modo isochrono con clock usb del Pc ma la quantità di dati trasferiti in ogni blocco viene regolata in base al feedback dal (al PC) in modo che la velocità dati complessiva sul bus USB corrisponda alla velocità dati "richiesta" dalla destinazione, all'estremità "ricevitore" il flusso può essere riclockato utilizzando il master clock (locale)

Un DAC che riceve dati errati tramite UAC2 ha solo poche opzioni:
-Disattivare l'output finché non arrivano dati validi (vale a dire si verificano interruzioni).
-Riprodurre i dati così come sono e sperare per il meglio. leggi glitch
Indice che si ha un problema, che potrebbe essere un cavo difettoso o non in specifica come molti... un dispositivo rotto etc

Quindi  l'audio USB è una modalità di trasmissione di solo invio, non correggibile, che non garantisce affatto la ricezione dei pacchetti, e tanto meno che i pacchetti ricevuti siano corretti!
L'unica cosa che viene inviata al Pc  è un controllo asyncrono che gli dice di inviare il pacchetto successivo più velocemente o più lentamente , con convincoli temporali molto limitati.

La parte "async" del nome significa che il clock  usb  nel convertitore D/A non deve essere sincronizzato con il clock nel computer. Questa è un miglioramento rispetto al clock del pc  e relativo jitter della connessione ,nel convertitore audio si utilizzano  XO nettamente migliori alimentazioni migliori ,tecniche di reclock etc etc....
quindi con la modalità "async", il clock audio master è nel DAC, il buffer memorizza i dati audio in arrivo dal computer e il chip controller dice al computer di inviare più dati audio man mano che il buffer si svuota durante la riproduzione.

Fortunatamente, il danneggiamento/la perdita di dati utilizzando cavi conformi alle specifiche (incluso il rispetto delle limitazioni di lunghezza nelle specifiche USB 2.0) in un sistema correttamente funzionante sono rari.

Ora nel 2024 usb son abbastanza buone  ma negli ultimi 15anni ne hanno combinate di ogni ,se NoN recenti  un paio di domande  me le farei , visto che sono realizzate in 1000modi ,i recenti isolatori  introducono abbondante  Jitter che poi va'  eliminato , ve ne sono di  4 tecnologie diverse almeno con 100 modelli e di marche diverse   ,tale  isolamento si puo applicare in  modi diversi e non tutti son validi ne permessi , quando ti dicono :ma ha la usb isolata ed async ...significa il nulla cosmico! non pensate che il dacchino da 200€ sia ottima ,
che funzioni ,come anche la vecchia synch, e' sicuro quello che cambia e' il come ......  

questa e' la parte concettuale fortunatamente abbiamo all' orizzonte  interfacce migliori specialmente nella parte elettrica/ottica che contano molto di piu di quella dati

Grazie per avermi ricordato cose che sapevo 

Questo non ti libera dal fatto che alcune cose non le comprendi, né ora... ne mai

[ilmisuratore]

1 minuto fa, Gustavino ha scritto:

basta che sei convinto te

Non è convinzione, è oggettivamente un fenomeno che viene meno

Scompare sia ad orecchio che, ovviamente..alle misure

 

[Ggr]

Il 30/10/2024 at 13:54, ilmisuratore ha scritto:

Non è convinzione, è oggettivamente un fenomeno che viene meno

Scompare sia ad orecchio che, ovviamente..alle misure

Ma ci provi ancora...? In molti gli abbiamo fatto una domanda precisa, ha sempre fatto finta di niente.

Probabilmente non trova niente su google per rispondere, e sta chiedendo alla intelligenza artificiale... deve essere in difficoltà pure lei...

[widemediaphotography]

Visto che si è messa indubbio la mia Onestà Intellettuale chiedo al neo Professore, allo luce di quanto sostenuto nelle ultime disamine,   come faccia un DAC come smsl DO300 ad avere quelle misure non avendo la porta USB trattata, mentre risulta pure  dotato  di un alimentatore switching.

La pratica, che a forza si è voluta perdere di vista in questa discussione, afferma che il trasferimento audio via USB, nonostante la modalità Isocronica che è senza correzione errori (infatti non serve), sia priva di perdita di dati già con le più basiche implementazioni.

Ma la domanda:  Quale sarebbe l'alternativa a USB,  ancora non riceve risposta nonostante sia stata qui presentata come la schifezza delle schifezze!

 

P.S. Gli Isolatori USB non ottici hanno modesta efficacia...mentre il flusso che entra nella USB del DAC, con altissima probabilità, rimane sempre e solo bit perfect!

[Gustavino]

4 hours ago, Ggr said:

Ma ci provi ancora...? In molti gli abbiamo fatto una domanda precisa, ha sempre fatto finta di niente.

Probabilmente non trova niente su google per rispondere, e sta chiedendo alla intelligenza artificiale... deve essere in difficoltà pure lei...

le tue sono solo provocazioni  insignificanti

[ilmisuratore]

Relativamente al bit-perfect, piu si sale con la frequenza di campionamento e piu si "rischia" di imbattersi in errori

Mi chiedo se gli utilizzatori del DSD (vedi @Gerardo61 e tanti altri) fanno uso del collegamento USB e se con l'utilizzo di frequenze di campionamento altissime avvertono dei clic/pop e/o microinterruzioni nella riproduzione musicale

Questo potrebbe essere un indizio del fatto che, con frequenze altissime scaturisca qualche errore

Se invece la riproduzione risultasse sempre fluida ed esente dai fenomeni citati sopra, vuol dire che alle frequenze inferiori ci farebbe il solletico

Nel pomeriggio ho contattato un ex collega informatico che possiede una RME UC Fireface e che ha svolto anche lui delle prove

Mi assicura che per tutte le frequenze piu alte che possono transitare dalla sua scheda non ci sono errori...anche perchè (ma guarda un pò ) il trasferimento non è nemmeno isocrono ma asincrono BULK...per cui tali errori sarebbero scongiurati

[ilmisuratore]

Per completezza di informazioni al piu presto mi farò inviare (se l'avevo qui l'avrei aggiunto subito) il descriptor della scheda RME UC Fireface per vedere se viene riportato un protocollo isocrono o BULK (per come mi diceva il collega) cosi da verificare se il BULK (come ho sempre affermato) adotta anche implementazioni su device di tipo USB audio class 2.0

[aldofranci]

Vi invito però ad essere benevoli con gustavino.

Già l'audiophilo è un mestiere difficile, ma quello del technikikoaudiophilo è veramente ingrato: dover dare spiegazioni technikike per lo più improbabili a fenomeni percettivi per lo più immaginari.

Un lavoraccio.

[ilmisuratore]

12 minuti fa, aldofranci ha scritto:

Vi invito però ad essere benevoli con gustavino.

Già l'audiophilo è un mestiere difficile, ma quello del technikikoaudiophilo è veramente ingrato: dover dare spiegazioni technikike per lo più improbabili a fenomeni percettivi per lo più immaginari.

Un lavoraccio.

Ben ritrovato Aldo, la tua partecipazione ultimamente è stata un pò scarsetta...ma l'importante è che "ci sei" 

 

[Ramsete2]

@ilmisuratore mortacci tua mi è venuto un crampo al dito per scorrere sul tablet tutta la roba che hai copiato.

[ilmisuratore]

Visto che qualcuno mi ha forzatamente (non vorrei sprecare il mio tempo per cose che sapevo) spinto a fare un bel ripasso, per completezza di informazioni aggiungo anche un altra cosa

Le aziende, in modo proprietario (anche dopo il famigerato "2009") e senza il rischio di venire "arrestati" per aver leso "sua maestà  UAC 2.0" potevano benissimo adottare soluzioni proprietarie

Non si tratta affatto di "Diy" ma di prodotti che venivano commercializzati e che in molti abbiamo anche usato

Musiland Audio Labs ad esempio adottava un architettura proprietaria per le sue interfacce USB affinchè potessero funzionare in modo bidirezionale, con la correzione degli errori e il trasferimento di dati in blocco...in soldoni anche Musiland Audio Labs ha utilizzato il protocollo BULK su USB Audio Class 2

Dunque che nessun costruttore lo abbia implementato è una inesattezza, men che meno che tutto venga relegato a chi ha utilizzato il TAS1020

RME fino al 2015 ha implementato la BULK

Musiland Audio Labs, ipotizzo fino al 2012, ha utilizzato la BULK 

Potrebbero anche oggi implementarla, ma non lo fanno per due precisi motivi:

1) lo sviluppo proprietario costa molto alle aziende, spese aggiuntive per un mercato in cui ci si scanna per 1€

2) la tecnologia isocrona/asincrona ha raggiunto un eccellente compromesso di grande affidabilità con il semplice utilizzo di un chippettino XMOS

Se le info che vi sto fornendo sono di vostro gradimento non esitate a mettere un like 

[widemediaphotography]

1 minuto fa, ilmisuratore ha scritto:

Visto che qualcuno mi ha forzatamente (non vorrei sprecare il mio tempo per cose che sapevo) spinto a fare un bel ripasso, per completezza di informazioni aggiungo anche un altra cosa

Le aziende, in modo proprietario (anche dopo il famigerato "2009") e senza il rischio di venire "arrestati" per aver leso "sua maestà  UAC 2.0" potevano benissimo adottare soluzioni proprietarie

Non si tratta affatto di "Diy" ma di prodotti che venivano commercializzati e che in molti abbiamo anche usato

Musiland Audio Labs ad esempio adottava un architettura proprietaria per le sue interfacce USB affinchè potessero funzionare in modo bidirezionale, con la correzione degli errori e il trasferimento di dati in blocco...in soldoni anche Musiland Audio Labs ha utilizzato il protocollo BULK su USB Audio Class 2

Dunque che nessun costruttore lo abbia implementato è una inesattezza, men che meno che tutto venga relegato a chi ha utilizzato il TAS1020

RME fino al 2015 ha implementato la BULK

Musiland Audio Labs, ipotizzo fino al 2012, ha utilizzato la BULK 

Potrebbero anche oggi implementarla, ma non lo fanno per due precisi motivi:

1) lo sviluppo proprietario costa molto alle aziende, spese aggiuntive per un mercato in cui ci si scanna per 1€

2) la tecnologia isocrona/asincrona ha raggiunto un eccellente compromesso di grande affidabilità con il semplice utilizzo di un chippettino XMOS

Se le info che vi sto fornendo sono di vostro gradimento non esitate a mettere un like 

Ma infatti è il driver software specifico, che realizza il costruttore del Device (DAC,) che stabilisce con l'HOST (PC)  in che modalità funzionare, altrimenti a che servirebbero a fare i driver sw che si trovano sulle pagine di supporto dei costruttori di periferiche USB?

[ilmisuratore]

8 minuti fa, widemediaphotography ha scritto:

Ma infatti è il driver software specifico, che realizza il costruttore del Device (DAC,) che stabilisce con l'HOST (PC)  in che modalità funzionare, altrimenti a che servirebbero a fare i driver sw che si trovano sulle pagine di supporto dei costruttori di periferiche USB?

Esatto, sviluppo del driver associato al chipset adatto

Se lo hanno fatto fino al 2015 su USB Audio Class 2.0, oggi lo potrebbero perfettamente rifare

L'ingegnerizzazione costa, e ci sono oggi strade con un "percorso piu veloce" potendo garantire il trasferimento BIT-PERFECT contenendo le spese

Diversamente, se avessero avuto problemi (seri) avrebbero fatto marcia indietro

[widemediaphotography]

28 minuti fa, ilmisuratore ha scritto:

Esatto, sviluppo del driver associato al chipset adatto

Se lo hanno fatto fino al 2015 su USB Audio Class 2.0, oggi lo potrebbero perfettamente rifare

L'ingegnerizzazione costa, e ci sono oggi strade con un "percorso piu veloce" potendo garantire il trasferimento BIT-PERFECT contenendo le spese

Diversamente, se avessero avuto problemi (seri) avrebbero fatto marcia indietro

Proprio perché la pratica, confortata dalle misure, conferma che  se nella remotissima possibilità che si  dovesse perdere un bit durante il trasferimento,  ma non accade mai, con i file audio ciò non comporterebbe nessuna alterazione significativa. Cosa ben diversa se bisogna trasferire un file di altra natura.

[Gustavino]

14 hours ago, ilmisuratore said:

Relativamente al bit-perfect, piu si sale con la frequenza di campionamento e piu si "rischia" di imbattersi in errori

Mi chiedo se gli utilizzatori del DSD (vedi @Gerardo61 e tanti altri) fanno uso del collegamento USB e se con l'utilizzo di frequenze di campionamento altissime avvertono dei clic/pop e/o microinterruzioni nella riproduzione musicale

Questo potrebbe essere un indizio del fatto che, con frequenze altissime scaturisca qualche errore

Se invece la riproduzione risultasse sempre fluida ed esente dai fenomeni citati sopra, vuol dire che alle frequenze inferiori ci farebbe il solletico

Nel pomeriggio ho contattato un ex collega informatico che possiede una RME UC Fireface e che ha svolto anche lui delle prove

Mi assicura che per tutte le frequenze piu alte che possono transitare dalla sua scheda non ci sono errori...anche perchè (ma guarda un pò ) il trasferimento non è nemmeno isocrono ma asincrono BULK...per cui tali errori sarebbero scongiurati

La domenica comincia gioiosa

[ilmisuratore]

1 ora fa, Gustavino ha scritto:

La domenica comincia gioiosa

...si, in effetti 🤣 comincia gioiosissima 

Il solito screenshot decontestualizzato che menziona UN ALTRO MODELLO DI SCHEDA RME 

Ritenta, sarai più (s)fortunato 

[ilmisuratore]

Sai qual è la differenza fondamentale tra me e te Gustavino ?

Che io vivo di cose che ho vissuto, ho toccato con mano, ho sperimentato realmente, ci ho studiato sopra

Tu invece vivi il presente su cose prelevate dal web...queste ti porteranno sfortuna 

Le cose bisogna saperle non cercando invano nelle figurine panini