Wtfplay project

[Membro_0017]

li ho provati tutti, wtfplay rimane il migliore.

da quando è passato alla priorità a 5, che io avevo già adottato, ho capito che lo sviluppatore ha un impianto serio o comunque un orecchio preparato, e capisce qual è la strada migliore da seguire. priorità 2 è ancora meglio nel mio setup, ma bazzecole.

il mio processore supporta AVX ma anche ovviamente SSE. è meglio il kernel compilato con SSE. AVX introduce più latenza.

cmq, la sostanza è che su Linux, alla fine, è meglio dare spazio al driver (che lavora in kernel mode) che suona il brano piuttosto che al processo che carica in RAM il brano. meglio suonare dalla memoria perchè ovviamente c è meno latenza.

il suono migliora se è meno luminoso, non solo ne lsens odi aspro. il digitale non deve scintillare. però deve essere comunque aperto, il suono non deve collassare in microvoci o fonti sonore con attacchi in primo piano ma senza decadimenti.

 

[Necro]

3 ore fa, Kingcarl67 ha scritto:

e piu' il dubbio mi assale: nella vita farà il filosofo o il copywriter?

Nella vita fa l'ingegnere informatico. Motivo per cui mi piacerebbe che le prove degli ascolti siano avallate da un test con un senso. Sono il primo a dire di fidarsi delle orecchie e non delle misure, nonostante la mia formazione (cosa che ho ripetuto tantissime volte nella sezione dei cuffiofili). Però, per fare una valutazione onesta delle proprie orecchie bisogna mettersi in condizione di poterle usare bene. La filosofia, è quella di giudicare a sentimento in condizioni non controllate. Sono assolutamente aperto ad accettare qualsiasi risultato, potete dire altrettanto?

 

Aneddoto 1: prima della caduta di Melius c'era un utente, di cui non ricordo il nome, che sosteneva di aver sentito notevoli differenze soniche passando da un i3 ad un i7. Gli ho suggerito la prova di cui sopra e, in modo intellettualmente onesto, l'ha fatta. Risultato: ha venduto l'i7 perchè in realtà le differenze non c'erano. Per quale ragioni sentiva le differenze prima? Vai a sapere...ma tant'è...Se ci legge ancora può intervenire.

 

Aneddoto 2: circa 2 mesi fa ho cambiato il mio sistema Topping A90/D90 con un Audio-GD R8 e Fezz Audio omega Lupi. Ho fatto il test descritto sopra. Risultato:

Riconoscimento differenza DAC: 37 brani su 40.

Riconoscimento differenza Ampli: 35 brani su 40.

Prova rifatta varie volte con risultati dallo scarto di +/-1.

Ho fatto bene a spendere i soldi in più? Si. Ovviamente poi ho scelto di tenere la coppia che preferisco sonicamente, ossia la seconda (anche se sulla carta misura peggio della prima!!!).

 

Ho un amico, audiofilo neofita. Ha fatto lo stesso test con gli stessi apparati e nelle stesse condizioni:

 

Riconoscimento differenza DAC: 10 brani su 40.

Riconoscimento differenza Ampli: 13 brani su 40.

Faceva bene a spendere i soldi in più? No.

 

Ora, la "spesa dei soldi" non è il punto della questione. La questione è capire se nell'ascolto entrano o meno dei fattori che non state considerando, qualsiasi essi siano. Questo lo può dire solo la prova. A quel punto la solidità nell'affermare differenze soniche fra i player diventa molto migliore. Accetto che ci sia, ma su delle basi. Chi legge un forum come questo, forse, e dico solo forse, potrebbe avere idee più chiare dei pro e dei contro dei vari player. Mi rendo conto che è solo una chimera, ovviamente.

 

Con questo vi saluto! Buoni ascolti e, spero, buone prove! 😄 

Ciao!

 

[Membro_0017]

@Necro le prove in audio non si fanno così. manco gli amplificatori riconosci così.

le prove audio si fanno tendendo un componente, HW o SW, per qualche settimana, ti abitui al suono , valuti ciò che ti piace o meno, valuti il modo in cui ti fa fa godere della musica. certo valuti i dettagli. quell oche senti, ma è la cosa minore. invece se ci passi il tempo e ti diverti, tutti le volte, è una misurazione buona. perchè se suona peggio delle tue aspettative, alla lunga ti diverti meno.

