Wtfplay - misurazioni e confronti con players

[marcoc1712]

Sono in larga misura daccordo.....ma siccome con le mie orecchie ho constatato il netto miglioramento di prestazione di squeezelite-R2 con winserver comincio a pensare che le variabili in gioco siano diverse e approfondire come e perche possa portarci a cercare le strade giuste per migliorare l'esistente con cognizione.k

E' esattamente il mio obiettivo. Per questo ho anche proposto/chiesto a Friederick di aiutarmi ad installare Squeezelite-R2 ed attivare al rete nella sua distro, ma ha declinato, per il momento.

E' un prodotto chiuso e tale rimane, con buona pace di tutti.

Ciò non toglie che dall'analisi a confronto possano emergere indicazioni, è difficile, ma provarci sicuramente è istruttivo, è difficile perchè non credo che noi poveri sprovveduti armati di conoscenze di base e semplici strumenti amatoriali (parlo per me) si possa scoprire cose che i grandi centri di ricerrca ignorano, ma io sono convinto che il problema non stia li, quanto piuttosto che ai grandi centri di ricerca (ed anche ai piccoli) non interessi minimamente andare a scoprire e documentare "differenze" ad un livello di profondità tale da non interessare l'utenza 'normale'. Sono paturnie da audiofolli, non fanno conquistare quote di mercato...

Spero solo che il nostro lavoro non serva a qualche furbetto della cantina per vendere soluzioni 'segrete' a prezzi da gioielleria...

[gefrusti]

...sto facendo tutto di fretta (scusatemi) ma non potevo non postare la differenza che ---nel contesto di sm63--- e con il suo hardware-software è venuta fuori-

Cominciamo dalla forma d'onda messa in overlay tra DAPHILE e WTF...
Qui c'è molta coerenza...il leggerissimo microdelay intrinseco è ininfluente...al contempo ampiezza, rise time e geometria risultano sovrapponibili-
Verde DAPHILE e ROSSO WTF



Qui la differenza tra le risposte in frequenza...sia in real time che tracciando una funzione di trasferimento-






Adesso spostiamoci su (WTF-DAPHILE) vs FOOBAR
VERDE WTF e ROSSO FOOBAR

Overlay della forma d'onda...



