Wtfplay - misurazioni e confronti con players

[SM63]

Credo possa interessare ....

Veniamo al risultato ....i grafici che spostero racchiude un po il quadro della sistuazione ....i player sono tre ...volutamente ho preferito testare solo quelli free ....

A) Foobar ....
B) Daphile ...una delle ultime versioni stabili
C) WTFplay ...se non avessi letto questo 3d con molta propabita' mi sarei perso emozioni che non avrei mai provato ...

Hardware

1) Pc ottimizzato per misure e ascolti
2) Futro
3) Dac basato sulla interfaccia Xmos diyinhk con Ak 4490 pesantemente ottimizzato
4) Dac basato sulla interfaccia JLS 2 sempre con Ak 4490 non particolarmente ottimizzato ...

Sfortunatamente non ho potuto provare un secondo Pc ottimizzato per gli ascolti avviabile dalla USB per fare andare ( daphile-WTF)...

Finalita' ...

Vista l'evidenza differenza agli ascolti ..non nascondo le non poche difficolta' per accertare le possibili cause ...ricordo stiamo parlando di player in bit perfect ...in teoria come nella pratica dovrebbero garantire il medesimo risultato sonoro ....


Metodologia ... ( NTD) By Tom .... per chi volesse approfondire in cosa consiste consignio questa lettura “NTD”

Come molti sapranno uno dei modi per evidenziare differenze prodotte da qualsiasi forma di alterazione ....consiste in un confrotto speculare tra due segnali ...uno va tenuto come riferimento ... confrontato con quello acquisisto ...dopo essere stato opportunamento allineato .... il risultato ottenuto dalla cancellazione totale o parziale ...permette di stabilire con assoluta certezza eventuali differenze .....

Dopo questa breve illustrazione sono passato alla prima verifica ....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 ....se mi chiedete agli ascolti si sente la differentra tra le due impostazioni ....SI .....anche in modo sostanziale ....

Fino qui nulla di nuovo .....non poteva essere diversamente ....siamo in bit perfect oltre questo tra la riproduzione e l'acquisizione aggancia allo stesso clock ....i problemi sorgono durante le acquisizioni con i dac USB
cioe acquisendo dalle uscita analogica passando da una doppia conversione D/A -A/D ....in questi casi e facile imbatersi nell'errore ....visto che durante il calcolo necessita compensare l'errore in ppm .....

Vediamo la prima NTD ....il confronto tra il segnale campione con il segnale acquisito dalla stesso dac in analogico riprodotto dai tre payer ....la differenza oggetiva non trova riscontro rispetto a quelle percepite

[marcoc1712]

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 ....se mi chiedete agli ascolti si sente la differentra tra le due impostazioni ....SI .....anche in modo sostanziale ....

Il parametro andrebbe visto congiuntamente al buffer size (-n), che per default è a 3 e minimo a 2.

Insieme determinano la dimensione del buffer di alsa, in funzione del sample rate e del bith dept.

Stando a quello che scrivi (dando per scontato il mantenimento inalterato degli altri parametri) sembrerebbe che buffer più grandi provochino minore cancellazione, il che mi sembra francamente strano. Cosa rappresentano i msec? la latenza? Se così fosse, sei sicuro doi non aver invertito le due condizioni (B = buffer più grande?).

Rispetto ai valori comunuemente usati in squeezelite, sono comunque buffer molto grandi. Hai provato a usare valori corrispondenti (da convertire) in squeezelite e ripetere la misurazione?

[SM63]

Il parametro andrebbe visto congiuntamente al buffer size (-n), che per default è a 3 e minimo a 2.

Insieme determinano la dimensione del buffer di alsa, in funzione del sample rate e del bith dept.

Stando a quello che scrivi (dando per scontato il mantenimento inalterato degli altri parametri) sembrerebbe che buffer più grandi provochino minore cancellazione, il che mi sembra francamente strano. Cosa rappresentano i msec? la latenza? Se così fosse, sei sicuro doi non aver invertito le due condizioni (B = buffer più grande?).

Rispetto ai valori comunuemente usati in squeezelite, sono comunque buffer molto grandi. Hai provato a usare valori corrispondenti (da convertire) in squeezelite e ripetere la misurazione?