quind se non ti stufi già è un buon indizio.

poi decidi di cambiare, e rifai lo stesso percorso. 

quando ti rendi conto che preferisci A a B, puoi anche staccare e riattaccare. ma prima lanci solo una moneta.

 

ps. il fatto che un i7 suoni meglio di un i3 è presto detto. il processo del tuo player che fornisce i frame al driver ,per darglieli ogni 44.4 volte a lsecondo, è allocato in un core della CPU. ma non ci rimane certo epr tutti i 5 minuti del brano. o per sempre. il sistema operativo lo butta fuori ogni "quanto" di tempo, che è una frazione minuscola di un secondo. perchè i sistemi operativi moderni sono multitasking e la schedulazione è pre-emptive, cioè i vari processi devono sloggiare fuori dal core pure se non hanno finito il loro job. nessun processo può allocarsi un core e tenerselo per tutto il suo tempo di esecuzione.

quindi, più core hai a disposizione, più il sistema operativo può allocare i processi in parallelo, infastidendo meno quelli che richiedono più tempo in CPU. questo  significa che il processo player audio, e/o il driver, rimangono effettivamente in esecuzione (cioè nella lista dei processi RUN) più tempo se ci sono più core disponibili. uno potrebbe chiedersi se utilizzare motherbord mult-iprocessore con tantissimi core allora è la panacea: purtroppo no, perchè se ci sono più processori il tempo richiesto dallo scheduler per dire al processo tizio e a caio di andare in esecuzione nel processore 1 o 2 e nel core A o B... diventa predominante. e si aumenta di nuovo la latenza.

perchè è quello il problema. la latenza tra un frame e l altro. questa latenza introduce del jitter, che è udibile.

non credi al jitter introdotto? e allora non credi a questo hobby. il digitale dovrebbe suonare come il vinile secondo te, perchè non ci sono artifatti introdotti dalla conversione D/A tali da rovinare la shiftare la fase o mangiarsi le armoniche. non nei moderni DAC, ma manco negli antichi.

quindi invece di fare crociate su cose che forse non conosci, cambia hobby e stop.

[Necro]

15 minuti fa, emaspac ha scritto:

ps. il fatto che un i7 suoni meglio di un i3 è presto detto.

ah si? Perchè l'utente in questione diceva proprio il contrario, cioè che alla fine NON suonava meglio? Non erano importanti le orecchie...?

 

15 minuti fa, emaspac ha scritto:

perchè è quello il problema. la latenza tra un frame e il altro. introduce del jitter, che è udibile.

non credi al jitter introdotto? e allora non credi a questo hobby. il digitale dovrebbe suonare come il vinile.

ma ovviamente non è cosi. quindi invece di fare crociate su cose che non conosci, cambia hobby e stop.

Sono un professionista del settore informatico e per i primi anni della mia carriera ero ricercatore informatico sui sistemi operativi. Ciò che tu affermi è in generale corretto. Ciò che non consideri è che un i3 e un i7 sono perfettamente in grado di smistare la frequenza di campionamento richiesta, a maggior ragione se li metti su un sistema dedicato dove avrai molte meno interruzioni rispetto ad un sistema generalista. Quindi NO, un i7 NON fa suonare meglio il player di un i3 all'atto finale dell'ascolto. Anche se mi puoi aver saltato una deadline temporale un manciata di volte (cosa che fra un i3 e un i7 non accade), non sentirai la differenza. Questa tua affermazione non ha senso ed è in estremo disaccordo con tutti quelli che si comprano il Futro da 35 euro con processore irrisorio. Non sono sicuro di essere io a dover cambiar hobby ma se gli atteggiamenti che volete mettere in campo sono questi, ok, vi saluto definitivamente.

Saluti

[Membro_0017]

@Necro che vuol dire professionista?  invece io sono laureato in informatica, ma per davvero. ho 50 anni e ho lavorato e lavoro programmando driver e librerie per processori da 15 anni. ora lavoro i nquelli per le telecomunicazioni.

quindi SI, quello che scrivo è vero. e da notare che anche il set di istruzioni SIMD, AVX o SSE, se il processore è Intel, influisce pesantemente sulla latenza.

