Wtfplay - misurazioni e confronti con players

[marcoc1712]

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

Le prime verifiche in ambito digitale te le ho già richieste, spero ci permetteranno di smarcare un punto cruciale, confermando che diverse impostazioni di ALSA/USB non rompono il bit perfect e che quindi le differenze nel suono percepite rientrano in quelle causate per via indiretta. Lo stesso si potrebbe fare in windows usando i diversi drivers ed impostazioni.

Se qualcuno ha idee migliori di come condurre questa prova, si faccia avanti, credo che sia l'unica dalla quale potersi aspettare risultati concreti.

Stabilito questo, propongo di concentrarsi su un solo player (o su uno per volta) e verificare l'effetto delle diverse impostazioni/condizioni, reali o simulate alla bisogna. Ripropongo:

a. Rete
b. grafica
c. alimentazione

nell'ordine che si preferisce.

Se dovessero uscire risultati interessanti, potremmo quindi scendere a verifiche di maggiore dettaglio, oltre a cercare (ma qui io mi fermo) la correlazione tra cause ed effetto e magari individuare contromisure più mirate.


EDIT: Se usiamo LMS + squeezelite invece di/oltre a Daphile, ho il modo di 'mettere le mani in pasta' per realizzare prove più mirate.

[SM63]

Le prime verifiche in ambito digitale te le ho già richieste, spero ci permetteranno di smarcare un punto cruciale, confermando che diverse impostazioni di ALSA/USB non rompono il bit perfect e che quindi le differenze nel suono percepite rientrano in quelle causate per via indiretta. Lo stesso si potrebbe fare in windows usando i diversi drivers ed impostazioni.

Se qualcuno ha idee migliori di come condurre questa prova, si faccia avanti, credo che sia l'unica dalla quale potersi aspettare risultati concreti.

Stabilito questo, propongo di concentrarsi su un solo player (o su uno per volta) e verificare l'effetto delle diverse impostazioni/condizioni, reali o simulate alla bisogna. Ripropongo:

a. Rete
b. grafica
c. alimentazione


Bene ..visto che l'autore del player ci sta seguendo ...intano l'invito a partecipare ....


Chiedendo alcune informazioni ....esattamente cosa puo cambiare al bit perfect nella modalita' UWTF o WTF riproducendo un file in PCM ...

Se dovessero uscire risultati interessanti, potremmo quindi scendere a verifiche di maggiore dettaglio, oltre a cercare (ma qui io mi fermo) la correlazione tra cause ed effetto e magari individuare contromisure più mirate.


EDIT: Se usiamo LMS + squeezelite invece di/oltre a Daphile, ho il modo di 'mettere le mani in pasta' per realizzare prove più mirate.

Bene ...inizieremo con questa prima verifica


PS : visto che l'autore del player ci sta seguendo ...intano l'invito a partecipare ....


Chiedo alcune informazioni ....esattamente cosa puo cambiare al bit perfect nella modalita' UWTF o WTF riproducendo un file in PCM ...

[marcoc1712]

Bene ...inizieremo con questa prima verifica


PS : visto che l'autore del player ci sta seguendo ...intano l'invito a partecipare ....


Chiedo alcune informazioni ....esattamente cosa puo cambiare al bit perfect nella modalita' UWTF o WTF riproducendo un file in PCM ...

Ottimo, mi aggiungo all'invito! Se poi decidesse di condividere con noi qualche 'segreto'...

[gefrusti]

