Wtfplay - misurazioni e confronti con players

[SM63]

Si, la differenza tra diversi player nellordine di +/- 2db a -86 db (a 40Khz) mi pare assolutamente in linea con le capacità dei due dac e certo le differnze ci sono, è un dato di fatto che non metto minimamente in dubbio.

In quei 4db c'è sicuramente la differenza di suono tra i diversi players, il problema è capire da cosa è causata e mediante quale correlazione. Come hai detto tu stesso, il valore in assoluto più basso lo ha squeezelite, che guarda caso è l'unico headless. Ricordo che stiamo misurando un 'null'. Considera poi che di mezzo c'è uno stadio analogico con i suoi bei componenti attivi e passivi. Bisognerebbe circoscrivere bene il caso ed andare a misurare i singoli effetti, ma la 'sensibilità' degli strumenti temo sia al limite.

In uno stream stereo (ma anche multicanale) i canali viaggiano insieme, entrambi in una stessa 'frame', non si pone il problema di latenza diversa, l'unico effetto è uno shift temporale COMUNE, che si può influire sulla fase e per questo ha effetto molto maggiore alle alte frequenze che non alle basse. v. il link che ho postato, come evidenziano le tue stesse misure, ma è 'artificialmente' introdotta dalla presenza dei due clock nel processo DA/AD, nella 'realtà' il riferimento sarebbe solo il clock del ADC usato in ripresa ed - analogamente - tra questo ed il tempo 'vero', entrambi inconoscibili e perduti irrimediabilmente.

Diverso è in fase di acquisizione e missaggio, in qual caso gli stream sono diversi per canale ed il problema della latenza è viceversa FONDAMENTALE, moivo per cui si usa necessariamente un master clock.

Lo farei io, ma non ho la possibilita con USB, solo SPDIF. Riesci per cortesia a fare l'acquisizione via USB del segnale digitale (senza passare per la conversione AD e DA) transitato dall'interfaccia USB?

Vorrei verificare che in tuttii casi il segnale mantenga la bit perfectness. Quanto hai riportato nel primo set di misure, ottenuto semplicemente cambiando le dimensioni del buffer alsa mi insospettisce. La valenza di questo test è che elimina dal gioco la componente analogica ed i clock (che come dice Paolo, sono loro stessi analogici).

Grazie.

Se ho compreso bene mi chiedi di acquisire nuovamente in questo modo dac USB out spdif rientro nella scheda in spdif ...giusto ..?

Con il palyer wtf in due modalita buffer settato 1024 e 8192 ...

[marcoc1712]

Se ho compreso bene mi chiedi di acquisire nuovamente in questo modo dac USB out spdif rientro nella scheda in spdif ...giusto ..?

Con il palyer wtf in due modalita buffer settato 1024 e 8192 ...

In realtà io vorrei provare questo:

PC -> USB -> USB -> PC

evitando il passaggio a SPDIF, ma dato che sono ragionevolmente certo che quello non produce perdite, va bene anche:

PC -> USB -> SPDIF -> USB -> PC

Se riesci farei la prova per tutti i player + i due casi di WTFPLAY con buffer diversi.

p.s.

Al di la dei tracciati, mi interessa il confronto binario, sapere se i flies acquisiti sono ESATTAMENTE identici o meno.

p. p.s.

ripensandoci, Roger mi aveva detto che è possibile uscire in SPDIF dalla JLSOUND, potrei provare ad uscire di li e rientrare nella IO2, realizzando esattamente quel collegamento. Ho solo paura di compromettere il lavoro di Giovanni, con le mani sono una capra handicappata!

Vedo di organizzare, se nel frattempo riesci tu, ... ti ringrazio,.

[UnixMan]

b. Come ripeto da un bel po, chi suona in primis è ALSA, tant'è che al variare dei suoi parametri avvertite differenze

Ovviamente. Nonché lo stack USB, e tutto quanto influisce sul "ritmo" del flusso di dati verso il DAC.

(e riportate anche che non sono bit perfect).

Uh? Chi? Cosa? Dove, come, quando, perché?!

Se i due clock sono indipendenti, stai misurando la somma algebrica dei due drift.

il concetto è quello, ma temo che il modo in cui gli effetti si combinano sia "un filo" più complesso di una banale somma algebrica... specie se teniamo conto del jitter "istantaneo" e non solo dei "drift" medi.