ora che tu senta o meno le differenze all orecchio, non è importante nel mio discorso: io ti sto riportando i fattori che aumentano la latenza. e di conseguenza il jitter. se riduci il numero dei processi in esecuzione il tuo processo rimarrà più tempo in CPU. se aumenti i core a disposizione, lo stesso (ovviamente evitando di farlo migrare inutilmente da un core all'altro usando l'affinity ,che consiglia allo scheduler di allocarlo prefiribilmente in un core definito a priori)

nel mio impianto si sentono queste differenze, nel tuo no pazienza. il mio impianto sarà migliore del tuo. perchè la teoria che ho enunciato è vera. è quella che ho scritto io. quindi non sono fenomeni psico-acustici. sono fenomeni informatici. dire che il processore è "perfettamente in grado"... non significa nulla. non è un discorso informatico, no nè effettivo. in grado di fare che cosa?

di riprodurre il brano? si. di avere lo stesso jitter? no.

anche se cambi i buffer dei driver, ASIO per linux, si sentono le differenze. perchè cambia la latenza.

il processore ovviamente l osuonerà il brano, eh. 

 

[Necro]

Adesso, emaspac ha scritto:

quindi SI, quello che scrivo è vero.

Laureato per davvero pure io, ricercatore e poi sviluppatore prevalentemente in ambito embedded.

Lo so che quello che scrivi è vero. Non ho detto che non è vero. Ho detto che per un processo di streaming audio, su un sistema per altro dedicato, un i3 e un i7 sono entrambi sovradimensionati di risorse hardware e permettono entrambi di garantire le stesse deadline temporali. Anche qualora ci fosse una perdita di una manciata di frame dire che si sente all'atto finale dell'ascolto (dopo tutti gli errori che poi introdurrà il DAC ed il resto della catena) vuol dire essere in grado di riconoscere la goccia di acqua nel mare...

[Membro_0017]

Adesso, Necro ha scritto:

Laureato per davvero pure io, ricercatore e poi sviluppatore prevalentemente in ambito embedded.

Lo so che quello che scrivi è vero. Non ho detto che non è vero. Ho detto che per un processo di streaming audio, su un sistema per altro dedicato, un i3 e un i7 sono entrambi sovradimensionati di risorse hardware e permettono entrambi di garantire le stesse deadline temporali. Anche qualora ci fosse una perdita di una manciata di frame dire che si sente all'atto finale dell'ascolto (dopo tutti gli errori che poi introdurrà il DAC ed il resto della catena) vuol dire essere in grado di riconoscere la goccia di acqua nel mare

 

ma di quali errori parli? non ci sono errori né ci saranno mai.

sto parlando di latenza. 

[Necro]

 

Distinguiamo le due cose:

A livello tecnico ci possono essere differenze di scheduling del driver fra un i3 e un i7 e quindi alcuni, molto pochi se non nulli frame fuori clock. Ciò dipende anche dal carico di sistema (lo puoi misurare ma stiamo parlando di quei due processori in questione e non stiamo parlando di un armv4 vs un intel i9). Siamo daccordo.

A livello di ascolto però (che è ciò che si tirava in ballo) mi sembra assurdo dire che lo "sentiamo". Non ci posso credere che "lo senti" in quelle condizioni.

6 minuti fa, emaspac ha scritto:

ma di quali errori parli? non ci sono errori né ci saranno mai.

sto parlando di latenza. 

Parlo del fatto che il segnale digitiale che esce dall'USB poi segue una catena (DAC, AMPLI, cuffie/speakers...) che a sua volta introduce errori di conversione fosse solo anche la conversione D/A (non parliamo di DAC che fanno OS ad esempio....). Torno a dire: vogliamo davvero raccontarci che all'atto dell'ascolto gli eventuali errori di drift che possono esserci fra un i3 e un i7 di ultima generazione saranno udibili su un flusso audio fosse anche a 192Khz?!? Ti hanno installato un oscilloscopio al posto del timpano? 😄 

 

[Membro_0017]

@Necro ma che cosa scrivi.

solo cambiando i parametri del buffer ALSA in linux cambia la latenza. e i risultati son oudibili. ma non perchè lo dico io, perchè si può calcolare. il driver ALSA però deve andare in esecuzione in un core (i nkernel mode). e per andarci, deve andare in competizione con altri processi di sistema, con la sua stessa priorità.