Buonasera a tutti...nonostante tutti gli impegni (lavoro e battaglia con alcune teste di rapa...certi audiofili) mi sono registrato per contribuire a dare qualche risposta su alcuni dubbi sollevati.
Qui trovo degli amici...che conosco (bibo01, sm63, campa2, ipoci e qualche altro che al momento non ricordo) sperando che venga considerato amico anche da quelli con cui non ci conosciamo.
Vado direttamente al punto...è stato chiesto di spiegare il perchè la NTD mostrasse difformità di ampiezza (su graph FFT nel dominio della frequenza) di parecchi db.
Ebbene...come ampiamente spiegato nel link di MarioBon la NTD non è una misura -assoluta- ma relativa...quindi dimentichiamoci a priori eventuali correlazioni matematiche (come per i segnali sinusoidali e test convenzionali) tra differenza e valore reale.
Se per ipotesi rilevassimo due volte consecutive lo stesso segnale analogico e li confrontassimo su NTD...risulterebbe un segnale "azzerato" e con il solo livello del rumore termico (noise floor).
Se ad uno dei due segnali applicassimo una variazione di 0.1db a 1khz e li riconfrontassimo...risulterebbe un evidentissimo picco di ben 50db (circa) perfettamente centrato a 1khz...quindi si passerebbe dal rumore termico al rumore di quantizzazione (circa 90/95db)
Questo per far capire che la NTD va vista come una "gara tra automobili in pista"...ovvero adatta a fornire un indicazione su chi sta davanti//indietro...ma al contempo senza riferimenti di velocità e distanza (in metri...o centimetri) tra le vetture.
La NTD serve per rilevare una "differenza"...chi piu...chi meno...
E' lo "scotto" che si paga per quando si effettuano test in condizioni di funzionamento effettivo e con segnali complessi (quale il pink noise o musicali)...diversamente con misure convenzionali non si vedrebbe nulla.
Salvatore ha voluto creare due variabili (correzione off e on dell'errore di sample rate) ma non era nemmeno necessario poichè sarebbe bastato il confronto sulla ripetizione dei vari segmenti...che in caso di stabilità del clock avrebbero dovuto fornire un errore trascurabilissimo visto che ci troviamo in presenza di sola ripetizione dello stesso brano ed errore di clock noto (quello del "primo aggancio")
Su un protocollo Bifase mark code (tipo il mio) la ripetizione dei vari segmenti fornisce l'assenza di errori...risulta sempre 0,0000ppm...anche se ripetessi per 100 volte.
Dac come gli MSB Analog (ingresso USB quad) non ripetono lo stesso segnale analogico...come nell'esempio mostrato da Salvatore con i vari player...come dire ogni qualvolta si riproduce un brano...questo risulta diverso dall'altro.
Pare che con WTF si acuisca la costanza...e costanza significa meno errore e piu stabilità (ripetibilità)
Al momento non posso puntare direttamente il dito sulle cause...ma vi seguirò.
Se mi viene qualcosa in mente lo scriverò con piacere.

saluti a tutti.

Tom.

[SM63]

Ciao Tom ...ben venuto

Intanto grazie per il tuo contributo ....

[marcoc1712]

Buonasera a tutti...nonostante tutti gli impegni (lavoro e battaglia con alcune teste di rapa...certi audiofili) mi sono registrato per contribuire a dare qualche risposta su alcuni dubbi sollevati.
Qui trovo degli amici...che conosco (bibo01, sm63, campa2, ipoci e qualche altro che al momento non ricordo) sperando che venga considerato amico anche da quelli con cui non ci conosciamo.
Vado direttamente al punto...è stato chiesto di spiegare il perchè la NTD mostrasse difformità di ampiezza (su graph FFT nel dominio della frequenza) di parecchi db.
Ebbene...come ampiamente spiegato nel link di MarioBon la NTD non è una misura -assoluta- ma relativa...quindi dimentichiamoci a priori eventuali correlazioni matematiche (come per i segnali sinusoidali e test convenzionali) tra differenza e valore reale.
Se per ipotesi rilevassimo due volte consecutive lo stesso segnale analogico e li confrontassimo su NTD...risulterebbe un segnale "azzerato" e con il solo livello del rumore termico (noise floor).
Se ad uno dei due segnali applicassimo una variazione di 0.1db a 1khz e li riconfrontassimo...risulterebbe un evidentissimo picco di ben 50db (circa) perfettamente centrato a 1khz...quindi si passerebbe dal rumore termico al rumore di quantizzazione (circa 90/95db)
Questo per far capire che la NTD va vista come una "gara tra automobili in pista"...ovvero adatta a fornire un indicazione su chi sta davanti//indietro...ma al contempo senza riferimenti di velocità e distanza (in metri...o centimetri) tra le vetture.
La NTD serve per rilevare una "differenza"...chi piu...chi meno...
E' lo "scotto" che si paga per quando si effettuano test in condizioni di funzionamento effettivo e con segnali complessi (quale il pink noise o musicali)...diversamente con misure convenzionali non si vedrebbe nulla.
Salvatore ha voluto creare due variabili (correzione off e on dell'errore di sample rate) ma non era nemmeno necessario poichè sarebbe bastato il confronto sulla ripetizione dei vari segmenti...che in caso di stabilità del clock avrebbero dovuto fornire un errore trascurabilissimo visto che ci troviamo in presenza di sola ripetizione dello stesso brano ed errore di clock noto (quello del "primo aggancio")
Su un protocollo Bifase mark code (tipo il mio) la ripetizione dei vari segmenti fornisce l'assenza di errori...risulta sempre 0,0000ppm...anche se ripetessi per 100 volte.
Dac come gli MSB Analog (ingresso USB quad) non ripetono lo stesso segnale analogico...come nell'esempio mostrato da Salvatore con i vari player...come dire ogni qualvolta si riproduce un brano...questo risulta diverso dall'altro.
Pare che con WTF si acuisca la costanza...e costanza significa meno errore e piu stabilità (ripetibilità)
Al momento non posso puntare direttamente il dito sulle cause...ma vi seguirò.
Se mi viene qualcosa in mente lo scriverò con piacere.

saluti a tutti.

Tom.

Benvenuto.

Ovviamente solo nel campo delle ipotesi, dato che non dispondo delle misure, ma per deduzione SE applicando la correzione di AudioDiffMaker la differenza svanisce, mi pare evidente che si tratti di una differenza 'correggibile' da quell'algoritmo, quindi delay o sample rate drift, non altro.

Spero converrai che il delay è del tutto ininfluente e non va considerato, o meglio se un player è più costante nel delay di un altro... non è che per questo sia preferibile, non più di uno con case giallo rispetto ad uno con case rosso.

Ho già fornito un ipotesi su come questo si possa ottenere da programma e dato che WFT ha un evidente ritardo in partenza, dovuto al caricamento del brano in RAM, mi pare che il caso sia proprio questo.

In teoria - ma non credo - potrebbe trattarsi anche di sample rate drift. Essendo coinvolto un processo DA/AD le differenze in frequenza si 'staticizzano' nei bit, quindi vengono rilevate come differenze, ma in realtà sono presenti SOLO perchè sono coinvolti due diversi clock. Se si usasse un master clock verebbero elise e quindi non comparirebbero. Per questo si applica la compensazione software.

Una volta applicata la correzione, quindi ritrovato l'allineamneto ed eliminato l'eventuale drift, non mi pare che WTF presenti "più costanza", anzi, a me pare che il primato (per quel che vale) vada attribuito a Daphile, ma visti i livelli assoluti (siamo < -86db a 40Khz) direi che le differenze di per se siano quasi trascurabili, in quanto molto vicine alla soglia teorica di risoluzione dei due dac in serie.

Dovremmo trovare un accordo su questo, altrimenti continuiamo ad attribuire 'maggiore costanza' a WTF, quando è solo minore varabilità del delay, un parametro del tutto ininfluente.

Comunque, ammettiamolo, WTF è certamente più costante nel delay di inizio riproduzione, mentre Daphile e Foobar partono con ritardi 'imprecisati' ogni volta. Sarà un caso che WTF non è gapless?

[gefrusti]

Benvenuto.

Ovviamente solo nel campo delle ipotesi, dato che non dispondo delle misure, ma per deduzione SE applicando la correzione di AudioDiffMaker la differenza svanisce, mi pare evidente che si tratti di una differenza 'correggibile' da quell'algoritmo, quindi delay o sample rate drift, non altro.

Spero converrai che il delay è del tutto ininfluente e non va considerato, o meglio se un player è più costante nel delay di un altro... non è che per questo sia preferibile, non più di uno con case giallo rispetto ad uno con case rosso.

Ho già fornito un ipotesi su come questo si possa ottenere da programma e dato che WFT ha un evidente ritardo in partenza, dovuto al caricamento del brano in RAM, mi pare che il caso sia proprio questo.

In teoria - ma non credo - potrebbe trattarsi anche di sample rate drift. Essendo coinvolto un processo DA/AD le differenze in frequenza si 'staticizzano' nei bit, quindi vengono rilevate come differenze, ma in realtà sono presenti SOLO perchè sono coinvolti due diversi clock. Se si usasse un master clock verebbero elise e quindi non comparirebbero. Per questo si applica la compensazione software.

Una volta applicata la correzione, quindi ritrovato l'allineamneto ed eliminato l'eventuale drift, non mi pare che WTF presenti "più costanza", anzi, a me pare che il primato (per quel che vale) vada attribuito a Daphile, ma visti i livelli assoluti (siamo < -86db a 40Khz) direi che le differenze di per se siano quasi trascurabili, in quanto molto vicine alla soglia teorica di risoluzione dei due dac in serie.

Dovremmo trovare un accordo su questo, altrimenti continuiamo ad attribuire 'maggiore costanza' a WTF, quando è solo minore varabilità del delay, un parametro del tutto ininfluente.

Comunque, ammettiamolo, WTF è certamente più costante nel delay di inizio riproduzione, mentre Daphile e Foobar partono con ritardi 'imprecisati' ogni volta. Sarà un caso che WTF non è gapless?

salve Marco...che ci siano incongruenze tra i due clock è chiaro...il processo D/A -> A/D provoca un errore...però questo non dovrebbe affatto variare in modo ballerino se la riproduzione verte nell'acquisire una serie di segmenti della stessa traccia.
Tra segmenti (sm63 ha creato una singola traccia con 10 segmenti di segnale) ci dev'èssere costanza nonostante l'errore noto risultasse riscontrabile se confrontato il segnale originale con la traccia analogica acquisita.
Salvatore ha confrontato gli spezzoni della medesima traccia...qui c'è un errore di frequenza di campionamento causa deriva del clock.
Una singola traccia non può provocare una deriva se ogni 20 secondi si presenta il segnale.
Se si manifestasse un delay ADM allineerebbe una parte di traccia e nel segnale differenza si formerebbero parti cancellate e non.
L'interfaccia USB associata ai vari player è nota per provocare delay...con sm63 lo abbiamo visto in diverse occasioni (il famigerato effetto a "farfalla" che si forma nella forma d'onda del segnale differenza)
Ora in questo caso (non ho il segnale differenza e dovrebbe mostrarlo Salvatore) farei pendere l'ago della bilancia più verso un possibile disturbo del clock (che genererebbe la deriva del sample rate) che un delay...fenomeno quest'ultimo ampiamente visto e metabolizzato.

saluti, Tom.

[marcoc1712]

salve Marco...che ci siano incongruenze tra i due clock è chiaro...il processo D/A -> A/D provoca un errore...però questo non dovrebbe affatto variare in modo ballerino se la riproduzione verte nell'acquisire una serie di segmenti della stessa traccia.
Tra segmenti (sm63 ha creato una singola traccia con 10 segmenti di segnale) ci dev'èssere costanza nonostante l'errore noto risultasse riscontrabile se confrontato il segnale originale con la traccia analogica acquisita.
Salvatore ha confrontato gli spezzoni della medesima traccia...qui c'è un errore di frequenza di campionamento causa deriva del clock.
Una singola traccia non può provocare una deriva se ogni 20 secondi si presenta il segnale.
Se si manifestasse un delay ADM allineerebbe una parte di traccia e nel segnale differenza si formerebbero parti cancellate e non.
L'interfaccia USB associata ai vari player è nota per provocare delay...con sm63 lo abbiamo visto in diverse occasioni (il famigerato effetto a "farfalla" che si forma nella forma d'onda del segnale differenza)
Ora in questo caso (non ho il segnale differenza e dovrebbe mostrarlo Salvatore) farei pendere l'ago della bilancia più verso un possibile disturbo del clock (che genererebbe la deriva del sample rate) che un delay...fenomeno quest'ultimo ampiamente visto e metabolizzato.