Differenza di risposta in frequenza sia in real time che in versione funzione di trasferimento (molto "particolare" quell'anticipo pseudo-brickwall e la brusca risalita)





Considerando che il DAC usato è il medesimo e cambia soltanto la parte a monte digitale (hardware (?) + software player) ne viene fuori una differenza abbastanza evidente...visivamente sembra perfino un filtraggio diverso (visto quel brickwall anticipato) per cui se Salvatore avrà rispettato rigorosamente i settaggi (nessun resampler attivo e/o impostazione della frequenza di campionamento) e considerando che dal player esce un flusso Bit Perfect...questa differenza è abbastanza sorprendente.
Vorrei sapere per curiosità se WTF e FOOBAR girano sul medesimo hardware poichè potrebbe incidere ancor più dello stesso player-
Si dovrebbe (se possibile) confrontare FOOBAR e WTF nel medesimo PC-

a presto, Tom.

[SM63]

...sto facendo tutto di fretta (scusatemi) ma non potevo non postare la differenza che ---nel contesto di sm63--- e con il suo hardware-software è venuta fuori-

Cominciamo dalla forma d'onda messa in overlay tra DAPHILE e WTF...
Qui c'è molta coerenza...il leggerissimo microdelay intrinseco è ininfluente...al contempo ampiezza, rise time e geometria risultano sovrapponibili-
Verde DAPHILE e ROSSO WTF

Z2e1enn.jpg

Qui la differenza tra le risposte in frequenza...sia in real time che tracciando una funzione di trasferimento-

zWuSTQh.jpg

liM7nm8.jpg

Adesso spostiamoci su (WTF-DAPHILE) vs FOOBAR
VERDE WTF e ROSSO FOOBAR

Overlay della forma d'onda...

XfvIMfB.jpg

Differenza di risposta in frequenza sia in real time che in versione funzione di trasferimento (molto "particolare" quell'anticipo pseudo-brickwall e la brusca risalita)

3bvt2xP.jpg

hyyxcl3.jpg

Considerando che il DAC usato è il medesimo e cambia soltanto la parte a monte digitale (hardware (?) + software player) ne viene fuori una differenza abbastanza evidente...visivamente sembra perfino un filtraggio diverso (visto quel brickwall anticipato) per cui se Salvatore avrà rispettato rigorosamente i settaggi (nessun resampler attivo e/o impostazione della frequenza di campionamento) e considerando che dal player esce un flusso Bit Perfect...questa differenza è abbastanza sorprendente.
Vorrei sapere per curiosità se WTF e FOOBAR girano sul medesimo hardware poichè potrebbe incidere ancor più dello stesso player-
Si dovrebbe (se possibile) confrontare FOOBAR e WTF nel medesimo PC-

a presto, Tom.

p.s scusate se le immagini non compaiono direttamente...non conosco ancora l'esatto meccanismo (e poi oltre alla fretta ho la connessione che fa capricci)

Come dicevo in precedenza Foobar gira su un'altro hardware esattamente lo stesso pc dove acquisisco ....osservando i grafici riferiti a foobar sono molto strani ....questa sera controllo ...non vorrei per errore ho lasciato attivo un resampler ....anche perche da molto tempo non ascolto piu' con questo player ...

Per le altre acquisizione in digitale nessun problema ...sicuramente per fine settimana ....

[bigtube]

E' esattamente il mio obiettivo. Per questo ho anche proposto/chiesto a Friederick di aiutarmi ad installare Squeezelite-R2 ed attivare al rete nella sua distro, ma ha declinato, per il momento.

E' un prodotto chiuso e tale rimane, con buona pace di tutti.

Ciò non toglie che dall'analisi a confronto possano emergere indicazioni, è difficile, ma provarci sicuramente è istruttivo, è difficile perchè non credo che noi poveri sprovveduti armati di conoscenze di base e semplici strumenti amatoriali (parlo per me) si possa scoprire cose che i grandi centri di ricerrca ignorano, ma io sono convinto che il problema non stia li, quanto piuttosto che ai grandi centri di ricerca (ed anche ai piccoli) non interessi minimamente andare a scoprire e documentare "differenze" ad un livello di profondità tale da non interessare l'utenza 'normale'. Sono paturnie da audiofolli, non fanno conquistare quote di mercato...

Spero solo che il nostro lavoro non serva a qualche furbetto della cantina per vendere soluzioni 'segrete' a prezzi da gioielleria...

Non avevo il minimo dubbio su cio' che ti sta a cuore Marco. Sei la persona giusta per valutare come puo' essere scritto il codice.
A questo proposito mi chiedevo se nella stesura del codice son previste per squeezelite protocolli particolari per la gestione della cpu , della rete e della usb.
come è gia emerso dai discorsi fatti e piu' o meno noti lo sviluppatore di Wtfplay ha scritto il codice del player e ricompilato il kernel sulle specifiche hardware
delle CPU Intel . Puoi aggiungere qualche riflessione in proposito?

[marcoc1712]

Non avevo il minimo dubbio su cio' che ti sta a cuore Marco. Sei la persona giusta per valutare come puo' essere scritto il codice.
A questo proposito mi chiedevo se nella stesura del codice son previste per squeezelite protocolli particolari per la gestione della cpu , della rete e della usb.
come è gia emerso dai discorsi fatti e piu' o meno noti lo sviluppatore di Wtfplay ha scritto il codice del player e ricompilato il kernel sulle specifiche hardware
delle CPU Intel . Puoi aggiungere qualche riflessione in proposito?

Assolutamente nulla di tutto cio. Semplice codice C che si occupa di chiamare le diverse librerie per i diversi compiti, come è corretto che sia per un software protabile su tutti i principlai sistemi operativi e hardware.

Francamente NON credo che nessun player abbia in se codice per interagire DIRETTAMENTE con CPU, USB, Rete o altro, sarebbe MOSTRUOSAMENTE fragile, instabile, poco portabile e difficilmente manutenibile, WTF usa le stesse librerie di Squeezelite (limitandosi a pcm e flac) ma usa SALSA invece di ALSA e questa è l'unica vera differenza a livello di software 'sorgente'.

Quello che ha fatto, piuttosto, è stato compilare le diverse componenti (credo anche il Kernel) al fine di usare set di istruzioni specifici per i diversi chipset, ottenendo versioni molto 'verticali', dedicate e 'piccole', al sacrifico della portabilità e compatibilità. Qui però ci inoltriamo nel terriorio sistemistico ed io mi fermo, lascio ad altri la valutazione se questo sia un bene un male ed in quali situazioni, l'unica perplessità è che lo faccia in un ambiente 'chiuso' che anche volendo non puoi ricompilare sul tuo specifico sistema, quindi o rientri esattamente in uno dei due target o sei comunque in condizione sub ottimale.

Certamente può implememtare funzionalità aggiuntive (es il play form ram, che da quello che ho capito non fa tramite un ram disk esterno, ma caricandosi inizialmente il file nella sua memoria aplicativa (come se si trattasse di un buffer enorme), ma non credo si spinga oltre questo livello di profondità. Purtroppo non ho modo di verificarlo.

Di certo, nei sorgenti di squeezelite il 90% del software è dedicato alla gestione dei diversi parametri, l'implememntazione di SLIMPROTO per il colloquio con SBS, il 'collante' per la gestione delle diverse librerie, formati audio e sound systems (ALSA e PORTAUDIO). La componente 'palyer' vera e prorpia è semplicissima ed in pratica un loop entro il quale vengono spostate dall'input all'output porzioni dello stream in funzione dei formato e delle dimensioni dei buffer applicativi. Non più di 50 righe in tuitto.

Squeezelite direttamente NON sa nulla di ethernet o usb, sa a mala pena se l'input è uno stream o un file locale, ma NON usa quell'informazione se non per accedere o meno all'header, cosa che io ho sfruttato per la mia modifica.

E' un perfetto esempio di astrazione applicativa, sono le diverse librerie e, tramite queste, i sottosistemi ed driver di dispositivo a svolgere il lavoro, come deve essere.

In Linux, usando ALSA, scende appena più in basso, nel senso che permette di specificare parametri (quelli che conosciamo) e li trasmette nel comando di apertura, ma se si usa portaudio, delega anche questo alle relative librerie, che sono una astrazione dei vari sistemi, infatti mi ha stupito che abbiate riscontrato maggiore qualità con Win Server 2012, ma probabilmente questo è dovuito proprio al fatto che non interferisce con il lavoro svolto dal sound system e dai drivers.

Non è un caso che squeezelite si presti bene per realizzare 'bridge' verso altri sistemi (UPNP; ChormeCast,...) proprio grazie alla sua struttura "perfettamente" modulare.

Da questo punto di vista, squeezelite è quanto più simile ad un cavo un software player possa essere, ovviamente ha anche il 'tape loop' e puoi inserici tutti i dsp che vuoi (es. il resample) ma anche in questo caso non fa altro che richiamare librerie (anche dinamiche) e passare parametri.

[bibo01]

@ Tom, Salvatore, Marco

Non mi sembra possibile che le ultime acquisizioni di Foobar siano corrette.
Quando inizialmente Salvatore aveva confrontato il segnale campione con le 3 acquisizioni dalla stesso dac in analogico riprodotto dai tre payer, Foobar era corretto.
Se ci fosse stata quell'ultima voragine, non avrebbe superato il null test!

[gefrusti]

@ Tom, Salvatore, Marco

Non mi sembra possibile che le ultime acquisizioni di Foobar siano corrette.
Quando inizialmente Salvatore aveva confrontato il segnale campione con le 3 acquisizioni dalla stesso dac in analogico riprodotto dai tre payer, Foobar era corretto.
Se ci fosse stata quell'ultima voragine, non avrebbe superato il null test!

Infatti è sorprendente quell'andamento...e chiedevo di verificare-

Magari Salvatore può aggiungere a quelle acquisizioni anche la corrispondente analogica di WTF

Quindi da WTF digitale + analogica...e da FOOBAR digitale + analogica- per un totale di 4 files-

Dai Salvatore...ci metti un attimo...non farci aspettare fino a domenica!

[marcoc1712]

Infatti è sorprendente quell'andamento...e chiedevo di verificare-

Magari Salvatore può aggiungere a quelle acquisizioni anche la corrispondente analogica di WTF

Quindi da WTF digitale + analogica...e da FOOBAR digitale + analogica- per un totale di 4 files-

Dai Salvatore...ci metti un attimo...non farci aspettare fino a domenica!

Anche a me sembra strano, ma segnaloche ADM ha un parametro che indica il limiti del confronto in frequenza, la 'voragine' è ben oltre i limiti standard, quindi probabilmente non viene considerata nel confronto.

A me sembra quasi il profilo di un filtro passa basso, la cosa più strana è il 'ritorno' dopo i 45 KHz.

Comunque considerate che

WFT e Daphile girano sullo stesso hw e, praticamente, sullo stesso OS, salvo diversi settaggi è sempre Gentoo, mentre Foobar è su un pc diverso e in Windowws XP (con che drivers? sicuro di aver bypassato il mixer di windows ed il conseguente resampling?)


A breve avremo altre opportunità di test a paritò di OS.

[gefrusti]

Anche a me sembra strano, ma segnaloche ADM ha un parametro che indica il limiti del confronto in frequenza, la 'voragine' è ben oltre i limiti standard, quindi probabilmente non viene considerata nel confronto.

A me sembra quasi il profilo di un filtro passa basso, la cosa più strana è il 'ritorno' dopo i 45 KHz.

Comunque considerate che

WFT e Daphile girano sullo stesso hw e, praticamente, sullo stesso OS, salvo diversi settaggi è sempre Gentoo, mentre Foobar è su un pc diverso e in Windowws XP (con che drivers? sicuro di aver bypassato il mixer di windows ed il conseguente resampling?)


A breve avremo altre opportunità di test a paritò di OS.

...è cosi...in frequenza ADM lavora fino a 20/21khz...
Attendiamo la verifica e se poi si confrontano sullo stesso OS ancora meglio-


Tom.

[UnixMan]

WTF usa le stesse librerie di Squeezelite (limitandosi a pcm e flac) ma usa SALSA invece di ALSA e questa è l'unica vera differenza a livello di software 'sorgente'.

infatti.

Tanto per chiarire, "SALSA" è una versione di ALSA (o meglio delle librerie e dell'architettura in user-space di ALSA) semplificata e ridotta ai minimi termini (è pensata per applicazioni "embedded" su piattaforme con risorse estremamente limitate). Include esclusivamente il minimo indispensabile per fornire l'accesso diretto ai "driver" dei dispositivi (che sono nel kernel), escludendo tutta la gestione dei "plugin". Cioè, in pratica, permette di avere e di utilizzare soltanto i devices "raw", diretti, "hw:x,y".

In teoria, se con ALSA si utilizzano esclusivamente i device diretti (hw:x,y), tra questo e SALSA non dovrebbe esserci alcuna differenza (salvo che per la diversa quantità di spazio occupato sul disco...).

Quello che ha fatto, piuttosto, è stato compilare le diverse componenti (credo anche il Kernel) al fine di usare set di istruzioni specifici per i diversi chipset,

esatto. Nulla di strano: con Gentoo è praticamente la norma!

Gentoo infatti è una distribuzione basata (solo) sui sorgenti: qualsiasi software si voglia installare (inclusa ogni parte del sistema stesso) deve sempre, necessariamente, essere compilato "al volo" sulla propria macchina.

Dovendo ricompilare al momento tutto il software che verrà utilizzato (solo) sulla macchina su cui si sta installando, è ovvio che si scelga di attivare tutte le opzioni di configurazione ed ottimizzazione specifiche per il relativo hardware. Con tutti i vantaggi del caso.

I kernel Linux poi prevedono da sempre opzioni di configurazione (e compilazione) specifiche per i diversi tipi di CPU, chipset, ecc.

(Nei tempi "eroici", configurare e compilare il proprio kernel -"ritagliato" ed ottimizzato per il proprio hardware- era non solo la norma, ma addirittura una necessità inevitabile. Solo dopo l'avvento della "modularizzazione" del kernel si sono cominciati a diffondere i kernel "generici" precompilati. Cosa senza dubbio comoda e che ha semplificato di molto l'accesso a Linux da parte dei neofiti, ma non priva di controindicazioni ed effetti collaterali).

Se le differenze tra un sistema e l'altro sono effettivamente dovute al diverso "timing" nella gestione del flusso di dati sul bus USB, è a dir poco probabile che questo genere di ottimizzazioni abbia una importanza rilevante.

l'unica perplessità è che lo faccia in un ambiente 'chiuso' che anche volendo non puoi ricompilare sul tuo specifico sistema, quindi o rientri esattamente in uno dei due target o sei comunque in condizione sub ottimale.

probabile.

BTW: vedi se riesci ad ottenere le opzioni di configurazione che ha utilizzato, in particolare le opzioni per il "configure" di SALSA ed il file ".config" del kernel (nonché fatti dire se ha usato un kernel "vanilla" o se/quali patch ha aggiunto).

Dopo di che fatti dare le modifiche che ha eventualmente fatto lui stesso a SALSA e/o al kernel (quelle ce le deve dare obbligatoriamente... altrimenti contattiamo la FSF e gli facciamo fare causa per violazione dei termini delle rispettive licenze).

A quel punto, un sistema "WTF-like" con la rete abilitata e Squeezelite-R2 al posto dei suoi software custom ce lo facciamo da soli...

[...] es il play form ram, che da quello che ho capito non fa tramite un ram disk esterno, ma caricandosi inizialmente il file nella sua memoria aplicativa (come se si trattasse di un buffer enorme),

possibile, per non dire probabile. Potrebbe anche utilizzare un ram disk standard (ad es. /dev/shm) ma, avendo a che fare con un proprio player custom, utilizzare un buffer interno alla fine è anche più semplice e comodo.