Wtfplay - misurazioni e confronti con players

[bigtube]

Stando alle misure o all´ascolto? perché nel mio caso e secondo i miei gusti (quindi parere personale) all´ascolto non c´é confronto.
e chiaramente con il mio hardware

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

[marcoc1712]

Sto scavando nella memoria per cercare di ricordare che programma utilizzai a suo tempo per confrontare il contenuto di due files.

Quello semplicemente 'conta' i bit dversi nei due files, già sarebbe qualcosa, meglio sarebbe se riuscisse a darne la rappresentazione della posizione relativa all'interno dei frames/campioni e la distribuzione temporale, stile il tool usato nella discussione segnalata da Bibo.

Sarebbe molto utile per evidenziare in modo semplice l'eventuale presenza di patterns non casuali nella distribuizione degli errori. Lo scopo principale è il confronto dei file acquisiti per via digitale, mi sembra che le differenze siano decisamente troppe perchè si tratti di errori casuali all'interno di un sistema bit perfect, ma non riesco ad oggettivare e quantificare. Qualcuno ha idee o consigli in proposito?

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

[gefrusti]

Se trovi il tempo, prova a considerare quanto emerge dalle misurazioni sullo stream preso IN DIGITALE da Salvatore. Ovviamente il drift è sempre nullo, ma anche alineando correttamente le tracce ci sono differenze non nulle (ed a mio avviso non casuali) nei files.

Hai una qualche intrepretazione da suggerire in merito?

...se ce la faccio con piacere Marco. :-)

ciao, Tom.

[gefrusti]

@Marcoc1712
@sm63

...ho guardato velocemente le acquisizioni digitali e...mi sono spaventato...troppe cose da verificare e in questo momento non posso permettermelo-

Facciamo una cosa...la cosiddetta "prova del 9"

Visto che tra WTF e FOOBAR scaturisce quella vistosa differenza nel segnale analogico...accertiamoci di quello che accade nel dominio digitale...e accertiamoci che foobar non sia in preda a qualche svista.

Quindi se Salvatore mi manda:

1) acquisizione in digitale da WTF

2) acquisizione in digitale da FOOBAR

3) acquisizione analogica da FOOBAR

Il tutto senza operare tagli (lo faccio io poi)

p.s se nel dominio digitale FOOBAR invia un flusso "modellato" con quella forma...allora il DAC si limita a convertire quanto inviato nello stream...se invece lo stream digitale dovesse inviare un segnale che non presenta "modellature"...significherà che durante il processo di pacchettizzazione (ordine delle trame) accadrà qualcosa che appartiene a fenomeni legati alle alterazioni non lineari-

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!