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

[Gustavino]

4 minutes ago, ilmisuratore said:

Sei uno spasso 

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

quindi ora neghi la bulk ?

[ilmisuratore]

5 minuti fa, Gustavino ha scritto:

quindi ora neghi la bulk ?

Non hai capito allora ???

Te lo dico per l'ultima volta, è "bulk" ma non interviene MAI in quanto viene evitato dal tipo di feedback che regola le trame, i dati non risulteranno MAI corrotti o persi a tal punto da chiedere il reinvio

"Se" ci fosse bisogno il TAS1020 lo prevede

Il disegnino è completo

[widemediaphotography]

6 ore fa, Gustavino ha scritto:

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

Adesso è tutto chiaro! 

Tu non hai ben compreso il concetto di clock e soprattutto confondi Isocronico con Sincrono, che come ho spiegato nei post precedenti, sono due cose completamente differenti!

 

Sincrono è ad esempio la modalità S/PDIF, in cui i 2 clock di Host e Device devono sincronizzarsi, perché il clock dell'Host avviene a velocità variabile  e  nessuno può farci niente! Il DAC deve andarci dietro e svolgere il flusso prima di processarlo. I2s, ad esempio, fa questo processo dal lato HOST, restituendo al DAC Clock e dati separati!

 

Nella modalità Isocronica (in tempo reale, questo significa e niente di più) i dati vengono inviati in pacchetti discreti con la velocità dei frame del bus (12 MHz o 480 MHz), ma la quantità totale di dati inviati è proporzionale alla velocità di campionamento e avviene quindi a velocità costante! Il clock non deve essere sincronizzato, ed è gestito nel Device (DAC) che ha quindi un proprio clock (che lavora a velocità costante) e pertanto viene definita modalità ASINCRONA, proprio perché non deve sincronizzare nessun clock! Chiaro?  Va da se che in questa modalità viene escluso la possibilità di perdita di dati. Chiaro anche questo?

Asincrona che si accosta  ad Isocronico (in tempo reale)  si riferisce alla una modalità in cui è il Device ad avere un proprio clock che ignora sempre  quello del device! Ora ritornando a 12/6MHZ che hai indicato sopra, la domanda è come credi che i dati vengono spinti nel DAC, nella modalità Isocronica...  soffiandoli, ?

[ilmisuratore]

@widemediaphotography

La frase di Gustavino "se sente anche sulla sincrona" in effetti spiega tutto, diciamo spiega quello che non ha ben compreso poichè avrebbe dovuto scrivere "se sente principalmente sulla sincrona" 

Mi sembra ovvio che un ottimo clock "se senta" se implementato su un protocollo sincrono, peraltro disturbato in quanto a pomiciare con tutta una serie di oscillatori che stanno dentro il PC, nonchè i disturbi elettromagnetici e relative interferenze, dunque la qualità del clock per un trasfer sincrono è imprescindibile

Il DAC ricostruisce il clock master secondo la precisione del clock dell'host (PC) per cui il PC è master e il DAC (dipendente dal clock del PC) è slave

[Gustavino]

On 10/27/2024 at 1:39 AM, widemediaphotography said:

Adesso è tutto chiaro! 

Tu non hai ben compreso il concetto di clock e soprattutto confondi Isocronico con Sincrono, che come ho spiegato nei post precedenti, sono due cose completamente differenti!

Sincrono è ad esempio la modalità S/PDIF, in cui i 2 clock di Host e Device devono sincronizzarsi, perché il clock dell'Host avviene a velocità variabile  e  nessuno può farci niente! Il DAC deve andarci dietro e svolgere il flusso prima di processarlo. I2s, ad esempio, fa questo processo dal lato HOST, restituendo al DAC Clock e dati separati!

