Daphile con squeezelite modficato per upsampling

[UnixMan]

[...] ma probabilmente /var/lib/squeezeboxserver/Plugins é piú corretto

sì, solito motivo: se si vogliono seguire gli standard ed evitare possibili problemi il contenuto del file system "/usr" (eccetto /usr/local) dovrebbe essere gestito esclusivamente dal package manager. Il software installato manualmente dall'utente dovrebbe andare per l'appunto proprio sotto /usr/local, mentre in "/var" (che sta per "VARiable data") di norma ci vanno i dati "variabili" delle varie applicazioni...

http://en.wikipedia.org/wiki/Filesys...archy_Standard

[marcoc1712]

Per ora non ho toccato niente in convert.conf e ho lasciato solo attivata in flac- pcm. I file che ho provato sono 44.1. Quindi niente up o down sample. Il server è su winzozz. Proveró a seguire i tui consigli marco anche se nel punto a non ho ben chiaro come fare. Grazie

Inviato dal mio Nexus 7 utilizzando Tapatalk

Per il punto a usi le opzioni della riga di comando di squeezelite (fino a che qualcuno dotato di buona volonta non realizzerà il microsito di configurazione...):


In particolare:

-b <stream>:<output> Specify internal Stream and Output buffer sizes in Kbytes

Se non specificati, i valori di default sono

256 Kbytes, 861 Kbytes (2048 e 3446 Kbit).

Daphile imposta (di default) rispettivamente 3072 e 4096 KBytes.

Molto dipende dal formato di trasmissione, la formula usata da Squeezelite è questa:

#define STREAMBUF_SIZE (2 * 1024 * 1024) = 2097152 -> 2048 Kb
#define OUTPUTBUF_SIZE (44100 * 8 * 10) = 3528000 -> 3446 Kb (5 sec. stereo a 44100/16)

Il motivo per cui il primo buffer è più piccolo del secondo è che ipotizza di ricevere files compressi (flac), ma nella nostra configurazione non è così, quindi, volendo mantenere i 5 secondi:

se mandi uno stream a 32/192K hai 8.7 volte la dimensione : 29980.2 Kb, identico anche in ingresso, dato che non usiamo flac ma la conversione avviene sul server.

Ne conseguono 32768 Kb -> 4096 KB, quindi:

-b 4096 :4096 .

Per stream e formati di uscita diversi, basta riapplicare la formula con i parametri corretti.

5 secondi di buffer sono già tanti, ma se hai problemi di dropouts puoi aumentare il primo anche a 8192, ricordati però di aumentare conseguentemente il buffer sul server (ritardo del lettore) è probabile che il problema sia lì.

Se hai sul clinet almeno un 1 GB di RAM, sono valori assolutamente sicuri, puoi anche aumentarli, ma devi assolutamente evitare che il sistema cominci a paginare (scrivere il contenuto della memoria RAM in quella virtuale, su disco) otterresti l'effetto contrario a quello desiderato (motivo per cui io diffido dei ramdisk usati a capocchia).

Sonicamente, non ti so dire, la mia impressione generale è che i buffer ben dimensionati rendano meno 'aspro' il suono (mi riferisco non solo a questi), quindi se hanno un effetto è migliorativo.

Quello che leggi in giro in merito alla latenza, è spesso frutto di confusione tra questi buffer (applicativi) e quelli di Alsa, dei vari sound systems (ASIO, WASAPI,DS,...) dei drivers e dei Kermels...

Quelli applicativi sono gestiti... dall'applicazione, quindi nel caso di LMS non comportano nessuna latenza aggiuntiva (non è così in altri sistemi però) mentre quelli di Alsa e gli altri, per l'applicazione 'non esistono' quindi qui si che si può generare latenza indesiderata. Insisto però nel dire che per la riproduzione domestica, se non si ha sincronizzazione di diverse sorgenti, non è un parametro significativo, mentre lo è in acquisizione (registrazione) o 'live' con monitoring.