Se lo stesso hw, nelle stesse condizioni ambientali produce differenze più sensibili tra una riproduzione e l'altra usando SOLO player software diversi ma verificati 'bit perfect' in digitale, allora è evidente che le variazioni si originano nel (nei) dac e con ogni probabilità nel (nei) clock per via assolutamente indiretta.

...che mi pare l'unica spiegazione plausibile.

Se questa differenza è solo o preminentemente dovuta al drift del (dei) clock ed è costante nel breve periodo è ininfluente all'ascolto ed eliminabile mediante un semplice algoritmo matematico, altrimenti si 'fissa' nel contenuto in bit del segnale riacquisito, originando una differenza di contenuto vera e prorpia.

che è esattamente l'effetto causato dal jitter... sia alla sorgente (ADC in ripresa) che alla "destinazione" (DAC in riproduzione).

Più allarmante è la differenza in puro ambito digitale originata dalla modifica dei parametri di ALSA.

di nuovo: ma siete sicuri!? dove/come/quando è stato verificato?

Cioè, ho sempre notato delle differenze ben percepibili tra le varie combinazioni OS/Player che in teoria non ci sarebbero dovute essere; intendo dire che in teoria con l'USB (che ho sempre odiato) il pc manifesta una intenzione di trasmettere dati che vengono poi regolati dall'usb del dac ... A parità di hardware Pc-DAC, questo dialogo fatto salvo l'eventuale esaurimento dei dati nei buffers, dovrebbe fornire risultati identici.

di più. I risultati dovrebbero essere identici semplicemente a parità di DAC, a prescindere dal computer.

Ed invece ho sempre notato differenze ascoltabili,

non solo tu... ed anche tra diversi cavi USB a parità di tutto il resto ("mistero" ancora più grande).

Ma non potrebbe essere che WTF, non "congestiona" i buffers ma mantiene un flusso dati con una specie di shaper verso il DAC, cioè non fa intervenire meccanismi di gestione interna dei pacchetti da parte dell'hardware ?

che "non faccia intervenire i meccanismi hardware" è impossibile (problemi di sincronizzazione tra clock).

Però è indubbio che, cambiando le dimensioni dei buffer ed una infinità di altri parametri vari, in qualche modo cambia anche l'andamento del flusso di dati sul bus USB. E questo non solo per WTF ma per qualsiasi combinazione di software diversi (OS incluso).

Non si può quindi escludere che l'autore di WTF abbia in qualche modo "indovinato" un modo per "ottimizzare" tale flusso.

Questa è la vera domanda! In teoria solo la temperatura, in pratica.. chissà.

uh? Perché mai solo la temperatura? Ci sono letteramente una infinità di parametri che hanno influenza sugli oscillatori di clock (ed ancora di più sul jitter finale).

La temperatura più che altro ha effetti sensibili sul "drift", cioè sulla frequenza "media" (stabilità a lungo termine). Viceversa, le piccole fluttuazioni istantanee (cioè il jitter, che è quello che ci da fastidio) dipendono soprattutto da altri fattori. Senza dimenticare le vibrazioni meccaniche, cui i cristalli sono sensibilissimi (un quarzo è un oscillatore elettromeccanico), in questo caso al primo posto tra i sospettati metterei la "pulizia" di masse ed alimentazioni, sia dell'oscillatore che del DAC stesso!

Essendo un segnale analogico chi lo puo' disturbare?

Eh?! I segnali analogici sono suscettibili a tutti i disturbi possibili e immaginabili!

L'unica cosa che ho puntualizzato è che i 30db sono troppi per essere dovuti a disturbi, la spiegazione più semplice è che siano dovuti a latenza (delay), quindi 'fittizi' presenti solo perchè si confranto gli effetti di due clock non sincronizzati 'staticizzati' nei bit.

penso proprio anche io...

[marcoc1712]

Uh? Chi? Cosa? Dove, come, quando, perché?!
di nuovo: ma siete sicuri!? dove/come/quando è stato verificato?

....acquisendo in digitale ...in questo modo

Riproduzione ......Player >PC >Xmox USB (JLS) >OUT spdif -----IN spdif >PC > software (Audition) ....per tutti i player questo risultato non puo essere rappresentato con la grafica visto la quasi totale cancellazione ...pero ritengo interessante farvi vedere il risultato dei log ...come potete asservare la massima cancellazioe porta un limite fermandosi a 300 dB escluso un caso ....

Player Foobar ....parameters: -5,677msec, 0,000dB.Corr Depth: 300,0 dB

