ilmisuratore Inviato 25 Ottobre 2024 Inviato 25 Ottobre 2024 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" 1
ilmisuratore Inviato 25 Ottobre 2024 Autore Inviato 25 Ottobre 2024 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 Inviato 25 Ottobre 2024 Inviato 25 Ottobre 2024 4 ore di segnale a quanti mb corrispondono? Dipende anche dalla risoluzione del segnale immagino.
ilmisuratore Inviato 25 Ottobre 2024 Autore Inviato 25 Ottobre 2024 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 1
Questo è un messaggio popolare. Ggr Inviato 25 Ottobre 2024 Questo è un messaggio popolare. Inviato 25 Ottobre 2024 Diamo tempo a google di mettere in rete qualcosa.....😉 3
saltato Inviato 26 Ottobre 2024 Inviato 26 Ottobre 2024 E quindi dopo 4 ore abbiamo capito xchè non si perde un bit. 🤐
ilmisuratore Inviato 26 Ottobre 2024 Autore Inviato 26 Ottobre 2024 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 1
Ggr Inviato 26 Ottobre 2024 Inviato 26 Ottobre 2024 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)... 1
Gustavino Inviato 26 Ottobre 2024 Inviato 26 Ottobre 2024 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 .... 1
Questo è un messaggio popolare. widemediaphotography Inviato 26 Ottobre 2024 Questo è un messaggio popolare. Inviato 26 Ottobre 2024 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. 3
ilmisuratore Inviato 26 Ottobre 2024 Autore Inviato 26 Ottobre 2024 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
Questo è un messaggio popolare. maxgazebo Inviato 26 Ottobre 2024 Questo è un messaggio popolare. Inviato 26 Ottobre 2024 @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 3
Gustavino Inviato 26 Ottobre 2024 Inviato 26 Ottobre 2024 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 Inviato 26 Ottobre 2024 Inviato 26 Ottobre 2024 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 26 Ottobre 2024 Inviato 26 Ottobre 2024 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 1
Gustavino Inviato 26 Ottobre 2024 Inviato 26 Ottobre 2024 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 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
ilmisuratore Inviato 26 Ottobre 2024 Autore Inviato 26 Ottobre 2024 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 Ammettere una cosa che si conosce è un traguardo effettivamente da leccarsi i baffi
Messaggi raccomandati