Gentoo: Installazione PC Server (HQPlayer, LMS ) e PC Player (NAA, Mpd, Squeezelite-R2) | Stampa

Quote:

---

Originariamente inviato da bigtube

Pero' io sto aspettando l'autore di Squeezelite-R2....è latitante
Se non si fa' vivo io non la metto la guida in onda:pp:pp
Marcooooo!!!!

---

Eccomi, ma non c'è assolutamente bisogno di me, su Gentoo non poteri aggiungere nulla (sono una capra) e l'ebuild di squeezelite l'ho già visto a suo tempo. E' OK, c'è solo un aspetto che non capisco bene ed è la patch allegata ai sorgenti utile per consentire l'utilizzo di codecs diversi da pcm in gentoo: se viene applicata il risultato dovrebbe essere una 'linea di versioni' diversa da R2 (auspicabilmente con un suo repository in rete, magari come fork di R2) , altrimenti non è necessario in quanto i sorgenti sono esattamente gli stessi, quindi si tratta solo di una 'distribuzione' diversa.

Chiarito questo punto ed operato di conseguenza è tutto perfetto, dal punto di vista della manutenzione di squeezelite.

I sorgenti più che gli stessi sono propio quelli presenti nel tuo github... Cioè non fa altro che scaricarli e compilarli ... Non capisco il fork....distribuzione diversa...manutenzione...


Inviato dal mio iPhone utilizzando Tapatalk

Quote:

---

Originariamente inviato da DacPassion

Perché i 2gb di RAM del futro non bastano per il bufferone?

---

La logica del "bufferone" è questa:

L'intero porcesso è asincrono, cioè è la componente 'a valle' che determina il 'timing' di quelle a monte, quindi occorre distinguere tre fasi distinte del processo:

a. Riempimento iniziale
b. funzionamenti
c. svuotamento finale

Nella fase iniziale, squeezelite chiede al server di 'riempire' il buffer nel minor tempo possibile, il che comporta un 'picco' nelle attività, la cui intensità e durata sono funzione delle impostazioni del client, delle capacità di rete, del server e dello storage (o server remoto). Raggiunto un 'livello' minimo di riempimento del buffer in ingresso, squeezelite inizia la trascodifica, cioè sposta dal buffer di input a quello di output eseguendo le necessarie trasformazioni di formato (nulla nel nostro caso), raggiunto un livello minimo del livelo del buffer di output avvisa ALSA di essere pronto alla riproduzione.

A questo punto ALSA riempe il suo buffer (499 mSec) e raggiunto un livello minimo, inizia a trasferire al (driver del) DAC via USB, ripetendo il gioco per ogni FIFO (o buffer) presente nella catena).

Da questo punto in poi il DAC 'preleva' dalla catena dei buffer fino a quello in uscita all'interfaccia USB in ragione del sample rate e del numero di canali, in modo SINCRONO, cioè con una velocità costante dettata dal clock.

ALSA, invece risponde in modo asincrono, cioè trasferisce una quantità di dati pari alla dimensione del periodo (499/2 = 250 msec) per i canali (2) ed il sample rate ad ogni periodo, chiedendo alla CPU di dedicare un ciclo per farlo. Il carico è estremamente basso, dato che avviene solo 4 volte al secondo.

I buffer a monte reagiscono di conseguenza, man mano vengono svuotati e raggiungono un livello minimo, chiedono alla CPU di essere alimentati e cosi via, Tutti questi cicli di CPU, nel nostro caso, non fanno altro che spostare dati da una locazione di memoria A a B, non essendo richiesta nessuna trascodifica, solo lo svuotamentoi del buffer in input provoca la richiesta al server di inviare nuovi dati, con la conseguente attività di rete.

Se il buffer di output è per dimensioni, identico a quello di ALSA, la cpu lavorerà 8 volte al secondo, se è più grande meno in proporzione inversa, fino al limite del 'mai' quando il brano è di dimensione minore rispetto al buffer stesso.

