Vai al contenuto
Melius Club

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


Messaggi raccomandati

Inviato

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"

 

acquisizione-14400.png

acquisizione-14400-2.png

acquisizione-vs-originale.png

  • Thanks 1
widemediaphotography
Inviato

Ma allora i bit so bit...:classic_ohmy:

 

  • Haha 1
Inviato
7 minuti fa, widemediaphotography ha scritto:

Ma allora i bit so bit...:classic_ohmy:

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

Inviato

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

Inviato
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

  • Thanks 1
Inviato

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

🤐

Inviato
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 :classic_biggrin:

  • Haha 1
Inviato
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)...

  • Melius 1
Inviato
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 ....

Screenshot 2024-10-26 at 14-40-10 USB Audio Class non e' bit perfect !.png

  • Haha 1
Inviato
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 :classic_smile:

Inviato
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 :classic_smile:

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

Inviato
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

widemediaphotography
Inviato
46 minuti fa, Gustavino ha scritto:

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

E da quando non l'avrei compresa? Tu mi ha bombardato di schede con in cui mi mostravi oscillatori ed io ti ho mostrato che il pinout USB 2.0  non prevede clock conduttori di clock. Il Clock rimane quello del DAC, perché il protocollo, per quanto isocrono ( in tempo reale e senza correzione, ma con possibilità di verifica di errori) avviene in modalità Asincrona in cui il Clock è esclusivo del DAC. Questo è il punto ch fa cadere le tue convinzioni sull'audio USB che avviene per trasferimento di esclusivo di Dati e quindi bit, a differenza di S/PDif che è dipendente dalle sincronizzazioni dei clock. Poi nella pratica anche Spdif la consideriamo a bit perfect ( lo dimostrano le misure e le comparazioni dei WAV acquisiti. Bada bene, ti stai dando la zappa sui piedi, perché se aggiungi altro viene fuori che nelle trasmissioni di dati sono indipendenti dalla tipologia di alimentazioni che poco incidono sui disturbi di sistema, nulla è possibile per o loop di terra.

 

Ti rinnovo la mia stima :classic_smile:

  • Melius 1
Inviato
12 minutes ago, widemediaphotography said:

E da quando non l'avrei compresa? Tu mi ha bombardato di schede con in cui mi mostravi oscillatori ed io ti ho mostrato che il pinout USB 2.0  non prevede clock conduttori di clock. Il Clock rimane quello del DAC, perché il protocollo, per quanto isocrono ( in tempo reale e senza correzione, ma con possibilità di verifica di errori) avviene in modalità Asincrona in cui il Clock è esclusivo del DAC. Questo è il punto ch fa cadere le tue convinzioni sull'audio USB che avviene per trasferimento di esclusivo di Dati e quindi bit, .....i..... Bada bene, ti stai dando la zappa sui piedi, perché se aggiungi altro viene fuori che nelle trasmissioni di dati sono indipendenti dalla tipologia di alimentazioni che poco incidono sui disturbi di sistema, nulla è possibile per o loop di terra.

Ti rinnovo la mia stima :classic_smile:

non risco a comprendere cosa stai dicendo !
-tu nulla mi hai mostrato
-il clock 6/12Mhz del phy e' sempre lo stesso tra sincrono ed asincrono non cambia nulla solo che comanda quello del dac e puoi metterlo migliore Ma se sente anche sulla sincrona fatto da me nella usb costruita nel 2006  
-usb audio e' un flusso dati in realtime non e' un UsbHD per capirci ecco peche "flusso audio"
-nella usb per generare le frequenze DEVI  mettere dei buoni clock 22/24Mhz o 2x e non il ppl

Inviato
1 ora fa, Gustavino ha scritto:

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

Sei uno spasso :classic_biggrin:

Ammettere una cosa che si conosce è un traguardo effettivamente da leccarsi i baffi :classic_biggrin:

Ospite
Questa discussione è chiusa.

  • Notizie

  • Badge Recenti

    • Contenuti Utili
      Capotasto
      Capotasto ha ottenuto un badge
      Contenuti Utili
    • Contenuti Utili
      fabio76
      fabio76 ha ottenuto un badge
      Contenuti Utili
    • Ottimi Contenuti
      landi34
      landi34 ha ottenuto un badge
      Ottimi Contenuti
    • Badge del Vinile Verde
      landi34
      landi34 ha ottenuto un badge
      Badge del Vinile Verde
    • Membro Attivo
      thewall
      thewall ha ottenuto un badge
      Membro Attivo
×
×
  • Crea Nuovo...