quindi, figurati se la latenza non cambia si inserisci un altro processore aggiungendo più core (sempre affidandosi all'affinity, altrimenti più core potrebbero essere persino deleteri... ad esempio se i processi sono così pochi che lo scheduler può scegliere i core a caso).

detto questo , a me però fa riflettere che ancora scrivi che saltano i frame: non salta nessun frame, altrimenti udiresti degli erroi. quindi o non sei un informatico, cosa che credo, o non hai capito la latenza. in entrambi i casi il tuo ragionamento non è scientifico.

quindi, dato che ora devo lavorare, ti saluto.

[Necro]

 

5 minuti fa, emaspac ha scritto:

a me però fa riflettere che ancora scrivi che saltano i frame: quindi o non sei un informatico, cosa che credo, o non hai capito la latenza.

Ma di quale cambio di latenza mastodontico stai parlando tu per dire che si "sente" la differenza?!?! Va bene ok, ci rinuncio. Che ognuno senta ciò che vuole sentire. Tanto, alla fine, la prova in cieco "nel mondo dell'audio" non si fa (come dici tu) perchè non conta, però contano le introduzioni al microsecondo di latenza (se ci sono!!!) fra processori sovradimensionati per il task in questione. Contento te....

[Membro_0017]

1 minuto fa, Necro ha scritto:

Ma di quale cambio di latenza mastodontico stai parlando tu per dire che si "sente" la differenza?!?! Va bene ok, ci rinuncio. Che ognuno senta ciò che vuole sentire. Tanto, alla fine, la prova in cieco "nel mondo dell'audio" non si fa (come dici tu) perchè non conta, però contano le introduzioni al microsecondo di latenza (se ci sono!!!) fra processori sovradimensionati per il task in questione. Contento te....

 

c è tutto un mondo del lavoro che sviluppa software per diminuire la latenza. basti pensare ai driver ASIO, a Pro Tools, ai kernel di Linux "configurati" per le applicazioni real-time. tutti strumenti inutili per indirizzare fenomeni per te psico-acustici... eppure tutti strumenti utilizzati negli ambiti professionistici, pagati fiori di dollari, per diminuire il jitter. altro esempio sono i clock atomici, negli studi di registrazione.

a costo di sembrare scortese: il tuo essere scettico è superato dalla realtà dei fatti. è come essere scettici sugli effetti della forza di gravità. se lo sei, non puoi essere un fisico.

[Necro]

11 minuti fa, emaspac ha scritto:

c è tutto un mondo del lavoro che sviluppa software per diminuire la latenza. basti pensare ai driver ASIO, a Pro Tools, ai kernel di Linux "configurati" per le applicazioni real-time. tutti strumenti inutili per indirizzare fenomeni per te psico-acustici... eppure tutti strumenti utilizzati negli ambiti professionistici, pagati fiori di dollari, per diminuire il jitter. altro esempio sono i clock atomici, negli studi di registrazione.

Ne sono consapevole. Torno a dire che la differenza a livello tecnico esiste, altrimenti non esisterebbe la ricerca, ma se qui parliamo di differenze udibili in modo "mastodontico" mi piacerebbe che ognuno valutasse per se stesso (orecchie e catena di impianto) se questa differenza a livello tecnico poi alla fine si sente per davvero. Se questa prova non si fa in un test controllato ma a "sentimento" (come hai descritto tu), le differenze numeriche rimarrano scorrelate dal risultato di ascolto. Il mio dubbio rimane quello. Tu mi puoi anche dire che il test in cieco è sbagliato, ma questo significa comunque che non riuesci a fare una correlazione tra le prestazioni sulla carta e ciò che viene percepito.  Si cerca il numerino importante di jitter e latenza, ma poi si è davvero in grado di sentirlo? Stai spostando la discussione verso altri lidi.

Qui si era partiti dal confrontare wtfplay con daphile che sono tutt'altro che sistemi ultra professionali, pagati nessun dollaro e che nessuno si sognerebbe mai di far girare su clock atomici. Quindi cosa centra il tuo discorso? Stai facendo un'altra discussione. Il mio "esortare a provare" (che non è "scietticismo" ma solo curiosità), quindi, si basa sulle condizioni della premessa ORIGINALE, non sulle condizioni che stai descrivendo ora che afferiscono ad un altro mondo.

[Membro_0017]

@Necro ma certo che lo senti. che domande sono. tutti gli esseri umani che cambiano i parametri del driver ALSA di linux, periodo e ampiezza del buffer, sentono diffferenze. per esempio a casa mia al cento per cento. ma non ho niente di speciale: penso basti un impianto di alta fedeltà, normale. a casa di amici si sente lo stesso. sono differenze eclatanti se il livello è ALTA fedeltà. senza problemi si sentono. si devon osentire, altrimenti il livello è BASSA fedeltà. che poi piacciano o meno dipende da tutta la catena.

 

ps- i clock che trovi dentro i DAC di alto livello sono quasi come quelli atomici, anzi alcuni, i migliori, nelle frequenze audio sono anche più precisi, avendo un rumore di fase più basso. perchè la precisione a lungo termine, che nei clock è un parametro preciso, non è così importante i ncampo audio. conta invece quanto jitter esiste tra un tick del clock e il successivo. e questo si misura col rumore di fase. 

 

 

[Necro]

1 minuto fa, emaspac ha scritto:

ma certo che lo senti. che domande sono. tutti gli esseri umani che cambiano i parametri del driver ALSA di linux, periodo e ampiezza del buffer, sentono diffferenze.

Ok, bene. Ne prendo atto. Buoni ascolti!

[Membro_0017]

@Necro ecco, iniziamo a prenderne atto. perchè negarlo significa semplicemente negare non solo che cosa ascolta il tuo oecchio, ma anche che esiste il jitter. quindi asserire  che le misure di latenza siano tutte risibili nell uso pratico. cosa vera sol ose il sistema non è ad alta fedeltà.

 

in genere vale questo:

 

https://www.yumpu.com/en/document/read/40401370/audio-latency-on-linux-kernels-alsa

 

e in particolare, tornando al discorso di i3 vs i7:

 

 

questi switch, se hai a disposizione più core e usi la proprietà di affinity, avvengono semplicemente meno spesso.

 

wtfplay usa la proprietà di affinity per il suo player dalla versione 7.3 mi pare.

[Necro]

@emaspac Guarda stiamo facendo due discussioni diverse ed è inutile continuare su questa strada anche perchè mi stai attribuendo cose che non ho detto nel modo in cui le stai riportando. Torno a dire che non ho mai detto che il jitter NON conti in assoluto, dico che a mio avviso esistono delle tolleranze per cui sentire la differenza in modo netto in determinati casi (ad esempio l'i5 vs i7 di prima) non mi sembra così ovvio come si crede o almeno questo dice la mia esperienza (sia tecnica che di ascolto). Proprio perchè io non voglio imporre alcun pensiero chiedo di fare delle prove perchè non ho altro modo di poterlo capire. Dovremmo incontrarci, ma non si può. Dal mio canto c'è massima tranquillità nella cosa, mi dispiace tu ti sia rivolto a me in modo anche sgarbato, ma su un forum è facile fraintendere.

A parte questo, però, la discussione originale verteva sul fatto di sentire le differenza fra wtf-play e daphile. Ora, entrambi usano alsa ed entrambi quindi possono essere configurati allo stesso modo in termini di driver. Se quindi li configuri uguali, tu continui a sentire differenze fra daphile e wtf-play? Se si, quindi, attribuisci tale differenza ad un ulterior minor jitter di wtf-play derivante dalla sua architettura (OS+patch)?

[Membro_0017]

@Necro wtfplay avrà 20 processi che girano. daphile ha pure una GUI. ovvio che suona meglio wtfplay per il motivo esposto nella figura. meno context switch tra processi in concorrenza, il processo Player e il driver audio rimangono più 'quanti' di tempo, contigui, in CPU e quindi producono meno jitter. 

[Necro]

@emaspac intendevi che suona meglio wtf-play. Detto questo io cotinuo a pensare che il ragionamento tecnico generale è reale e corretto. Però, su una macchina moderna con risorse di calcolo comunque sovradimensionate, il fatto di avere 20 processi su wtf-play e un po' di più su daphile (ndr, non ha una GUI ma un server web al limite...) non può essere sufficiente per giustificare differenze evidenti all'ascolto ed imputabili esclusivamente alla sola latenza. Diciamo meglio: non lo è stato per me e comunque riproverò senza alcun pregiudizio. Altra domanda: hai mai provato daphile su un futro con un Atom e poi su un nuc con i7? Hai sentito differenze?