Lo stesso vale per il buffer in ingresso, ma in questo caso l'attività non è nulla e coinvloge il server e la rete, da qui la scelta di massimizzare le dimensioni di questo buffer rispetto a quello di output, in caso di costrizione di risorse.

NOTA BENE: Tutti i parametri di ALSA vengono trattati come richieste di valori 'il più vicino a' è ALSA che determina i reali valori da utilizzare..

Quote:

---

Originariamente inviato da marcoc1712

c'è solo un aspetto che non capisco bene ed è la patch allegata ai sorgenti

---

non ho guardato, ma presumo sia l'equivalente Gentoo del "pacchetto sorgente" Debian, dei .src.rpm di Fedora/RedHat/CentOS e affini, ecc...

Quote:

---

Originariamente inviato da antonellocaroli

I sorgenti più che gli stessi sono propio quelli presenti nel tuo github... Cioè non fa altro che scaricarli e compilarli ... Non capisco il fork....distribuzione diversa...manutenzione...

Inviato dal mio iPhone utilizzando Tapatalk

---

Nella cartella "Files" dello zip contenete l'ebuild sono presenti, tra gli altri, due files di patch, che altro non sono che 'automazioni' di modifica ai sorgenti:

a. squeezelite-R2-1.8.3-gentoo-makefile.patch
b. squeezelite-R2-1.8.3-gentoo-optional-codecs.patch

il primo è un 'modo' per ottenere il makefile di gentoo, probabilmente necessario all'ebuild, non so, il secondo è la modifica al file decode.c (sorgente di squeezelite) non ho capito SE applicata in fase di build per gento o meno.

Se è li solo come documentazione o proposta, ma non viene applicato, lo eliminerei.

Se è una modifica al sorgente APPLICATA, allora di conseguenza i sorgenti non sono gli stessi, di fatto si tratta di una fork di squeezelite cui viene applicata quella modifica, esattamente come R2 è una modifica di pcm.c. Bada bene, NON di R2, dato che R2 NON modifica decode.c, ma usa lo stesso di squeezelite.

Quote:

---

Originariamente inviato da UnixMan

non ho guardato, ma presumo sia l'equivalente Gentoo del "pacchetto sorgente" Debian, dei .src.rpm di Fedora/RedHat/CentOS e affini, ecc...

---

In parte si e sono le componenti necessarie alla compilzione di squeezelite (non tanto di R2 in se) su Gentoo, ma la patch a decode.c è proprio una modifica ai sorgenti, forse perchè usa librerie diverse. R2 'eredita' decode.c, quindi la patch va eventualmente integrata a livello superiore e li mentenuta, se possibile.

Quote:

---

Originariamente inviato da marcoc1712

b. squeezelite-R2-1.8.3-gentoo-optional-codecs.patch

---

hai guardato cosa fa? magari è banalmente una modifica minore agli #include per correggere qualche path o nome di libreria per permetterne la compilazione su Gentoo... :mmmm

a proposito di questi file patch se volete vi mostro il contenuto ( che è solo testo ) di tutti.....ditemi

squeezelite-R2-1.8.3-gentoo-optional-codecs.patch ( nome del file )

codice HTML:

---