saluti, Tom.

Cosa intendi per disturbo del clock? Un drift (cioè una leggera e costante variazione dell afrequenza di oscillazione?) o una vera e propria 'deriva' con errori casuali tra un picco e l'altro?

Se il secondo, sarebbe una scoperta non da poco, se il primo... siamo sempre li, si evidenzia solo perchè c'è il dopio passaggio, altrimenti non si vedrebbe neppure, tant'è che viene eliminato dall'algoritmo.

Attenzione, nnè una singola traccia, è un repeat, quindi un loop che esegue lo start, SE fosse una singol atraccia con silenzio/musica/silenzio, il silenzio sarebbe sempre uguale a se stesso, la diversità compare proprio perchè i diversi player hanno tempi divers di riempimento dle buffer.

ADM allinea se lo richiedi, se non lo richiedi non lo fa, da quello che ho capito (altrimenti tutto quanto ho scritto sul delay è basato su un falso presupposto) Salvatore inizialmente NON ha richiesto la correzione del delay ad ADM, ma effettuato un allinamento manuale. Questo, è noto, provoca proprio quel profilo di errore di fase, dovuto al fatto che l'allinamento base tempo ha il limite di un 1/sample rate s., mentre su base frequenza no, da qui i 30 db.

Forse è meglio che Salvatore chiarisca questoi aspetto prima di procedere.

