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

[ilmisuratore]

Affinchè si potesse valutare se "a lungo termine" si sarebbe perso qualcosa sull'integrità del codice binario, ho collegato un interfaccia USB asincrona all'uscita del PC e ho acquisito un segnale "tosto" (white noise a basso fattore di cresta) per ben 4 ore di fila  (l'equivalente di 14.400 secondi) 

Il risultato è stato confermato con la perfetta integrità del flusso digitale tra file originale e segnale acquisito

Di seguito il segnale utilizzato e infine la comparazione binaria

la XMOS 208 funziona sinergicamente alla perfezione con il driver a corredo, insomma roba "ordinaria" che non provoca alcun problema nemmeno a "lungo termine"

 

[widemediaphotography]

Ma allora i bit so bit...

 

[ilmisuratore]

7 minuti fa, widemediaphotography ha scritto:

Ma allora i bit so bit...

Non si è perso nulla dopo 4 ore di acquisizione

Non capisco a cosa serve questa sperimentazione futuristica su schede il cui funzionamento non presenta problemi

Sistema operativo + driver + interfaccia USB = bit perfect ed ENOB secondo le specifiche

[one4seven]

4 ore di segnale a quanti mb corrispondono? Dipende anche dalla risoluzione del segnale immagino.

[ilmisuratore]

36 minuti fa, one4seven ha scritto:

4 ore di segnale a quanti mb corrispondono? Dipende anche dalla risoluzione del segnale immagino.

Si, dipende dalla risoluzione (anche)

Ho lasciato collegato il setup dopo ora di pranzo per poi stopparlo dopo 4 ore alla risoluzione di 24bit/44.1khz

La stima è di 1,77 Gb

[Ggr]

Diamo tempo a google di mettere in rete qualcosa.....😉

[saltato]

E quindi dopo 4 ore abbiamo capito xchè non si perde un bit.

🤐

[ilmisuratore]

1 ora fa, saltato ha scritto:

E quindi dopo 4 ore abbiamo capito xchè non si perde un bit.

🤐

...lo scopo non era quello di capire, ma confermare ipotesi sbagliate, tipo: quelle che tali bit si sarebbero persi per strada , magari dopo cinque minuti 

[Ggr]

27 minuti fa, ilmisuratore ha scritto:

quelle che tali bit si sarebbero persi per strada , magari dopo cinque minuti

Che casualmente causerebbe un collassamento della scena, e una peggior separazione tra gli strumenti.

Fateci caso, a parte gustavino che evita da mesi di rispondere sul casa dovremo sentire, la maggior parte delle super uditi, dicono queste cose.

Come se quei bit, fossero diversi da quelli che identificano il canale destro e sinistro,  da quelli che codificato una toni basso, uno acuto, ecc...che casualmente arrivano sempre integri.  Ma sentito di canali invertiti o di toni alto al posto dei bassi... mai sentito un rock, andare a tempo di Walzer e potremo continuare all'infinito... i che si perdono sono sempre quelli,  come se quei bit che codificato sfumature,  fossero più flebili degli altri.... invece di +5 e -5 volts, fossero + 4 e -4...( tra l'altro non cambierebbe nulla)...

[Gustavino]

16 hours ago, Ggr said:

Diamo tempo a google di mettere in rete qualcosa.....😉

Se leggessi quello che ho scritto ,capiresti che il problema era ilmisuratore che non avesse compreso il funzionamento del protocollo che non puo correggere l' eventuale perdita !
l' ovvieta' e'gia nota a nulla serve questo test se non ad intortare ....

[widemediaphotography]

3 minuti fa, Gustavino ha scritto:

Se leggessi quello che ho scritto ,capiresti che il problema era il misuratore che non avessa compreso il funzionamento del protocollo che non puo correggere  eventuale perdita !
l' ovvieta' e'gia nota a nulla serve questo test se non ad intortare ....