Avrai capito, quindi, che dissento da chi consiglia di tenerli il più bassi possibile prima di incorrere in dropouts. All'altro estremo c'è chi dimensiona lo Stream Buffer come un RAM Disk (512 MB >= 10'), così da averlo pieno nel corso dei primi secondi di play, dopo di che anche la rete si ferma. Se ci si assicura che il sistema non pagini MAI può avere un suo razionale, ma non è detto che succeda quello che ci si aspetta, il 'ritmo' della trasmissione lo determina comunque il server.

[marcoc1712]

sì, solito motivo: se si vogliono seguire gli standard ed evitare possibili problemi il contenuto del file system "/usr" (eccetto /usr/local) dovrebbe essere gestito esclusivamente dal package manager. Il software installato manualmente dall'utente dovrebbe andare per l'appunto proprio sotto /usr/local, mentre in "/var" (che sta per "VARiable data") di norma ci vanno i dati "variabili" delle varie applicazioni...

http://en.wikipedia.org/wiki/Filesys...archy_Standard

Qui le indicazioni per LMS nelle diverse piattaforme: Logitech Media Server file locations - SqueezeboxWiki

[marcoc1712]

Nell'attesa di provare C3PO, ieri sera stavo facendo delle prove con l'upsampling di squeezelite (per altro, facendo tutto con una sola macchina, dubito che otterrei chissà quali vantaggi spostando il carico da SL ad ad LMS).

La cosa che ho notato con piacere ( e che mi era sfuggita... ) è che (a differenza di altri software, come ad es. anche MPD, che al più consentono di scegliere solo tra le principali modalità standard) SL permette di sfruttare molto bene la libsoxr, offrendo una completa libertà di personalizzazione. Ci sono delle opzioni (tramite il campo "flags") che credo non siano accessibili neanche dallo stesso sox!

Già, è un programmino abbastanza furbetto. Sulla stessa macchina, in specie se abiliti l'opzione di accesso diretto ai files locali (e non usi i .cue), hai la stessa differenza che avresti usando SOX rispetto ad un programma C (che è negli obiettivi futuri di C-3PO) che usi direttamente libsox.

Anche in questo caso, il 'problema' è solo l'interfaccia utente, squeezeite può essere reso ancora più 'trasparente' rispetto alle opzioni di libsox (o delle altre librerie).

Forse non l'hai notato, ma può essere concatenato a pre e post processori per fare qualsiasi cosa tu voglia fare, daphile ha aggiunto Brute Fir, per esempio, io tempo addietro accarezzavo l'idea di usare SL come bridge verso HQP, così da poterlo comandare da LMS. Fattibile, ma seguendo la lontano l'esperienza con MUSO, ho capito che HQP non ha realmente intenzione di aprirsi, nemmeno tramite API, quindi per il momento è in stand by.

Ci vorrebbe tempo, tempo, tanto tempo...

[antonellocaroli]

Forse non l'hai notato, ma può essere concatenato a pre e post processori per fare qualsiasi cosa tu voglia fare, daphile ha aggiunto Brute Fir, per esempio, io tempo addietro accarezzavo l'idea di usare SL come bridge verso HQP, così da poterlo comandare da LMS. Fattibile, ma seguendo la lontano l'esperienza con MUSO, ho capito che HQP non ha realmente intenzione di aprirsi, nemmeno tramite API, quindi per il momento è in stand by.

Interessante!!!

[marcoc1712]

Interessante!!!

Eh, lo so che ci hai lavorato... Io ho scambiato qualche messaggio con lui, mi ha dato la benedizione, ma non si è fatto coinvolgere, sarebbe molto più lineare. MUSO -> LMS ->HQSqueeze->HQP, sciogliendo anche l'obbligo di avere Muso ed HQP sulla stessa macchina.

Ma va bene lavorare 'agratis' ma pure pagare e pregare no...

[DacPassion]

Nuova beta di Daphile ...non ha aggiornato ancora il nome

[marcoc1712]

Nuova beta di Daphile ...no ha aggiornato ancora il nome

Non mi aspetto lo faccia mai.

[DacPassion]

Almeno su questo sarebbe da "stimolarlo"...

[marcoc1712]

Almeno su questo sarebbe da "stimolarlo"...

Gli ho già scritto, fa orecchie da mercante... non ho bisogno di guerre e francamente non ne vale la pena.