Per forza di cose quando acquisisci devi tagliare inizio e fine traccia ...quella che a te pare l'incogrueza è solo la differenza tra il taglio delle traccie ...

[marcoc1712]

Per forza di cose quando acquisisci devi tagliare inizio e fine traccia ...quella che a te pare l'incogrueza è solo la differenza tra il taglio delle traccie ...

Scusa, non ho capito a cosa ti riferisci in riferimento a quanto hai quotato. Intendi dire che i msec sono diversi solo in funzione del taglio delle tracce (sono quindi una posizione relativa) e non la latenza? in questo caso sarebbero del tutto ininfluenti.

La mia perplessità è che - a parità di tutti gli altri fattori - buffer più grandi provochino maggiore cancellazione, mi sarei aspettato l'esatto contrario, eventualmente, per l'effetto di xRuns, ma in effetti si tratta di valori in assoluto alti, probabilmente i fattori sono altri. Sarebbe da investigare.

NOTA BENE: qui quello che cambia sono i bit (stai usando collegamenti asincroni), il tempo è escluso dalla questione. Hai provato a fare una comparaziuone binaria dei files? quante differenze vengono iontrodotte nelle diverse configurazioni?

E' un dato a mio avviso molto importante.

EDIT: Nelle prove fatte SPDIF/SPDIF i files rimanevano IDENTICI, nessun bit cambiato. Cosa succede qui inserendo USB e cambiando il buffer size in ALSA, al di là dell'immancabile e corrsipondente variazione della latenza?

Sarebbe interessante.

[SM63]

[QUOTE=marcoc1712;959463]Sempre per capire:

1. Nelle ripetizioni, i clock sono agganciati o no? (se si hai un drift unico, se no misuri la somma algebbrica dei due).
2. L'hw (compresi i cavi) è lo stesso per tutti i players?
3. Per compensazione di errore ppm intendi l'allineamento assoluto o qualche procedimento più invasivo?
4. WTF l'hai provato in configurazione A, B o è indifferente?
5. La curva riportata è 'la media' delle differenze? il profilo della curva è sempre così ben definito in tutte le singole rilevazioni e cambia solo il 'livello' reciproco?

Evidentemente non so spiegarmi ....come pretendi agganciare i due clock partendo dal dac USB acquisendo in analogico ...almeno questo ....nella seconda verifica si è compreso oppure no ...?

Certo sono stati mantenuti le stesse condizioni per testare tutti i player ...che senso avrebbe tutte il tempo impiegato

Errore ppm ....vedi la casella da spuntare su diffmaker ...compesate for sample rate drift

Non inacasiniamo le cosce lascia perdere per il momento la condizione A B

La curva riportata non è la media ....preso alcune come riferimento ....che senzo avrebbe riportare la media ? quello che conta mancanza nella ripetibilita' ...forse è questo che ancora non ti è chiaro ...

SE i clock sono aggangiati e l'hw è lo stesso, è effettivamente impressionante il fatto che utilizzando un player piuttosto che un'altro si riduca così sensibilmente l'errore ppm, che - in teoria - è una cartatteristica del cristallo variabile principalmente - se non esclusivamente - con la temperatura, non credo possa essere influenzata direttamente via software dal player, nel caso, quindi,. sarebbe interessante individuare ed isolare i processi che producono il drift (la rete? i dischi? il video? ) in modo così preciso e replicabile. Sarebbe un passo importante per capire COSA origina questo tipo di interferenze e prendere contromisure.

Per i motivi appena descritti i clock non possono essere agganciati ....ripeto le seconde acquisizione sono in analogico ...passando dal dac connesso in USB ....se conosci un modo per agganciare il clock ..sarei interessato

