Wtfplay - misurazioni e confronti con players

[marcoc1712]

Dalla JLS puoi tranquillamente uscire in spdif ...senza compromettere nulla ...


La prima scartala ....anche perche non saprei come farla ....acquisisco con una emu 1212 ..per quella prova servirebbe un hardware specifico ...USB to USB da impostare come device su audition ....

Posso acquisire in questo modo (Out) PC -> USB -> SPDIF (IN) -> SPDIF -> PC ...ti sposto le acquisizione dopo ci pensi tu come analizarle ...vanno bene 10 ripetizioni per ogni player ....piu' le due varianti nel buffer solo su wtf ....

Mi basta 1 x + il file originario, voglio solo verificrae la bitperfectness, cioè che il file acquisito sia ESATTAMENTE uguale a quello in ingresso e non per casuali e sporadici errori, ma per interventi sistematici, sono quelli che voglio poter escludere dall'equazione, come ho fatto a suo tempo per SPDIF.

Mi spiego:

File 1 sul server -> ETH -> SB -> SPDIF OUT -> SPDIF IN -> File 2 Su server.

File 1 sempre identico a file 2.

[marcoc1712]

Dalla JLS puoi tranquillamente uscire in spdif ...senza compromettere nulla ...

Sono le mie mani che possono comprometter il lavoro fatto da Giovanni pasticciando clamorosamente con il saldatore... non mi conosci, non sai di che porcate sono capace, purtroppo.

[marcoc1712]

ni... dato che è passato per s/pdif, un errore (nei dati) legato ad una fluttuazione nel clock ci può anche stare....

? senza passare per la conversione AD/DA? come è possibile che il clock cambi i bit nel flusso raw?

Il tutto sempre ammesso e non concesso che si tratti effettivamente di una differenza reale e non banalmente di un artefatto (-300dB sono... nulla, e -282,6dB pure: 0=0).

Cosa più che probabile, probabilmente -300 è il fondo scala. Non fosse che Salvatore dice di sentire la differenza in modo netto, quindi si tratterebbe di una doppia coincidenza. Una veloce verifica e ci togliamo il dubbio.

Sia chiaro, sarei ESTREMAMENTE sorpreso scoprissimo differenze.

[marcoc1712]

Ma il cristallo presente nel PC che partecipa alla preparazione dei pacchetti dati può essere influenzato da vari fattori sia software che hardware

In realtà il clock non partecipa alla preparazione dei pacchetti dati, ma solo al 'ritmo' in cui i cicli di CPU si susseguono, quindi eventualmente a quando vengono preparati ed instradati.

Almeno logicamente, questo non conta nulla, dato che il collegamento è asincrono. Il 'contenuto' del primo clock si perde nel momento in cui i dati vengono iommagazinati nel FIFO, esattamente come si perde quando trasferisci un file dal pc a al pc b e lo registri su disco. Alla successiva lettura, l'unico clock che conta è quello del pc B.

Questo è quello che spesso si confonde. il Jitter di USB NON è direttamente correlabile al JITTER al DAC, che grazie al collegamento asincrono - in teoria - risente solo di quello del CLOCK cui è collegato. Che quest'ultimo sia influenzabile ed influenzato da tutto quanto viene a monte, compreso il flusso di dati su USB, è altamente probabile, ma per quanto ne so, non ci si riferisce alla precisione del clock del pc sorgente, quanto allo 'shape' del trasferimento:

buffer piccoli -> flusso limitato ma costante, buffer grandi/ram disk -> picco iniziale di lavoro, poi silenzio.

Oltre a questo, io ritengo che il circuito analogico ha almeno le stesse probabilità di essere influenzato da questi disturbi 'indiretti' del clock del dac e, misurando attraverso la conversione DA/AD, queste influenze assumono almeno analoga rilevanza.

Detto questo, se stiamo sempre cercando il motivo di quei 30db... difficilmente sono qui.

[SM63]

Sono le mie mani che possono comprometter il lavoro fatto da Giovanni pasticciando clamorosamente con il saldatore... non mi conosci, non sai di che porcate sono capace, purtroppo.

Quando è cosi meglio lasciare stare ...

[SM63]

Mi basta 1 x + il file originario, voglio solo verificrae la bitperfectness, cioè che il file acquisito sia ESATTAMENTE uguale a quello in ingresso e non per casuali e sporadici errori, ma per interventi sistematici, sono quelli che voglio poter escludere dall'equazione, come ho fatto a suo tempo per SPDIF.

Mi spiego:

File 1 sul server -> ETH -> SB -> SPDIF OUT -> SPDIF IN -> File 2 Su server.

File 1 sempre identico a file 2.

Bene entro fine settimana ..procedo ...anche perche ho in mente altre verifiche ...

[marcoc1712]

Bene entro fine settimana ..procedo ...anche perche ho in mente altre verifiche ...

Se ti fa piacere, possiamo progettare un set di verifiche mirato alla verifica di diversi fattori. Oltre a me, che vado ben poco al di la di quello che ho scritto, qui ci sono sicuramente esperti che potrebbero aiutare a definire un protocollo di prova se non esaustivo almeno ben instradato.

Dovremmo inizialmente individuare COSA vogliamo mettere sotto controllo.

Io propongo di iniziare da:

a. Effetto della rete (es. effettuando rilevazioni in WTF con NIC accesa/spenta ed in contemporanea al rtrasferimento di un file. Se ripetendo un numero sufficiente di volte le riprese, dovessimo individuare una 'variazione tipica' della curva, sarebbe già un grosso passo avanti.

b. Effetto del video acceso/spento/scollegato/disabilitato, quindi UI semplice (WTF) UI complessa (foobar).

c. Effetto dell'alimentazione dl pc switching/lineare A/lineare B.

Propongo C come 'prova del 9', credo tutti qui conveniamo sul fatto che tra una switching ed una buona lineare la differenza c'è e si sente. Vediamo se un null test è in grado di individuarla e se le misure di renderla o meno.

[marcoc1712]

Quando è cosi meglio lasciare stare ...

Già, per fortuna ci sono gli amici! Grazie Giovanni!

[campa2]

Ho segnalato questa discussione a Fryderyk.....si e' detto molto interessato a seguirla ma ovviamente fa fatica con la traduzione automatica....(ma pure in italiano.......) se qualcuno che parla bene inglese e che ne capisce della materia volesse fare un riassunto per lui e postarlo qui potremmo avere il suo parere sarebbe interessante.

[SM63]

Se ti fa piacere, possiamo progettare un set di verifiche mirato alla verifica di diversi fattori. Oltre a me, che vado ben poco al di la di quello che ho scritto, qui ci sono sicuramente esperti che potrebbero aiutare a definire un protocollo di prova se non esaustivo almeno ben instradato.

Dovremmo inizialmente individuare COSA vogliamo mettere sotto controllo.

Io propongo di iniziare da:

a. Effetto della rete (es. effettuando rilevazioni in WTF con NIC accesa/spenta ed in contemporanea al rtrasferimento di un file. Se ripetendo un numero sufficiente di volte le riprese, dovessimo individuare una 'variazione tipica' della curva, sarebbe già un grosso passo avanti.

b. Effetto del video acceso/spento/scollegato/disabilitato, quindi UI semplice (WTF) UI complessa (foobar).

c. Effetto dell'alimentazione dl pc switching/lineare A/lineare B.

Propongo C come 'prova del 9', credo tutti qui conveniamo sul fatto che tra una switching ed una buona lineare la differenza c'è e si sente. Vediamo se un null test è in grado di individuarla e se le misure di renderla o meno.

Perfetto ....per me possimo iniziare ....definiamo un protocollo ...