La Pratica, quella reale, dimostra che il problema non é mai la perdita dati, perché vengono inviati pacchetti a velocità prestabilita con il protocollo USB isocronico, ma invece  potrebbe essere la sincronizzazione dei clock tra Host e Device.  Nell'Isochronus Transfer che avviene in modalità Asincrona,  il Clock é unico, costante e preciso, ed appartiene al DAC. Qualunque problema che gli audiofili immaginano nell'audio digitale, a partire dagli alimentatori, loop di terra, disturbi di sistema sono affari del DAC. DAC scarso = Risultati  mediocri. Poi stranamente volendo attribuire al DAC compiti che non gli competono, come la "colorazione del suono o l'impronta timbrica", si tende a relegare DAC dalle ottime misure e    assolutamente  Trasparenti, al ruolo di scarsi e senz'anima... Niente di più ridicolo. 

[ilmisuratore]

1 ora fa, Gustavino ha scritto:

era ilmisuratore che non avesse compreso il funzionamento del protocollo che non puo correggere l' eventuale perdita !

Siamo su scherzi a parte ???

L'isocrona non corregge i dati, al massimo ne controlla la ricezione in quanto un CRC esiste

Nell'isocrona non è previsto il reinvio di eventuali dati persi (che di fatto non si perdono)

Nell'asincrona e' previsto l'eventuale reinvio (il chip lo prevede se programmato) ma di fatto non viene mai usato in quanto NON si perdono mai dati grazie al feedback di controllo dei pacchetti del buffer e degli errori di underrun e/o overrun

Spero ti entri in testa per una buona volta, rimuginare ti rende ridicolo 

[maxgazebo]

@Ggr ma si...sarà sempre il problema legato alla cultura analogica, al mondo del continuo, alla nostra mente nata e cresciuta con le sinusoidi subordinate alle modifiche di ampiezza e fase in base alla lunghezza del cavo, alla impedenza offerta, ai disturbi che si concatenano durante il tragitto...concetti completamente fuori luogo, senza alcun senso nel dominio del discreto

Sentir parlare di scena più ampia o maggior dettaglio cambiando un pezzo di cavo USB o cavo CAT è assurdo, per natura intrinseca alla tecnologia digitale...sono discorsi che posso accettare da chi non ha basi tecniche, ma solo romantiche

Per avere queste diversità devo agire sul segnale, cambiarlo, processarlo, comprimerlo, insomma devo cambiare qualcosa, se parte una certa informazione ne deve arrivare un'altra

Se parte ed arriva la stessa informazione parlare di differenze all'ascolto è suggestione e basta

Per me chi fa questo tipo di affermazioni non ha la minima credibilità, non ha facoltà reale di discriminare differenze vere, reali

[Gustavino]

1 hour ago, ilmisuratore said:

Siamo su scherzi a parte ???

L'isocrona non corregge i dati, al massimo ne controlla la ricezione in quanto un CRC esiste

Nell'isocrona non è previsto il reinvio di eventuali dati persi (che di fatto non si perdono)

Nell'asincrona e' previsto l'eventuale reinvio (il chip lo prevede se programmato) ma di fatto non viene mai usato in quanto NON si perdono mai dati grazie al feedback di controllo dei pacchetti del buffer e degli errori di underrun e/o overrun

Spero ti entri in testa per una buona volta, rimuginare ti rende ridicolo 

Bravo finalmente riesci ad ammetterlo !!
complimenti un bel passo avanti dalla Bulk per gli scanner ...non hai neanche citato l'asynch  ,10 e lode

[Gustavino]

3 hours ago, widemediaphotography said:

La Pratica, quella reale, dimostra che il problema non é mai la perdita dati, perché vengono inviati pacchetti a velocità prestabilita con il protocollo USB isocronico, ma invece  potrebbe essere la sincronizzazione dei clock tra Host e Device.  Nell'Isochronus Transfer che avviene in modalità Asincrona,  il Clock é unico, costante e preciso, ed appartiene al DAC.. 

vedo che hai compreso la mia spegazione ,finalmente ,comunque Isochronus era anche sincrono prima dell UABC2