Player WTF ( Condizione A). parameters: -251,5msec, 0,000dB.Corr Depth: 282,6 dB

Player WTF ( Condizione B) parameters: -531,3usec, 0,000dB.Corr Depth: 300,0 dB

La differenza deriva dalla impostazione del Player WTF precisamente

Per la condizione A ..ho impostato F a 8192 per la B ....F 1024 ...

Qui i clock non hanno dominio, non c'è conversione AD e DA, quindi la differenza o è nei bit o non è. Ho chiesto di verificare.

uh? Perché mai solo la temperatura? Ci sono letteramente una infinità di parametri che hanno influenza sugli oscillatori di clock (ed ancora di più sul jitter finale).

parlando di drift, la temperatura (e la dilatazione che ne consegue) mi risulta sia la principale causa, tant'è che si mettono in case a 'forno' per stabilizarli e se ne consiglia l'accensione 24/7.

Il resto è probabile, ma non mi pare universalmente accettato, può originare i 30 db di differenza? non credo. Comunque, magari si riuscisse a stabilire una correlazione precisa con i 'mezzi' e ancor più con le cause. Purtroppo, sebbene la temperatura sia un 'mezzo' certo, non credo sia possibile stabilire un rapporto di causa con nessun aspetto del software in uso, magari è possibile per gli altri aspetti.

Non si può quindi escludere che l'autore di WTF abbia in qualche modo "indovinato" un modo per "ottimizzare" tale flusso.

Certo, ma nemmeno Triode in squeezelòite o chissà chi in foobar, ...come ne misuri l'effetto? Io continuo solo a dubitare della a correlazione di questi aspetti coni 30 db di diffrerenza, di certo non sono dovuti a differenze di flusso in USB...

[UnixMan]

Qui i clock non hanno dominio, non c'è conversione AD e DA, quindi la differenza o è nei bit o non è. Ho chiesto di verificare.

ni... dato che è passato per s/pdif, un errore (nei dati) legato ad una fluttuazione nel clock ci può anche stare. Specie se il ricevitore è uno di quelli moderni, che usano ASRC. Oppure potrebbe anche essersi verificato un "underrun", sebbene in tal caso mi aspetterei differenze molto maggiori. 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).

parlando di drift, la temperatura (e la dilatazione che ne consegue) mi risulta sia la principale causa, tant'è che si mettono in case a 'forno' per stabilizarli e se ne consiglia l'accensione 24/7.

se parliamo solo di drift (cioè di fluttuazioni "lente") senz'altro. Ma, dal punto di vista degli effetti (quanto meno potenzialmente) "udibili", il drift di un cristallo di quarzo è sostanzialmente irrilevante.

Quello che invece conta (anche e soprattutto dal punto di vista degli effetti udibili, ma probabilmente anche per queste misure) sono le fluttuazioni "veloci" (molto veloci!), cioè il jitter.

Le variazioni di temperatura del cristallo sono troppo lente per avere una influenza diretta in tal senso. Al più ci può stare un aumento del jitter al crescere della temperatura per questioni di rumore (agitazione termica).

Ma, in ogni caso, come giustamente dici non c'è alcun modo in cui un software sul PC possa influenzare la temperatura del cristallo dell'oscillatore di clock del DAC: un cosa del genere quindi è semplicemente fuori questione.

Il resto è probabile, ma non mi pare universalmente accettato, può originare i 30 db di differenza? non credo.

neanche per sogno, infatti. Come giustamente dicevi, quei 30dB di "differenza" verosimilmente non sono altro che latenza o qualcosa del genere... in ogni caso qualcosa di completamente irrilevante.

Non fosse altro perché 30dB sono un'enormità: se veramente ci fossero differenze di simile entità tra un player e l'altro, all'ascolto ci sarebbe ben altro che piccole differenze: uno dei due sarebbe completamente... "rotto"!

Comunque, magari si riuscisse a stabilire una correlazione precisa con i 'mezzi' e ancor più con le cause. Purtroppo, sebbene la temperatura sia un 'mezzo' certo, non credo sia possibile stabilire un rapporto di causa con nessun aspetto del software in uso, magari è possibile per gli altri aspetti.

è appunto quello che dicevo: masse, alimentazioni, layout (del DAC e dei relativi clock), ecc.