Se la correzione consiste in un allineamento temporale assoluto, ci andrei cauto a formulare correlazioni con l'ascolto. L'allineamento in se non è discernibile (ritaro o anticipo dell'evento) ed a seguito di quello le curve diventano quasi sovrapponibili (+/- 2 db a 40KHz).

Osservali con maggiore attenzione il secondo grafico ....curva rossa Foobar senza compensazione ....verde pisello compensato ....non sono +/-2 dB ... quello che ancora non si è compreso WTF curva Blu ..tra una acquisizione l'altra purche fatta in successione come le altre non necessita' alcuna compensazione ....mi sembra di aver parlato della ripetibilita'.... stesso evento ripetuto nel tempo ...gli altri player associati allo stesso hardware ...non si comportano alla stesso modo ...mancano nella costanza ...

Le mie conclusioni sono molto semplice il player come software per forza di cose interagisce con hardware PC incluso il sistema operativo ....forse non sara un caso l'autore del palyer la ridotto volutamente nei minimi termini ...

Ps : scusa conosci bene diffmaker ...prova acquisire ripetutamente lo stesso file due tre quantro ..quante volte vuoi ...confrontali tra gli stessi ....ai fini della ripetibilta' cosa ci dobbiamo aspettare ...?

[marcoc1712]

[QUOTE=SM63;959465]

Sempre per capire:




Evidentemente non so spiegarmi ....come pretendi agganciare i due clock partendo dal dac USB acquisendo in analogico ...almeno questo ....nella seconda verifica si è compreso oppure no ...?

Certo sono stati mantenuti le stesse condizioni per testare tutti i player ...che senso avrebbe tutte il tempo impiegato

Errore ppm ....vedi la casella da spuntare su diffmaker ...compesate for sample rate drift

Non inacasiniamo le cosce lascia perdere per il momento la condizione A B

La curva riportata non è la media ....preso alcune come riferimento ....che senzo avrebbe riportare la media ? quello che conta mancanza nella ripetibilita' ...forse è questo che ancora non ti è chiaro ...




Per i motivi appena descritti i clock non possono essere agganciati ....ripeto le seconde acquisizione sono in analogico ...passando dal dac connesso in USB ....se conosci un modo per agganciare il clock ..sarei interessato



Osservali con maggiore attenzione il secondo grafico ....curva rossa Foobar senza compensazione ....verde pisello compensato ....non sono +/-2 dB ... quello che ancora non si è compreso WTF curva Blu ..tra una acquisizione l'altra purche fatta in successione come le altre non necessita' alcuna compensazione ....mi sembra di aver parlato della ripetibilita'.... stesso evento ripetuto nel tempo ...gli altri player associati allo stesso hardware ...non si comportano alla stesso modo ...mancano nella costanza ...

Le mie conclusioni sono molto semplice il player come software per forza di cose interagisce con hardware PC incluso il sistema operativo ....forse non sara un caso l'autore del palyer la ridotto volutamente nei minimi termini ...

Ps : scusa conosci bene diffmaker ...prova acquisire ripetutamente lo stesso file due tre quantro ..quante volte vuoi ...confrontali tra gli stessi ....ai fini della ripetibilta' cosa ci dobbiamo aspettare ...?

Sia chiaro che io non voglio confutare quello che riporti come esperienza provata, ma semplicemnete capirlo ed inquadrarlo, perchè a mio avviso si corre il rischio di saltare troppo rapidamente alle conclusioni.

Per agganciare lo stesso clock nel caso di conversione DA/AD occorre che almeno uno dei dac consenta l'utilizzo di un master clock. Se i due clock sono indipendenti, stai misurando la somma algebrica dei due drift.

Come ti ho già scritto, nelle prove che feci tempo fa con SPDIF (per verificare la questione FLAC/WAV, nell'occasione) la differenza nel dominio digitale, in terminidi bit è risulatta nulla, come ci si aspettava. Il file acquisito è sempre risultato identico a se stesso. Inserendo la conversione AD/DA SENZA aggangiare i clock, il peso dei drift si faceva sentire Potevi ascoltare chiaramente la 'musica' dal file di differenza. Anche AudioDiffMaker ha una funzione di riallineamento, attivando la quale le differenze si assotigliavano molto, ma non spariscono mai, dato che i fattori ambientali - principalmente la temperatura - influiscono sulla precisione e costanza del clock. Due conversioni successive non danno MAI lo stesso risultato sonico ed - ovviamente - la riconversione in digitale non produce mai esattamente lo stesso file di origine. Può risultare 'sconvolgente' perr i sostenitori dei bit che sono bit, ma di fatto è così.

Cosa diversa è sostenere che tali differenze sono udibili. Se hai semplicemente un clock che invece di fornire esattamente 48.000 Hz, vibra a 48.005 o 47.995, l'esecuzione sarà leggermente più veloce o lenta, esattamente come avviene conun giradischi che vada leggermente più forte o più piano di 33 gpm. Fintanto che la velocità è costante all'interno di una esecuzione è irrilevante, se invece varia hai un fenomeo 'tipo' il wow and flutter, che diventa ben udibile.

Nel primo caso la 'corezzione' è 'semplice' (a condizione di avere un riferimento) nel secondo meno.

Ora, tutto questo però non prende atto in riproduzione (anche se teoricamente sarebbe possibile prevedere una funzione di feedback, come avviene in certi DSP, al prezzo di aumentare la latenza) e quindi è completamente al di fuori delle possibilità di controllo del player software.

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.

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.

Spero che su questo ci sia accordo.

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

[SM63]

[QUOTE=marcoc1712;959483][QUOTE=SM63;959465]

Cosa diversa è sostenere che tali differenze sono udibili. Se hai semplicemente un clock che invece di fornire esattamente 48.000 Hz, vibra a 48.005 o 47.995, l'esecuzione sarà leggermente più veloce o lenta, esattamente come avviene conun giradischi che vada leggermente più forte o più piano di 33 gpm. Fintanto che la velocità è costante all'interno di una esecuzione è irrilevante, se invece varia hai un fenomeo 'tipo' il wow and flutter, che diventa ben udibile.

Piemamente d'accordo ...come giustamente riporti nel primo caso il problema oltre a non porsi a livello percettivo ... sarebbe pure di facile soluzione ....infatti quello che ho rilevato con la seconda prova è proprio la non costanza del clock ....le cause possono essere le piu' svariati ....

A) instabilita dello stesso setup per l'acquisizione (PC1)
B) Hardware (pc) dove installato il player
C) Hardware (dac)