Nella modalità Isocronica (in tempo reale, questo significa e niente di più) i dati vengono inviati in pacchetti discreti con la velocità dei frame del bus (12 MHz o 480 MHz), ma la quantità totale di dati inviati è proporzionale alla velocità di campionamento e avviene quindi a velocità costante! Il clock non deve essere sincronizzato, ed è gestito nel Device (DAC) che ha quindi un proprio clock (che lavora a velocità costante) e pertanto viene definita modalità ASINCRONA, proprio perché non deve sincronizzare nessun clock! Chiaro?  Va da se che in questa modalità viene escluso la possibilità di perdita di dati. Chiaro anche questo?

Asincrona che si accosta  ad Isocronico (in tempo reale)  si riferisce alla una modalità in cui è il Device ad avere un proprio clock che ignora sempre  quello del device! Ora ritornando a 12/6MHZ che hai indicato sopra, la domanda è come credi che i dati vengono spinti nel DAC, nella modalità Isocronica...  soffiandoli, ?

Ma che davvero    ti rispondo  con il mio post di 8gioni faì che non hai compreso minimamente :
 

Titolo provocatorio ma tecnicamente non lo e' affatto  ,la consegna non e' garantita , USB Audio class non è uno di questi!!!
 

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.

 

 

[Gustavino]

On 10/27/2024 at 8:25 AM, ilmisuratore said:

@widemediaphotography

La frase di Gustavino "se sente anche sulla sincrona" in effetti spiega tutto, diciamo spiega quello che non ha ben compreso poichè avrebbe dovuto scrivere "se sente principalmente sulla sincrona" 

Mi sembra ovvio che un ottimo clock "se senta" se implementato su un protocollo sincrono, peraltro disturbato in quanto a pomiciare con tutta una serie di oscillatori che stanno dentro il PC, nonchè i disturbi elettromagnetici e relative interferenze, dunque la qualità del clock per un trasfer sincrono è imprescindibile

Il DAC ricostruisce il clock master secondo la precisione del clock dell'host (PC) per cui il PC è master e il DAC (dipendente dal clock del PC) è slave

ostia arrivi a dire  il contrario di quello che hai scritto in precedenza dandomi difatto ragione .
allora sti 30euro son stai ben spesi...ne hai messo di tempo per ammetterlo pian pianino un pezzetino alla volta ....

ti do una notizia il chip dac puo essere a sua volta synch o async con il clock della usb ahiahi !!
e qui mi fermo vista l'ora

[widemediaphotography]

18 minuti fa, Gustavino ha scritto:

Ma che davvero    ti rispondo  con il mio post di 8gioni faì che non hai compreso minimamente :
 

Titolo provocatorio ma tecnicamente non lo e' affatto  ,la consegna non e' garantita , USB Audio class non è uno di questi!!!
 

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.

Hai commesso 2 errori:

In tutto il testo che hai appena scritto, che non é farina del tuo sacco, non  si legge mai il termine SINCRONO (da te usato alla parola n.23 del tuo post di sabato alle ore  19:38  ) che tu hai confuso con ISOCRONO. Secondo, non é risposta pertinente al mio post, anche se é  corretta e coerente con quanto da me scritto in precedenza. La correzione errori da quale protocollo alternativo a USB audio é implementata? Serve? I Test e le misure cosa confermano?(Pratica)

Un consiglio... Discerni bene i tuoi interlocutori, io scrivo solo su cose che conosco alle quali  tu reagisci con le risatine, poi il rischio é che con me fai la figura del menga e questo non va bene perché più di una volta ho scritto che ti stimo e tu reagendo con le  risatine... mi fai ricredere .

[widemediaphotography]

@Gustavino Piuttosto vieni in mio soccorso nella sezione Fine Tuning, dove devo implementare una sicurezza per gestire 2 amplificatori con con 2/4 stessi diffusori. Per questo non sono ferrato come sull'audio digitale. 

[Gustavino]

8 hours ago, widemediaphotography said:

Hai commesso 2 errori:

