Migliorare daphile

Progetti, domande e idee sparse sull'autocostruzione di sorgenti digitali per musica "liquida" basate su computer o sistemi dedicati, interfaccie digitali, DAC, ecc.
Rispondi
samhorn
sostenitore
Messaggi: 675
Iscritto il: 24 gen 2011, 19:23
Been thanked: 1 time

Migliorare daphile

Messaggio da samhorn »

Ho trovato questi miglioramenti da fare a daphile
https://lmsuniverse.wordpress.com/migliorare-daphile/
Qualcuno li ha provati?
Simone
Avatar utente
UnixMan
sostenitore
Messaggi: 12086
Iscritto il: 27 ott 2005, 22:34
Località: L'Aquila (Italy)
Has thanked: 77 times
Been thanked: 47 times

Re: Migliorare daphile

Messaggio da UnixMan »

Occhio: ho dato una rapida occhiata e, se non ho visto male, la modifica prevede l'uso di "Jack". Che è sì un ottimo "middleware" (per altro pensato per uso "pro"), ma supporta esclusivamente PCM. Perciò, se usate o volete usare (anche) il DSD, da files nativi e/o attraverso la conversione in real-time PCM->DSD, le modifiche che prevedono l'uso di Jack non sono applicabili.

Per giunta, Jack lavora esclusivamente con sample-rate fisso (prefissato). Quindi non è possibile utilizzare sample-rate diversi da quello pre-impostato (salvo ricampionare). Nella guida che hai indicato, il sample-rate è impostato a 44.1K. Cioè al formato CD: eventuali files HD dovrebbero essere "downsamplati" a 44.1.

Se volete avere la possibilità di ascoltare files "HD" e/o usare l'upsampling in software dovete cambiare quel valore di conseguenza, ad es. a 192K o 384K, ed assicurarvi che tutto ciò che ha sample-rate inferiori a quello venga "upsamplato" al medesimo.

BTW: se volete "giocare" con soluzioni più sofisticate e/o personalizzate rispetto a quanto offerto "out of the box" da Daphile, consiglio di lasciar perdere il medesimo e seguire invece i link qui sotto, dove troverete varie guide per mettere in piedi sistemi del tutto "custom" con LMS+C3PO e Squeezelite-R2 (preferibilmente divisi su due diverse macchine):

http://marcoc1712.it/

http://audiodigitale.eu/

https://www.nexthardware.com/forum/pc-top-software/

In particolare, se disponete di un computer sufficientemente potente da usare come server (LMS+C3PO), ed un dispositivo di uscita audio (DAC) capace di gestire (bene) il DSD (>=DSD128), consiglio di sperimentare la conversione PCM->DSD, con uscita in DSD128 o (meglio) superiore. :wink:
Ciao, Paolo.

«Se tu hai una mela, e io ho una mela, e ce le scambiamo, tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
samhorn
sostenitore
Messaggi: 675
Iscritto il: 24 gen 2011, 19:23
Been thanked: 1 time

Re: Migliorare daphile

Messaggio da samhorn »

recepito :-)
e per quell che riguarda il realtime? se davvero fosse migliorativo, perchè non lo implementano definitivamente senza essere come alternativa...
Simone
Avatar utente
UnixMan
sostenitore
Messaggi: 12086
Iscritto il: 27 ott 2005, 22:34
Località: L'Aquila (Italy)
Has thanked: 77 times
Been thanked: 47 times

Re: Migliorare daphile

Messaggio da UnixMan »

samhorn ha scritto:e per quell che riguarda il realtime? se davvero fosse migliorativo, perchè non lo implementano definitivamente senza essere come alternativa...
esistono versioni di Daphile che usano un Kernel RT, quindi fai presto a provare. :wink:

Personalmente, nel mio sistema (custom, LMS+C3PO+R2, ma basato su Debian, quindi poco a che vedere con Daphile) soluzioni "full RT" le ho sperimentate... e non mi hanno convinto affatto.

Un sistema dedicato e "full RT" che sembra funzionare (e suonare) piuttosto bene è "Audiolinux" (trovi presentazione, discussione e notizie varie in questo topic del forum di NH). È basato su Arch, con tutta una serie di personalizzazioni ed "ottimizzazioni" specifiche per l'uso audio, e supporta diverse possibili opzioni per quanto riguarda il software di riproduzione. Può permettere di ottenere ottimi risultati risparmiando un mucchio di lavoro, ma non è gratuito.
Ciao, Paolo.

«Se tu hai una mela, e io ho una mela, e ce le scambiamo, tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Joseph K
starting member
Messaggi: 168
Iscritto il: 02 mar 2006, 22:56
Località: Italy