Ipotesi A da escludere per due motivi ....

Primo - se non si ha la certezza dello stadio ADC che garantisca ripetibilita... mi sembra inutile cimentarsi in queste prove .....
Secondo - questo trova conferma dallo stesso risultato ottenuto analizzando il player wtf .....

In automatico esclude l'ipotesi (C ) perche in comune per tutte le acquisizioni come lo stesso (PC1) usato per le acquisizioni ....

Rimane come unica sola ...l'ipotesi (B) ....non è forse quello che tutti cerchiamo ottimizzare con le piu' bizzarre soluzioni ?

Nel primo caso la 'corezzione' è 'semplice' (a condizione di avere un riferimento) nel secondo meno.

Non sono del tutto d'accordo .... anche nella seconda ipotesi disponiamo un riferimento certo ....le stesse acquisizione fatte in successione ....in questo caso poco importa se il clock va piu' avanti o piu' indietro ...l'importante mantenga la stessa cadenza ....questo riscontro punta esclusivamente nella costanza ....non piu' rispetto alla congruenza con il segnale in origine ...come risulta nel primo grafico

Forse questo passaggio non è ancora chiaro ....

Rinnovo l'invito a provare ..visto che conosci bene diffmaker ....ritengo molto interessante incrociare i risultati .... se trovi difficolta' per rappresentare i grafici ..ci penso io ....mi bastano i file dopo elaborati ....vale anche per il segnale da utilizzare come test ...

[UnixMan]

Due conversioni successive non danno MAI lo stesso risultato sonico ed - ovviamente - la riconversione in digitale non produce mai esattamente lo stesso file di origine. Può risultare 'sconvolgente' perr i sostenitori dei bit che sono bit, ma di fatto è così.

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

Se hai semplicemente un clock che invece di fornire esattamente 48.000 Hz, vibra a 48.005 o 47.995, l'esecuzione sarà leggermente più veloce o lenta, esattamente come avviene conun giradischi che vada leggermente più forte o più piano di 33 gpm. Fintanto che la velocità è costante all'interno di una esecuzione è irrilevante,

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

se invece varia hai un fenomeo 'tipo' il wow and flutter, che diventa ben udibile.

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.

[campa2]