In tutto il testo che hai appena scritto, che non é farina del tuo sacco, non  si legge mai il termine SINCRONO (da te usato alla parola n.23 del tuo post di sabato alle ore  19:38  ) che tu hai confuso con ISOCRONO.

 

-Primo il protocollo internazinale  usb audio class2.0 e' ovvio che non abbia scritto io
-Secondo che tu lo abbia conosciuto grazie a me e' un fatto orami certo !!!
Terzo quello che mi accusi di non conoscere lho pubblicato fin dall inizio il 18
Quarto ravviso uno una mancanza di onesta intellettuale anche da parte tua

 

[ilmisuratore]

10 ore fa, Gustavino ha scritto:

ostia arrivi a dire  il contrario di quello che hai scritto in precedenza dandomi difatto ragione .
allora sti 30euro son stai ben spesi...ne hai messo di tempo per ammetterlo pian pianino un pezzetino alla volta ....

ti do una notizia il chip dac puo essere a sua volta synch o async con il clock della usb ahiahi !!
e qui mi fermo vista l'ora

Non è un'affermazione al contrario sostenere che il clock abbia importanza su un transfer sincrono

È nella sincronizzazione asincrona che il clock lato host non ha influenza perché il DAC non è più slave ma viene cloccato in modo indipendente 

[ilmisuratore]

Gustavino sta sollevamento un polverone su qualcosa che funziona alla perfezione 

Lo sa soltanto lui quale è lo scopo...il suo scopo...

[Ggr]

34 minuti fa, ilmisuratore ha scritto:

sa soltanto lui quale è lo scopo...il suo scopo..

Dovrà disfarsi di qualche ravatto di troppo,  che si c è dimostrato inutile costando un botto 🤣

[Gustavino]

7 hours ago, ilmisuratore said:

Non è un'affermazione al contrario sostenere che il clock abbia importanza su un transfer sincrono

È nella sincronizzazione asincrona che il clock lato host non ha influenza perché il DAC non è più slave ma viene cloccato in modo indipendente 

carpiato triplo, i miei  complimenti

[Gustavino]

7 hours ago, ilmisuratore said:

Gustavino sta sollevamento un polverone su qualcosa che funziona alla perfezione 

Lo sa soltanto lui quale è lo scopo...il suo scopo...

Guarda che son due  discussione contro di me che tu hai aperto , ti si stan rivoltando contro

[widemediaphotography]

@Gustavino Mi sfugge...  cosa avrei compreso grazie a te? E soprattutto dove sarebbe la mia mancanza di onestà intellettuale? 

[ilmisuratore]

4 minuti fa, Gustavino ha scritto:

Guarda che son due  discussione contro di me che tu hai aperto , ti si stan rivoltando contro

Nessun "rivoltamento" in quanto sono state aperte giusto per correggere le tue presunte rivoluzioni, tipo si "perdono dati" o il "clock dell'host è importante" 

Le prove confermano il contrario, dunque saranno rivoltate e cappottate le tue ipotesi

[ilmisuratore]

10 minuti fa, Gustavino ha scritto:

carpiato triplo, i miei  complimenti

Si, io parlo di una cosa e tu capisci tutt'altro

Mi spiace, ma se non riesci non posso farci nulla

[Gustavino]

Just now, ilmisuratore said:

Nessun "rivoltamento" in quanto sono state aperte giusto per correggere le tue presunte rivoluzioni, tipo si "perdono dati" o il "clock dell'host è importante" 

Le prove confermano il contrario, dunque saranno rivoltate e cappottate le tue ipotesi

non puoi stravolgere il protocollo usb che tu non conoscevi essendo rimasto a 15anni fa' con la bulk ed il dato riparato che non esiste ,questi di ho contestato sul bricasti

1 minute ago, ilmisuratore said:

Si, io parlo di una cosa e tu capisci tutt'altro

Mi spiace, ma se non riesci non posso farci nulla

continua a negare quello che scrivi