Come suggeriva anche John Swenson, l'elaborazione del flusso di dati in arrivo dal bus USB (o da qualsiasi altra fonte) causa delle correnti che circolano nel loop di alimentazione / massa di tutti i circuiti interessati. Correnti che, essendo frutto delle commutazioni dettate dal segnale in arrivo, sono strettamente correlate a questo.

Attraverso una infinità di possibili accoppiamenti "parassiti", praticamente impossibili da eliminare completamente (accoppiamenti capacitivi e/o induttivi tra conduttori vicini, impedenza non nulla di collegamenti ed alimentatori, "reazioni" degli stessi regolatori alle variazioni di corrente, ecc) è molto probabile -per non dire certo- che questi "disturbi" (che sono una sorta di "copia" del segnale digitale in ingresso, nella fattispecie del traffico sul bus USB) arrivino in qualche modo ai clock, al DAC e/o anche direttamente ai circuiti analogici di uscita.

Ecco quindi che ciò che accade sul bus USB (e quindi indirettamente anche ciò che accade a monte, nel PC) può avere un qualche effetto (piccolo, indiretto e non banalmente determinabile, ma evidentemente "sensibile") sul "prodotto finale", cioè sul nostro beneamato segnale analogico in uscita dal DAC.

Senza contare poi il singolo chip -l'Xmos- che da una parte si occupa di gestire il flusso di dati sul bus USB e dall'altra sputa fuori il flusso I²S sincrono che va a pilotare il DAC. È a dir poco probabile che il jitter di tale segnale I²S sia fortemente correlato a quanto accade sul bus USB (da questo punto di vista nutro una qualche -piccola- speranza sulla nuova interfaccia Xmos, che utilizza due "core" separati e per così dire "indipendenti" per le due funzioni).

[bibo01]

Ho aperto un nuovo thread per le misure di Wtfplay

[bigtube]

ni... dato che è passato per s/pdif, un errore (nei dati) legato ad una fluttuazione nel clock ci può anche stare. Specie se il ricevitore è uno di quelli moderni, che usano ASRC. Oppure potrebbe anche essersi verificato un "underrun", sebbene in tal caso mi aspetterei differenze molto maggiori. 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).


se parliamo solo di drift (cioè di fluttuazioni "lente") senz'altro. Ma, dal punto di vista degli effetti (quanto meno potenzialmente) "udibili", il drift di un cristallo di quarzo è sostanzialmente irrilevante.

Quello che invece conta (anche e soprattutto dal punto di vista degli effetti udibili, ma probabilmente anche per queste misure) sono le fluttuazioni "veloci" (molto veloci!), cioè il jitter.

Le variazioni di temperatura del cristallo sono troppo lente per avere una influenza diretta in tal senso. Al più ci può stare un aumento del jitter al crescere della temperatura per questioni di rumore (agitazione termica).

Ma, in ogni caso, come giustamente dici non c'è alcun modo in cui un software sul PC possa influenzare la temperatura del cristallo dell'oscillatore di clock del DAC: un cosa del genere quindi è semplicemente fuori questione.


neanche per sogno, infatti. Come giustamente dicevi, quei 30dB di "differenza" verosimilmente non sono altro che latenza o qualcosa del genere... in ogni caso qualcosa di completamente irrilevante.

Non fosse altro perché 30dB sono un'enormità: se veramente ci fossero differenze di simile entità tra un player e l'altro, all'ascolto ci sarebbe ben altro che piccole differenze: uno dei due sarebbe completamente... "rotto"!


è appunto quello che dicevo: masse, alimentazioni, layout (del DAC e dei relativi clock), ecc.

Come suggeriva anche John Swenson, l'elaborazione del flusso di dati in arrivo dal bus USB (o da qualsiasi altra fonte) causa delle correnti che circolano nel loop di alimentazione / massa di tutti i circuiti interessati. Correnti che, essendo frutto delle commutazioni dettate dal segnale in arrivo, sono strettamente correlate a questo.

Attraverso una infinità di possibili accoppiamenti "parassiti", praticamente impossibili da eliminare completamente (accoppiamenti capacitivi e/o induttivi tra conduttori vicini, impedenza non nulla di collegamenti ed alimentatori, "reazioni" degli stessi regolatori alle variazioni di corrente, ecc) è molto probabile -per non dire certo- che questi "disturbi" (che sono una sorta di "copia" del segnale digitale in ingresso, nella fattispecie del traffico sul bus USB) arrivino in qualche modo ai clock, al DAC e/o anche direttamente ai circuiti analogici di uscita.