Mi permetto di intervenire non perche' sia tecnicamente all'altezza ma perche' ho seguito da vicino le prove ed ho avuto i risultati direttamente.....
Il lavoro di Salvatore e' estremamente interessante e ci permette di mettere dei punti fermi su questioni importanti.........traduco per la plebe magari sbagliando.....
I player sono tutti uguali quando in bit perfect.....le differenze ci sono con upsampling e filtri (misurate e in alcuni casi di grossa entita').
Le differenze nel digitale pre dac (che ancora molti negavano fino a poco tempo fa e che ora trovano precisi riscontri nelle misure oltre che negli ascolti )sembrano essere nell'interazione hardware sistema operativo e player in particolare nella gestione dei processi.....cioe' sono questi 3 elementi che insieme producono il risultato......e quando le cose funzionano, come nel caso di wtf il risultato e' costante e non variabile nel tempo come invece per gli altri player-so provati. Wtf sembra annullare le interazioni negative (a livello di clock) e annullare tutto l'offuscamento prodotto da altri player-so
Credo di poter dire che fino a qualche mese fa si metteva l'accento sull'isolamento dell'usb dal pc (naa e simili....con convertitori ottico elettrici) ora credo che il punto non sia tanto quello del rumore prodotto dal pc o dalla qualita' dell'alimentazione del pc (cose che comunque dovrebbero essere significative) ma nell'ottimizzazione e semplificazione estrema dei software.....su questo ora abbiamo un preciso riscontro.
Interessante anche "scoperta" della variabilita' dei risultati.......c'e' una spoegazione alla variabilita' degli ascolti in diversi momenti....utilizzando gli stessi identici apparecchi e software.......chi l'avrebbe detto.......
Sono comunque risultati un po in divenire e da elaborare.......vedremo se saranno confermati e approfonditi....

[bigtube]

Mi permetto di intervenire non perche' sia tecnicamente all'altezza ma perche' ho seguito da vicino le prove ed ho avuto i risultati direttamente.....
Il lavoro di Salvatore e' estremamente interessante e ci permette di mettere dei punti fermi su questioni importanti.........traduco per la plebe magari sbagliando.....
I player sono tutti uguali quando in bit perfect.....le differenze ci sono con upsampling e filtri (misurate e in alcuni casi di grossa entita').
Le differenze nel digitale pre dac (che ancora molti negavano fino a poco tempo fa e che ora trovano precisi riscontri nelle misure oltre che negli ascolti )sembrano essere nell'interazione hardware sistema operativo e player in particolare nella gestione dei processi.....cioe' sono questi 3 elementi che insieme producono il risultato......e quando le cose funzionano, come nel caso di wtf il risultato e' costante e non variabile nel tempo come invece per gli altri player-so provati. Wtf sembra annullare le interazioni negative (a livello di clock) e annullare tutto l'offuscamento prodotto da altri player-so
Credo di poter dire che fino a qualche mese fa si metteva l'accento sull'isolamento dell'usb dal pc (naa e simili....con convertitori ottico elettrici) ora credo che il punto non sia tanto quello del rumore prodotto dal pc o dalla qualita' dell'alimentazione del pc (cose che comunque dovrebbero essere significative) ma nell'ottimizzazione e semplificazione estrema dei software.....su questo ora abbiamo un preciso riscontro.
Interessante anche "scoperta" della variabilita' dei risultati.......c'e' una spoegazione alla variabilita' degli ascolti in diversi momenti....utilizzando gli stessi identici apparecchi e software.......chi l'avrebbe detto.......
Sono comunque risultati un po in divenire e da elaborare.......vedremo se saranno confermati e approfonditi....

Mi permetto di dire che la questione dell'influenza dell'hardware PC è stata intuita da molto tempo. Un esempio il Cmp2 dove tutto il lavoro dell'autore era rivolto a
ridurre al minimo il funzionamento della cpu durante il processo di elaborazionne dello stream massacrando tutto quello che non serve .
Il giovane Polacco autore di Wtfplay a parte scriversi autonomamente il player ha saputo compilarsi un kernel dove probabilmente ha eliminato tutto l'eliminabile
per far girare solo il minimo indispensabile. Questa è la strada maestra e non lo sappiamo da ieri l'altro.....I kernel linux disponibili sono tutti o quasi generici cioè
fanno di tutto in macchine sempre piu' complesse e dedicate a un mucchio di cose che a chi ascolta musica non gliene frega un accidente.