Re: Migliorare daphile

Messaggio da Joseph K »

Ed il quale (Audiolinux) souna meglio --- col modalita RT bloccato..
Almeno per me, col sistema mio. Opinione personale.
Di sicuro libera risorse e permette di eseguire operazioni piu pesanti, tipo un filtro piu impegnativo in HQplayer,
il quale e un risultato che ci ripaga con gli interessi subito..

Ciao, George

Ma adesso io mi ritiro -- non e il mio campo..
Avatar utente
UnixMan
sostenitore
Messaggi: 12086
Iscritto il: 27 ott 2005, 22:34
Località: L'Aquila (Italy)
Has thanked: 77 times
Been thanked: 47 times

Re: Migliorare daphile

Messaggio da UnixMan »

Joseph K ha scritto:Ed il quale (Audiolinux) souna meglio --- col modalita RT bloccato..
Almeno per me, col sistema mio. Opinione personale.
Ah-ah! Interessante.
Joseph K ha scritto:Di sicuro libera risorse e permette di eseguire operazioni piu pesanti,
senza alcun dubbio. È uno dei motivi per cui i Kernel "general purpose" non sono RT, e quelli per uso server spesso non includono neanche il supporto RT standard.

Vale la pena di chiarire un paio di cose. Prima di tutto, il significato di "real-time".

Contrariamente a quanto si potrebbe essere portati a pensare, un sistema "real-time" non è un sistema "più veloce", né un sistema che fa le cose più in fretta, o risponde più in fretta.

La caratteristica che definisce un sistema che possa (propriamente) dirsi RT è la natura deterministica della latenza massima.

In parole povere, mentre un sistema non-RT cerca di rispondere il più in fretta possibile, ma non garantisce nulla in merito ai tempi di risposta (che sono casuali e virtualmente illimitati), un sistema RT spesso risponde più lentamente, ma garantisce che la risposta arrivi entro un determinato tempo massimo (che può essere conosciuto a priori).

Questo può essere fondamentale ed imprescindibile in determinati contesti ed applicazioni, ma ha un prezzo. Parte del quale è proprio la minore efficienza del sistema, che porta ad avere una risposta mediamente più lenta, ed un "throughput" inferiore rispetto ad un sistema non-RT.

Oltre ai sistemi RT propriamente detti esistono però anche degli standard più "rilassati", che potremmo dire "quasi-RT". In pratica questi sistemi includono delle funzionalità che permettono di avvicinarsi alle caratteristiche di un sistema RT, cioè in sostanza che permettono di ottenere latenze basse, pur non potendo garantire al 100% che queste siano sempre limitate (entro un dato tempo max).

in questo senso, i Kernel Linux "moderni" sono praticamente tutti "real-time", in quanto includono il supporto per le estensioni real-time standard POSIX. I Kernel "RT" vanno oltre, ed hanno modifiche e funzionalità aggiuntive che consentono di implementare sistemi real-time propriamente detti.

La differenza sta in un "piccolo" ma importante particolare: mentre i Kernel "normali" prevedono al loro interno dei "processi" critici che non possono essere interrotti (dallo scheduler del kernel stesso) finché non hanno completato l'operazione in corso, le versioni "RT" sono "fully pre-emptible", cioè qualsiasi operazione può essere interrotta in qualsiasi momento (o quasi) dallo scheduler. Questo fondamentalmente è ciò che rende possibile garantire la prevedibilità della latenza max.

Sfortunatamente, in pratica questo significa che anche una operazione importante può essere interrotta, causando tempi di esecuzione e ritardi mediamente maggiori di quelli che si avrebbero se si lasciasse che il Kernel faccia quel che ha da fare senza disturbarlo con interruzioni inopportune. Implica inoltre che i diversi "processi" (inclusi quelli interni al Kernel) possono "disturbarsi" a vicenda, potendo dar luogo anche a situazioni di "deadlock", ecc. Le diverse priorità devono essere gestite con la massima cura ed accortezza, altrimenti si rischia di creare soltanto conflitti e problemi a non finire.

In definitiva, a meno che non sia assolutamente necessario (ed IMHO non è proprio il nostro caso), è meglio starne lontani. Specie se non si è più che competenti ed esperti degli innumerevoli dettagli di cui si deve tenere conto per far funzionare bene le cose...
Ciao, Paolo.

«Se tu hai una mela, e io ho una mela, e ce le scambiamo, tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Rispondi
  • Argomenti simili
    Statistiche
    Ultimo messaggio