Wtfplay - misurazioni e confronti con players

[marcoc1712]

sarebbe il segreto di pulcinella: alla configurazione si può risalire anche dal kernel in esecuzione.

Io, ovviamente, non sarei in gradi di farlo. Comunuqe ribadisco,chiedete a lui o passatemi la lista delle domande da fare, se tutto quento ci serve è in quello che si è detto dipsosto a fornire, benissimo, non ci saranno problemi, in caso contrario chiedere e lecito, rispondere è cortesia.

[bigtube]

sarebbe il segreto di pulcinella: alla configurazione si può risalire anche dal kernel in esecuzione.

Bene allora l'hai gia' fatto....facci sapere

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

[bibo01]

Riguardo SALSA

Per curiosità ho chiesto a Miska di HQPlayer cosa pensava di SALSA e se poteva essere utile nella compilazione del NAA

Could it be any use in the compilation of the various NAA images?

With some modifications, yes... But it would take some time package SALSA to do and re-validate the compatibility with networkaudiod.

Main drawback is this:

KNOWN PROBLEMS
--------------

- Incomplete MMAP mode

snd_pcm_mmap_*() are not implemented, and the mmap-mode is less tested, so far.

Can SALSA-lib have an effect on the playback?

I don't think so, only if you believe slight code variations in bit-perfect code paths having impact. Data going out would be the same anyway.

[marcoc1712]

Riguardo SALSA

Per curiosità ho chiesto a Miska di HQPlayer cosa pensava di SALSA e se poteva essere utile nella compilazione del NAA


With some modifications, yes... But it would take some time package SALSA to do and re-validate the compatibility with networkaudiod.

Main drawback is this:






I don't think so, only if you believe slight code variations in bit-perfect code paths having impact. Data going out would be the same anyway.

MMAP mode, personalmente NON ritengo sia un problema, ne abbiamo già discusso altrove. Comunque è facile provare, con squeezeite si può abilitare e disabilitare a piacere (in realtà significa usare diverse chiamate ad ALSA) e verificare 'ad orecchio' l'effetto che fa.

Per il resto, la considerazione che se è bit perfect i dati sono inalterati... vale per tutto e non solo per SALSA/ALSA, non ne capisco bene il senso.

Comunque i risultati delle rilevazioni in digitale andrebbero verificati, cosa che non sono attrezzato per fare, a naso, le differenze mi sembrano troppo grandi perchè siano dovute solo ad errori casuali.

[marcoc1712]

... se poi si confrontano sullo stesso OS ancora meglio-


Tom.

Questo dipende dalla volontà del creatore di WFT, non da me, però puoi provare squeezelite (= Daphile, al netto di OS) su stesso hw e OS di foobar, se vuoi.

[SM63]

@ 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 è cosi ....nelle ultime acquisizione ...mi sono dimenticato il resampler inserito a 88.200 ....

[marcoc1712]

Infatti è cosi ....nelle ultime acquisizione ...mi sono dimenticato il resampler inserito a 88.200 ....

Allora è impressionante che le differenze siano ccosì poche...

[marcoc1712]

....teoricamente i bit non sono perfetti ...forse Tom potrebbe chiarire la questione .....

Ci siamo allontanati da questo punto che a mio avviso è, invece, fondamentale. I files delle diverse riprese dello stesso file riprodotto in modalità diverse di WFTPlayer contengono un numero significativo di differenze NEI BIT anche se riallineati temporalmente ed a drift (ovviamente) nullo.

Posto che come tali risultano di certo non udibili (tutte le misure riportano un null a profondità > 190 db), a mio avviso non dovrebbero essere lì, in condizione di bit perfectness, e senza chiarire questo fatto, indagare su effetti indiretti causati dal diverso profilo di lavoro della CPU e fronte di una diversa riga di codice... mi sembra inutile.

Vorrei arrivare a stabilire se:

a. Sono cambiamenti 'significativi' o meno.
b. Cosa li provoca (il palyer o altro).
c. Sono voluti, 'sistemici' o frutto di errore casuale

Qualcuno ha idea di come procedere per valurarlo? Esistono strumenti? Se no, cosa dovrebbe afre un programma scritto ad hoc?

Io procederei così:

a. apre i due files
b. in base alla bit depth determina la dimensione del frame.
c. in base al sample rate determina il numero di frame per secondo.
d. in base all'endianess determina l'ordinamento dei bit.

e. analizza ogni frame e 'conta' i bit diversi.
c. mantiene un contatore della 'posizione' dei bit errati nei diversi frame, in base alla significatività)
d. consolida il risultato per unità di tempo, es. un secondo.

presenta i risultati in termini di:

1. numero di frame con errore
2. errori per frame
3. errori per posizione

in termini assoluti e percentuali, per l'intera durata e per unità di tempo, per valori minimo medio e massimo.Vorei produrre un output in qualche modo rappresentabile graficamente.

Se a qualcuno vengono in mente altre idee chieda pure.

[UnixMan]

Bene allora l'hai gia' fatto....facci sapere

no. Il fatto che sia possibile non significa che sia anche banale. Altrimenti non sarei stato a chiedere se gentilmente ci faceva avere il .config.

Hai detto niente .....c'è tutto il necessario per ricompilare il kernel e vedere poi l'effetto che fa'.....qualcosa mi dice che il file .config non lo molla

possibile, ma non fasciamoci la testa prima di averla rotta. :-)

Io una mano a farlo, sai che son na capra, poi i settings. Comunue, dato che ci segue, se tu o altri avete voglia di prendere l'iniziativa chiedete direttamente o fate pure il mio nome, ma parlate tra di voi cosi vi capite. Il risultato sareebbe di certo interessante.

infatti, sarebbe molto interessante. Ci provo, sentiamo cosa mi dice...

A mio avviso è più spaventato di esporre al giudizio di terzi (casa che io ho superato da mo) il proprio 'stile' che non convinto di tener tutto nascosto per chissà quali motivi arcani...

in effetti potrebbe anche essere. Visto che i risultati ottenuti sono alquanto diversi da quelli prodotti da altri sistemi "teoricamente equivalenti", non è affatto improbabile che abbia adottato soluzioni per così dire "poco ortodosse".

Riguardo SALSA
[...]
I don't think so, only if you believe slight code variations in bit-perfect code paths having impact. Data going out would be the same anyway.

De La Palisse... :-)

Per il resto, la considerazione che se è bit perfect i dati sono inalterati... vale per tutto e non solo per SALSA/ALSA, non ne capisco bene il senso.

Miska è un "ortodosso": sostanzialmente non crede che (nei sistemi informatici) fattori che non alterano i dati possano avere una qualche influenza sul suono. Cosa invero piuttosto comprensibile: mi arrendo all'evidenza, ma anche io faccio fatica a crederlo.

Infatti è cosi ....nelle ultime acquisizione ...mi sono dimenticato il resampler inserito a 88.200 ....

ah, ecco. q.e.d.

Vediamo cosa succede rimettendolo in modalità "bit-perfect"?