[bibo01]

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.

Sono d'accordo con te. Il collegamento è asincrono e non dovrebbe contare nulla, ma nella pratica la preparazione dei pacchetti va ad influire su come "reagisce" il FIFO.
Strumentalmente è stato verificato che Foobar manda i bit samples al ricevitore USB con un certo pattern. Pur rimanendo bit pefect, questo pattern cambia con un PC clock più preciso (o più isolato... non so) e influisce sulla catena a valle.
_______________________________

Continuo a pensare che misurare 3 players differenti su 3 piattforme differenti con settaggi differenti sia un... rompicapo. Comunque, desidererei verificare che tali "differenze" tra players esistano anche su PC diversi. Ad esempio, può darsi che una motherboard diversa con un power supply "migliore" limino le differenze tra i players. Inoltre, soprattutto su un vecchio PC, l'uso del monitor (quindi della GPU) crea disturbi.
_______________________________

Riguardo la misurazione, nella singola traccia con 10 spezzoni uguali inframezzati da silenzio si potrebbe prendere una porzione interna uguale in ciascun spezzone.

[gefrusti]

Cosa intendi per disturbo del clock? Un drift (cioè una leggera e costante variazione dell afrequenza di oscillazione?) o una vera e propria 'deriva' con errori casuali tra un picco e l'altro?

