Ultima modifica di SM63 : 14-06-2016 a 09:48
nulla si crea nulla si distrugge ma tutto si trasforma
Quello che mi lascia più perplesso è la differenza "significativa" che ho ascoltato con WTF rispetto a tutte le altre combinazioni OS/Player con il mio DAC:
- Interfaccia JLSounds xmos, galvanicamente isolata
- Scheda di reclock JLSounds con gli oscillatori Crystek
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.
Ed invece ho sempre notato differenze ascoltabili, per poi arrivare a WTF che si stacca nettamente da tutti.
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 ?
Un cordiale saluto, Massimiliano
PS. WTF ha dentro 4 diversi kernels, si potrebbe misurare se ci sono differenze tra gli stessi, misurando il risultato al variare di un componente minimale
Marco ..spero con questo riusciamo a trovare il nodo della matassa ....
Iniziamo dal segnale preso come campione ....quella da fare riprodurre al player ....durata 20 sec incluso il primo secondo di silenzio ....
Imposto il player in repeat cosi da riprodurre ininterrottamente la stessa traccia ....stessa procedura per gli altri player ...
Acquisizione
Il dac sempre lo stesso per tutti i player ....connesso in USB ...dalle uscite analogiche prelievo il segnale verso il PC par le acquisizione ...posso acquisire in due modalita' ...nel test da me condotto ho provato entrambi
A ) il player in esecuzione in modalita repeat ...conoscendo la durata tra inizio e fine traccia ...attivo l'acquisizione per il tempo necessario affinche mi ritrovo almeno 10 ripetizione dello stesso segmento ....
A questo punto inizio la divisione dei vari segmenti tutti della stessa durata ....dopo ci pensera diffmaker per allineare tutto entro 100ps
B) seconda modalita per acquisire ...verificando ulteriolmente la repetibilita' delle acquisizioni ...questa volta non piu unico file tagliato nei vari segmenti ....si lascia sempre il player in repeat ...acquisendo volta per volta la singola traccia .... REC > tempo necessiari per visualizzare inizio fine segmento > stop ...stessa procedure fino arrivare a 10 ....
A lavoro finito mi ritrovo con 10 traccie ..ottenute da un unico segnale ....
Analisi
Ovviamente se vado a comparare una di queste acquisizione prendento come riferimento il segnale digitale in origine ....vista l'impossibilita' aggaciare il clock tra il DAC con la scheda d'acquisizione ...si va incontro quasi sicuramente a errore del sample rate .... come si sa ...questo potrebbe non influire sul risultato finale ...nel caso in cui il clock ( DAC ) mantenga costanza ...
Detto questo non rimane che accertare la constanza ....accetto volentieri suggerimenti non potendo escludere altri metodi per la diagnosi ....
Lasciamo da parte il segnale digitale originale ...in precedenza preso come riferimento ....troviamone un'altro potenzialmente adatto per lo scopo ..quale ....se non quello ...prendere come riferimento un segmento ottenuto dalle stesse acquisizione fatte in successione ...?
Teoricamente se il clock ( Dac) conserva costanza ...il confronto tra i vari segmenti non dovrebbero generare errore nel sample quanto meno in modo insignificante per la correzione ...
Seconda analisi ....confronto tra le acquisizioni ...al fine nell'accertare la costanza
Dalle 10 traccie ottenute si passa al confronto ....prendendo inizialemte come riferimento la prima ....questa va confrontata con le altre 2-3-4-ecc alla fine si cambia il riferimento dalla prima si passa alla seconda ...a sua volta confrontata con la 3-4-5 ecc ... fino arrivare la nona confrontata con ultima ...il tutto senza spuntare la casella compensazione sample rate ...diversamente sarebbe solo tempo sprecato ...
la rappresentazione grafica dei risultati dovrebbe indicarci la repitibilita dello stesso evento ...nel caso in cui le curve risultassero pressoche sovrapponibili ...vorra dire in assoluta certezza ...un alto grado nella costanza nonche ripetibilita' dello stesso evento ....
Cosa che sono riuscito a rilevare nel mio contesto ...solo esclusivamente con WTF ....sara un caso oppure no ?
Da parte mia nessuna considerazio affrettata solo esclusivamente riscontri oggettivabili in qualsiasi momento ....
Ultima modifica di SM63 : 14-06-2016 a 09:41
nulla si crea nulla si distrugge ma tutto si trasforma
non vedo perché dovrebbe essere sconvolgente: "i bit sono bit" (solo) fintanto che restano tali.
Quando li si "combina" con un clock (che, come non mi stancherò mai di ripetere, è un segnale analogico) per passare (tornare) nel dominio analogico, "i bit" non ci sono più... e con questi svaniscono anche tutte le altre caratteristiche proprie dei sistemi (puramente) digitali, quali la ripetibilità e la virtuale assenza di errori.
Un dato esatto nel momento sbagliato è un dato sbagliato... e quale sia "il momento" lo stabilisce il clock. Che, essendo un segnale analogico, è soggetto ad imperfezioni ed "errori".
D'altro canto è forse utile ricordare che (anche a parità di codifica, sample-rate, precisione, ecc) un dato segnale analogico non ha una rappresentazione unica ed univoca nel dominio digitale.
Anche in un contesto idealizzato e perfetto, lo stesso identico segnale analogico può essere rappresentato da sequenze di campioni completamente diverse tra loro. Tutte altrettanto esatte e perfettamente equivalenti tra loro.
Ad es., posto di inviare uno stesso segnale analogico a due ADC identici, entrambi "ideali" e perfetti, perfettamente sincronizzati da un medesimo clock altrettanto ideale e perfetto, è sufficiente che la lunghezza dei cavi che portano le due copie del segnale analogico sia diversa per far sì che vi sia una differenza (ritardo) temporale tra i segnali che arrivano ai due ADC. Ciò fa sì che i campioni vengano "misurati" e "registrati" dai due ADC in "punti del segnale" diversi tra loro... e quindi che anche i dati numerici prodotti dai due ADC siano diversi tra loro. Pur rappresentando entrambi esattamente, perfettamente e senza errori lo stesso identico segnale analogico.
Dico questo (anche) per sottolineare il fatto che questi "null test" possono essere molto utili ed interessanti, ma il loro impiego corretto è a dir poco estremamente difficile e delicato. È sufficiente il benché minimo dettaglio dimenticato o sottovalutato per inficiare completamente una misura, e dar luogo a risultati ed interpretazioni prive di senso o, peggio, completamente fuorvianti...
vero, ma... solo perché in questo caso le differenze sono minuscole.
Differenze (stabili) della frequenza del clock, cioè della "velocità" della riproduzione, causano uno "shift" dello spettro del segnale riprodotto (verso le frequenze più basse se la frequenza è minore, verso quelle più alte se è maggiore). Con i vecchi giradischi analogici dotati di regolazione fine della velocità di rotazione la cosa si poteva sperimentare facilmente, così come i suoi effetti sul suono percepito (più che evidenti per differenze cospicue rispetto al valore corretto, piuttosto subdoli e non immediatamente riconoscibili per differenze più modeste).
Nel caso dei sistemi digitali le differenze in valore assoluto della frequenza di un clock rispetto a quella di un altro sono veramente minime, a livello di ppm... e perciò gli "shift" che ne conseguono a livello del segnale audio ricostruito risultano essere del tutto insignificanti (ed almeno in linea di principio non dovrebbero portare ad alcuna differenza percepibile).
esatto. Non per caso il problema non è tanto la precisione assoluta o la stabilità a lungo termine del clock, quanto piuttosto la sua stabilità a breve/brevissimo termine, cioè il famoso "jitter" (o phase noise che dir si voglia). E non tanto (non solo) a livello del clock stesso (del segnale che esce dall'oscillatore): il punto critico è laddove questo "si combina" con i dati, cioè a livello delle commutazioni interne al chip del DAC (o dell'ADC).
Anche qui direi che sia opportuno precisare che l'entità del fenomeno è enormemente più piccola rispetto al "wow & flutter" di un giradischi o di un nastro analogici, e che gli effetti che ne conseguono sono piuttosto diversi. Anche e soprattutto a livello percettivo, laddove questi sono molto più subdoli e difficilmente riconoscibili per ciò che sono.
Ultima modifica di UnixMan : 14-06-2016 a 13:48
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
La modalità l'ho capita, quello che non riesco a trasmetterti è che il fatto che anche confrontandole 10 ripetizioni successive tra di loro hai SEMPRE e comunque il problema dei clock diversi.Marco ..spero con questo riusciamo a trovare il nodo della matassa ....
Iniziamo dal segnale preso come campione ....quella da fare riprodurre al player ....durata 20 sec incluso il primo secondo di silenzio ....
Imposto il player in repeat cosi da riprodurre ininterrottamente la stessa traccia ....stessa procedura per gli altri player ...
Acquisizione
Il dac sempre lo stesso per tutti i player ....connesso in USB ...dalle uscite analogiche prelievo il segnale verso il PC par le acquisizione ...posso acquisire in due modalita' ...nel test da me condotto ho provato entrambi
A ) il player in esecuzione in modalita repeat ...conoscendo la durata tra inizio e fine traccia ...attivo l'acquisizione per il tempo necessario affinche mi ritrovo almeno 10 ripetizione dello stesso segmento ....
A questo punto inizio la divisione dei vari segmenti tutti della stessa durata ....dopo ci pensera diffmaker per allineare tutto entro 100ps
B) seconda modalita per acquisire ...verificando ulteriolmente la repetibilita' delle acquisizioni ...questa volta non piu unico file tagliato nei vari segmenti ....si lascia sempre il player in repeat ...acquisendo volta per volta la singola traccia .... REC > tempo necessiari per visualizzare inizio fine segmento > stop ...stessa procedure fino arrivare a 10 ....
A lavoro finito mi ritrovo con 10 traccie ..ottenute da un unico segnale ....
Analisi
Ovviamente se vado a comparare una di queste acquisizione prendento come riferimento il segnale digitale in origine ....vista l'impossibilita' aggaciare il clock tra il DAC con la scheda d'acquisizione ...si va incontro quasi sicuramente a errore del sample rate .... come si sa ...questo potrebbe non influire sul risultato finale ...nel caso in cui il clock ( DAC ) mantenga costanza ...
Detto questo non rimane che accertare la constanza ....accetto volentieri suggerimenti non potendo escludere altri metodi per la diagnosi ....
Lasciamo da parte il segnale digitale originale ...in precedenza preso come riferimento ....troviamone un'altro potenzialmente adatto per lo scopo ..quale ....se non quello ...prendere come riferimento un segmento ottenuto dalle stesse acquisizione fatte in successione ...?
Teoricamente se il clock ( Dac) conserva costanza ...il confronto tra i vari segmenti non dovrebbero generare errore nel sample quanto meno in modo insignificante per la correzione ...
Seconda analisi ....confronto tra le acquisizioni ...al fine nell'accertare la costanza
Dalle 10 traccie ottenute si passa al confronto ....prendendo inizialemte come riferimento la prima ....questa va confrontata con le altre 2-3-4-ecc alla fine si cambia il riferimento dalla prima si passa alla seconda ...a sua volta confrontata con la 3-4-5 ecc ... fino arrivare la nona confrontata con ultima ...il tutto senza spuntare la casella compensazione sample rate ...diversamente sarebbe solo tempo sprecato ...
la rappresentazione grafica dei risultati dovrebbe indicarci la repitibilita dello stesso evento ...nel caso in cui le curve risultassero pressoche sovrapponibili ...vorra dire in assoluta certezza ...un alto grado nella costanza nonche ripetibilita' dello stesso evento ....
Cosa che sono riuscito a rilevare nel mio contesto ...solo esclusivamente con WTF ....sara un caso oppure no ?
Da parte mia nessuna considerazio affrettata solo esclusivamente riscontri oggettivabili in qualsiasi momento ....
Per il dac in acquisizione un segnale solo leggermente in ritardo è un segnale diverso e lo renderà in un file con BIT diversi. Il 'repeat' è un play automatico in un loop, SE WTF - come credo - al play inserisce un ritardo predefinito affinchè il buffer si riempia, mentre gli altri no (il che si traduce nel fatto che la riproduzione parte non appena il buffer risulterà pieno per n periods, in funzione dei parametri) è prevedibile che presenti una maggiore 'costanza' temporale rispetto agli altri.
Fintanto che questo disallineamento è costante all'interno del brano campione (ed indivuiduabile dal'algoritmio di correzione) non rappresenta un problema e non è un sintomo particolare di qualità o meno, se usi clock sincronizzati, non lo rilevi nemmeno.
Per questo io NON dico che tu non abbia rilevato i dati che presenti e nemmeno contesto il metodo, ma la differenza macroscopica che presenti è con ogni probabilità uno shift temporale (latenza, non un sample rate shift), il che non è direttamente correlabile con maggiore o minore qualità sonora.
Quello che (presumibilmente) tu hai rilevato è che WTF mantiene il delta di latenza entro limiti molto inferiori (se non nulli) rispetto a quanto fanno gli altri players. STOP.
Ti ho già fornito un metodo pratico e facile da utilizzare in programmazione per ottenere questo effetto, che nulla (o meglio pochissimo) ha a che fare con la 'precisione' o la costanza del clock.
Il dato che interessa noi è la precisione di oscillazione, quindi la costanza nel periodo tra due picchi successivi, DI UN UNICO DCLOCK, del tutto indipendente dalla latenza, ma sopprattutto individuare SE e QUALI fattori esterni possono alterarlo e SE e QUALI processi eseguiti sul PC lo fanno, SE ed IN CHE MISURA nei diversi OS, SW PLAYERS ed HW, così da poter EVENTUALMENTE individuare contromisure speciiche.
Ribadisco che, questo NON è in contrasto con l'asserzione che WTF suona meglio degli altri, semplicemnte NEGA lo faccia in ragione di quei 30 db di differenza a causa di 'coerenza' del clock.
Ultima modifica di marcoc1712 : 14-06-2016 a 14:54
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Concordo, ma bisogna intendersi sul senso del termine dift.
a. Disallineamentio temporale assoluto (latenza) è del tutto ininfluente.
b. Leggera e costante differenza nella frequenza di oscillazione (drift vero e proprio) è una caratteristica del cristallo e della temperatura di esercizio, entro limiti accettabili, non è influente, provoca un effetto di 'accelerazioone/rallentamento' con conseguente spostamento dello spettro rispettivamente verso l'alto o il basso, esattamente come avviene in analogico, serve 'orecchio assoluto' per indiviudarla e, comunque, nei sistemi sani è sempre contenuta entro limiti trascurabili.
c. instabilità nell'oscillazione (Jitter) Qui sta il problema.
Se ti riferisci a c. concordo con te, ma IN NESSUN MODO è riconducibile alle misure che evidenziano i 30 db di differenza, quelle sono con ogni probabilità relative ad A e - forse - a B in parte minore, visto che vengono eliminate dall'algoritmo di correzione e NON si presenterebbero utilizzando un clock comune.
Rmangono evidenti differenze, seppur di intensità diversa, sulle quali si potrebbe indagare per capire gli effetti delle diverse componenti. Per esempio dai grafici io capisco che daphile, al netto di latenza e - forse - drift 'benigno', ha il miglior profilo e forse non è un caso che sia l'unico headless dei tre. Allo steso modo si potrebbe investigare l'influenza delle rete, di HDD, SSD CF, pennette USB,...
Come ho già espresso però, il fatto chen a seguito di doppia conversione DA/AD il risultato sia inferiore ad 86 db a 40 KHz, lo fa rientrare nei limiti delle caratteristiche dei dacs utilizzati. La vedo dura.
Personalmente sarei molto interessato ad approfondire la differenza determinata dai parametri di ALSA già in dominio digitale, cosa che NON succede con SPDIF ma è stata evidenziata con USB, caso che non riesco a replicare.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Clearaudio Emotion + Satisfy + Grado Gold1 > Phono D3A DIY
Futro S450 + Daphile / Amanero + Buffalo 2 (trident) uscita a TU Cinemag 15/15B DIY / Jlsounds + Lector Digicode TDA1541 S1
Monoblocchi D3A 2A3 (electrolytich free!!) DIY / Coral Beta8 in BLH DIY
Secondo me è c), ma c'è qualcosa di strano nei grafici che desidererei Salvatore spiegasse perché non mi sembra possibile una differenza di 30dB, non solo tra compensato e non compensato, ma anche tra players. Forse il metodo di confronto tra le dieci tracce ha ingigantito le differenze...
Appunto .....avete un'idea di quanto pesa un kernel generico degli ultimi....circa 80Mb compressi
La iso di wtfplay pesa 30 Mb e ne ha disponibili almeno 2. Insomma c'è solo il kernel e poco piu'.
Quanto potra' essere disturbata la cpu che dialoga con la USB e quasi niente con il resto a parte il video ridotto all'osso?
player1:thin client+voyage - player2:futros450+Debian > Usb Transport: I2soverUSB + DAC (6x1704+I/V a tubi) - Attenuatore passivo Lightspeed
Ampli finale: OTL 6C33 - MyRef Fremen Ed. - Diff.: Diapason Adamantes II - Guida LMS+Squeezelite - B
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