diff --git a/decode.c b/decode.c
index add5fcb..333d76b 100644
--- a/decode.c
+++ b/decode.c
@@ -138,16 +138,26 @@ void decode_init(log_level level, const char *include_codecs, const char *exclud
    if (!strstr(exclude_codecs, "alac") && (!include_codecs || strstr(include_codecs, "alac")))  codecs[i++] = register_ff("alc");
    if (!strstr(exclude_codecs, "wma")  && (!include_codecs || strstr(include_codecs, "wma")))  codecs[i++] = register_ff("wma");
 #endif
+#ifndef SL_NO_AAC
    if (!strstr(exclude_codecs, "aac")  && (!include_codecs || strstr(include_codecs, "aac")))  codecs[i++] = register_faad();
+#endif
+#ifndef SL_NO_OGG
    if (!strstr(exclude_codecs, "ogg")  && (!include_codecs || strstr(include_codecs, "ogg")))  codecs[i++] = register_vorbis();
+#endif
+#ifndef SL_NO_FLAC
    if (!strstr(exclude_codecs, "flac") && (!include_codecs || strstr(include_codecs, "flac"))) codecs[i++] = register_flac();
+#endif
    if (!strstr(exclude_codecs, "pcm")  && (!include_codecs || strstr(include_codecs, "pcm")))  codecs[i++] = register_pcm();
 
    // try mad then mpg for mp3 unless command line option passed
+#ifndef SL_NO_MAD
    if (!(strstr(exclude_codecs, "mp3") || strstr(exclude_codecs, "mad")) &&
        (!include_codecs || strstr(include_codecs, "mp3") || strstr(include_codecs, "mad")))    codecs[i] = register_mad();
+#endif
+#ifndef SL_NO_MPG123
    if (!(strstr(exclude_codecs, "mp3") || strstr(exclude_codecs, "mpg")) && !codecs[i] &&
        (!include_codecs || strstr(include_codecs, "mp3") || strstr(include_codecs, "mpg")))    codecs[i] = register_mpg();
+#endif
 
    mutex_create(decode.mutex);
 
diff --git a/faad.c b/faad.c
index 96d33ca..f994cf3 100644
--- a/faad.c
+++ b/faad.c
@@ -20,6 +20,8 @@
 
 #include "squeezelite.h"
 
+#ifndef SL_NO_AAC
+
 #include <neaacdec.h>
 
 #define WRAPBUF_LEN 2048
@@ -640,3 +642,5 @@ struct codec *register_faad(void) {
    LOG_INFO("using faad to decode aac");
    return &ret;
 }
+
+#endif
diff --git a/flac.c b/flac.c
index a5c7b3b..6240d84 100644
--- a/flac.c
+++ b/flac.c
@@ -20,6 +20,8 @@
 
 #include "squeezelite.h"
 
+#ifndef SL_NO_FLAC
+
 #include <FLAC/stream_decoder.h>
 
 struct flac {
@@ -286,3 +288,5 @@ struct codec *register_flac(void) {
    LOG_INFO("using flac to decode flc");
    return &ret;
 }
+
+#endif
diff --git a/mad.c b/mad.c
index 30e2498..b667900 100644
--- a/mad.c
+++ b/mad.c
@@ -20,6 +20,8 @@
 
 #include "squeezelite.h"
 
+#ifndef SL_NO_MAD
+
 #include <mad.h>
 
 #define MAD_DELAY 529
@@ -412,3 +414,5 @@ struct codec *register_mad(void) {
    LOG_INFO("using mad to decode mp3");
    return &ret;
 }
+
+#endif
diff --git a/mpg.c b/mpg.c
index f3074f2..bcf79d6 100644
--- a/mpg.c
+++ b/mpg.c
@@ -20,6 +20,8 @@
 
 #include "squeezelite.h"
 
+#ifndef SL_NO_MAD
+
 #include <mpg123.h>
 
 #define READ_SIZE  512
@@ -274,3 +276,5 @@ struct codec *register_mpg(void) {
    LOG_INFO("using mpg to decode mp3");
    return &ret;
 }
+
+#endif
diff --git a/vorbis.c b/vorbis.c
index 0809bee..7f258f3 100644
--- a/vorbis.c
+++ b/vorbis.c
@@ -20,6 +20,8 @@
 
 #include "squeezelite.h"
 
+#ifndef SL_NO_OGG
+
 // automatically select between floating point (preferred) and fixed point libraries:
 // NOTE: works with Tremor version here: - Revision 19580: /trunk/Tremor, not vorbisidec.1.0.2 currently in ubuntu
 
@@ -329,3 +331,5 @@ struct codec *register_vorbis(void) {
    LOG_INFO("using vorbis to decode ogg");
    return &ret;
 }
+
+#endif

---

mi pare un file che semplicemente indica a emerge cosa deve compilare per i codec
che utilizzera' squeezelite-R2

aggiunto altro codice per proseguire
vai al post dell'installazione