Se il secondo, sarebbe una scoperta non da poco, se il primo... siamo sempre li, si evidenzia solo perchè c'è il dopio passaggio, altrimenti non si vedrebbe neppure, tant'è che viene eliminato dall'algoritmo.

Attenzione, nnè una singola traccia, è un repeat, quindi un loop che esegue lo start, SE fosse una singol atraccia con silenzio/musica/silenzio, il silenzio sarebbe sempre uguale a se stesso, la diversità compare proprio perchè i diversi player hanno tempi divers di riempimento dle buffer.

ADM allinea se lo richiedi, se non lo richiedi non lo fa, da quello che ho capito (altrimenti tutto quanto ho scritto sul delay è basato su un falso presupposto) Salvatore inizialmente NON ha richiesto la correzione del delay ad ADM, ma effettuato un allinamento manuale. Questo, è noto, provoca proprio quel profilo di errore di fase, dovuto al fatto che l'allinamento base tempo ha il limite di un 1/sample rate s., mentre su base frequenza no, da qui i 30 db.

Forse è meglio che Salvatore chiarisca questoi aspetto prima di procedere.

Buongiorno a tutti...come detto prima non ho elementi sufficienti per asserire quale fenomeno scaturisce da questo confronto...però provvisoriamente ci vado "a naso"-
Foobar...se messo in repeat...non provoca drift su interfacce spdif...abbiamo in quel caso un PLL che lo recupera...di contro anche la lettura dei samples via Fifo (su USB) è slegata da questo in quanto la "costruzione del clock" avviene nel device...essendo asincrono.
Il tempo di caricamento (se ha messo in repeat...peraltro anche potenzialmente assorbibile dal silenzio iniziale) è relativo in quanto i file verranno poi allineati...mi pare che il dritf in questo caso si trova dentro lo stesso file...tra vari file (nonostante l'allineamento) permane un sample rate error se confrontati specularmente tra loro.
L'ipotesi gettata da Gianluca (pc clock piu preciso) non dovrebbe teoricamente influenzare il clock master del device...poichè il pc clock serve per arbitrare le trame tra PC e buffer (o fifo)...come dire...potrebbe influenzare la portante su cui viaggiano i pacchetti...ma non il clock master del DAC. (non considero overrun della fifo se no funzionerebbe male la trasmissione asincrona)
Dunque...se il clock master del device costruisce un proprio clock di riferimento...perchè questa deriva del sample rate ?????
Dico questo perchè ho sempre assistito ad un errore noto tra processi D/A --> A/D...ma non variabile in corso...la fase D/A e quella A/D si "assesta" (aggiungo solitamente) su un sample rate error...ma tra la ripetizione degli stessi brani l'errore dovrebbe scomparire o risultare molto trascurabile.
Se devo formulare una prima ipotesi..ancora azzardata...potrebbe accadere che l'eventuale oscillazione della FS della portante (pc clock) possa intermodulare con la FS del clock di riferimento...ergo generare dritf.
Andiamo avanti...(nel frattempo se mi viene qualche idea sulla composizione di un segnale ancora piu adatto la posto)