Ecco quindi che ciò che accade sul bus USB (e quindi indirettamente anche ciò che accade a monte, nel PC) può avere un qualche effetto (piccolo, indiretto e non banalmente determinabile, ma evidentemente "sensibile") sul "prodotto finale", cioè sul nostro beneamato segnale analogico in uscita dal DAC.

Senza contare poi il singolo chip -l'Xmos- che da una parte si occupa di gestire il flusso di dati sul bus USB e dall'altra sputa fuori il flusso I²S sincrono che va a pilotare il DAC. È a dir poco probabile che il jitter di tale segnale I²S sia fortemente correlato a quanto accade sul bus USB (da questo punto di vista nutro una qualche -piccola- speranza sulla nuova interfaccia Xmos, che utilizza due "core" separati e per così dire "indipendenti" per le due funzioni).

Paolo parli di qualcosa che avviene nello stesso modo qualunque sia il player in azione. Non spiega perchè uno appare percettivamente piu "autentico". Secondo me il jitter non spiega niente.
cosa accade quando il kernel è impegnato in troppo lunghe discussioni fra CPU, blocco USB e software? il kernel deve interpretare e coordinare.
Ce la fa' nel tempo giusto? e se anche ce la fa' tutto questo va' e vieni, se fosse semplicemente eccedente una certa soglia, non introduce correnti di addizione o
sottrazione tali da inficiare il lavoro del clock?

[bibo01]

...

se parliamo solo di drift (cioè di fluttuazioni "lente") senz'altro. Ma, dal punto di vista degli effetti (quanto meno potenzialmente) "udibili", il drift di un cristallo di quarzo è sostanzialmente irrilevante.

Quello che invece conta (anche e soprattutto dal punto di vista degli effetti udibili, ma probabilmente anche per queste misure) sono le fluttuazioni "veloci" (molto veloci!), cioè il jitter.

Le variazioni di temperatura del cristallo sono troppo lente per avere una influenza diretta in tal senso. Al più ci può stare un aumento del jitter al crescere della temperatura per questioni di rumore (agitazione termica).

Ma, in ogni caso, come giustamente dici non c'è alcun modo in cui un software sul PC possa influenzare la temperatura del cristallo dell'oscillatore di clock del DAC: un cosa del genere quindi è semplicemente fuori questione.

....

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

[antonellocaroli]

Da completo ignorante in materia credo che il punto sia questo:

Non si può quindi escludere che l'autore di WTF abbia in qualche modo "indovinato" un modo per "ottimizzare" tale flusso

Perché l´autore di wtf ha fatto diverse versioni? corei7 e core2? presumibilmente ha compilato player e librerie e kernel per comunicare e eseguire le operazioni seguendo delle specifiche istruzioni(CPU)...quindi non é solo ottimizzazione software, SO e kernel, ma ne esce fuori anche una comunicazione con l´hardware ottimizzata. Praticamente un flusso piú veloce e con minori operazioni, praticamente anziché prendere una strada provinciale prende una bella Autostrada a tre corsie stando costantemente nella corsia di sorpasso (ipotesi).
e in un certo senso questo lo si ascolta. al di la delle misure!

Escludendo le misure, il confronto all´ascolto con Daphile é completamente indegno per questo "player" !!!

diciamo che con il mio sistema winsever(ottimizzato pesantemente)+Squeezelite-R2+piú qualche altro accrocchio software(sempre sul player) +LMS in qualche occasione gli posso stare un pochino dietro...ma non lo raggiungo ...certo a comoditá lo supero abbondantemente

[SM63]

In realtà io vorrei provare questo:

PC -> USB -> USB -> PC

evitando il passaggio a SPDIF, ma dato che sono ragionevolmente certo che quello non produce perdite, va bene anche:

PC -> USB -> SPDIF -> USB -> PC

Se riesci farei la prova per tutti i player + i due casi di WTFPLAY con buffer diversi.

p.s.

Al di la dei tracciati, mi interessa il confronto binario, sapere se i flies acquisiti sono ESATTAMENTE identici o meno.

p. p.s.

ripensandoci, Roger mi aveva detto che è possibile uscire in SPDIF dalla JLSOUND, potrei provare ad uscire di li e rientrare nella IO2, realizzando esattamente quel collegamento. Ho solo paura di compromettere il lavoro di Giovanni, con le mani sono una capra handicappata!

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 ....