Guida a Logitech Media Server, Squeezelite e derivati.

[UnixMan]

Esistono liberie portabili sia in Java che in C++ che lo fanno, immagino appoggiandosi sugli strumenti dell'OS ospite o mediante un classico polling, come si è sempre fatto...

inotify serve proprio a quello: per evitare il "polling". Anziché dover verificare periodicamente se determinati files (o directory) sono stati modificati, puoi dire al kernel: "se modifichi uno di questi files/direcotries, avvisami" (dato che tutti i file-system sono gestiti dal kernel, il kernel sa sempre se/quando/cosa viene modificato).

b. CPU e rete... Qualche tempo fa con LMS si sono verificati dei problemi in alcuni sistemi a causa delle impostazioni di risparmio energia, nel senso che provocavano dei momentanei dropouts, inizialmente era uscito un plugin che sospendeva lo stand by ora credo sia integrato in LMS, bisogna vedere cosa succede a SL, ma per sicurezza non abiliterei di default le impostazioni di risparmio.

vedi che succede ad usare sempre interfacce e sistemi troppo "astratti"? si finisce per prendere fischi per fiaschi...

Quello di cui stiamo parlando non ha niente a che fare con sospensione o "stand-by" (che tra l'altro sono gestite da processi "user-space", attraverso ACPI, non direttamente dal kernel). Il "governor" della CPU si limita a gestire il “Dynamic CPU frequency scaling (also known as CPU throttling)”, cioè in sostanza a "modulare" la frequenza di funzionamento della CPU in funzione del "carico" momentaneo della stessa.

Le possibili impostazioni sono:

1) "performance", che tende a massimizzare le prestazioni facendo lavorare la CPU (quasi) sempre alla max potenza;
2) "ondemand", che tende a bilanciare prestazioni e consumi (e dissipazione);
3) "powersave", che tende a minimizzare i consumi facendo lavorare la CPU quanto più possibile a potenza ridotta;
4) "userspace", che demanda la gestione della frequenza della CPU ad un processo esterno (in "user space", per l'appunto).

In tutti i casi (tranne l'ultimo, che dipende da cosa decide il processo esterno), la frequenza della CPU è determinata automaticamente e dinamicamente: viene aumentata progressivamente quando il carico cresce e diminuita quando diminuisce. I diversi "governor" (tranne l'ultimo) cambiano semplicemente l'algoritmo che determina le caratteristiche di tale regolazione automatica.

Non ho provato la conversione PCM / DSD, però.

quella immagino che sia inevitabilmente molto ma molto più pesante... forse in quel caso mettere "performance" sul server potrebbe essere utile nel caso si verifichino dei drop-out all'inizio di un brano (dopo non cambia nulla: una volta che il "carico" di CPU è salito al max, tutti e quattro i governor "interni" provvedono automaticamente ad aumentare la frequenza della CPU, se necessario fino al max delle sue possibilità).

[bigtube]

La discussione è interessante e sec. me proficua . Mi sto convincendo che ci vuole un equilibrio di tendenze approcciando linux. Bisogna imparare a usare la shell e
insieme spiegare cosa si sta facendo nella shell per offrire liberta basata su conoscenza. Perchè in questo modo l'utente puo' eseguire certe operazioni perchè ha capito dove possono condurre. E puo approfittare della flessibilita' del sistema in situazioni impreviste o imprevedibili.
Uno script come aasetup è comodo ed efficace ma all'utente sfugge cosa sta succedendo e in caso di problemi non sa' nemmeno da dove partire.
Quindi una guida ragionata con lo strumento shell a me pare utile sempre....ho un problema? la shell e il suo uso basato su una guida ragionata ci porta fuori
dalle secche. Lo script non funziona per i motivi piu' svariati ?....rimango al palo se non so' nemmeno come procedere con la shell per trovare una via d'uscita.

In conclusione ci sono parti della guida che pur con grande sforzo sono risolte in modo non sufficientemente completo. Gli utenti lo fanno intendere
e quindi bisognerebbe integrare cio' che manca e di cui si sente la mancanza . Lo script accelera il processo di ottenimento di un sistema funzionante
ma ne perdiamo il controllo. Forse paradossalmente bisogna fare ricorso di piu alla shell accompagnata pero' dall'esplicazione del razionale che la richiede
e giustifica. Insomma " in medio stat virtus " . Automatizzare è comodo ma se abbiamo capito il processo e' molto meglio.

[marcoc1712]

La discussione è interessante e sec. me proficua . Mi sto convincendo che ci vuole un equilibrio di tendenze approcciando linux. Bisogna imparare a usare la shell e
insieme spiegare cosa si sta facendo nella shell per offrire liberta basata su conoscenza. Perchè in questo modo l'utente puo' eseguire certe operazioni perchè ha capito dove possono condurre. E puo approfittare della flessibilita' del sistema in situazioni impreviste o imprevedibili.
Uno script come aasetup è comodo ed efficace ma all'utente sfugge cosa sta succedendo e in caso di problemi non sa' nemmeno da dove partire.
Quindi una guida ragionata con lo strumento shell a me pare utile sempre....ho un problema? la shell e il suo uso basato su una guida ragionata ci porta fuori
dalle secche. Lo script non funziona per i motivi piu' svariati ?....rimango al palo se non so' nemmeno come procedere con la shell per trovare una via d'uscita.

In conclusione ci sono parti della guida che pur con grande sforzo sono risolte in modo non sufficientemente completo. Gli utenti lo fanno intendere
e quindi bisognerebbe integrare cio' che manca e di cui si sente la mancanza . Lo script accelera il processo di ottenimento di un sistema funzionante
ma ne perdiamo il controllo. Forse paradossalmente bisogna fare ricorso di piu alla shell accompagnata pero' dall'esplicazione del razionale che la richiede
e giustifica. Insomma " in medio stat virtus " . Automatizzare è comodo ma se abbiamo capito il processo e' molto meglio.

Assolutamente daccordo, se sono pigro faccio fare tutto allo script, ma la guida mi permette di approfondire e capire. La guida poi è uno strumento 'vivo' e nel tempo evolve e può contentre argomenti aggiuntivi (ho già consigliato una guida/selezione ai migliori plugin di LMS, per esempio).

Secondo me è questo che distingue un 'prodotto' chiuso da uno aperto.

La maggior complicazione eventualmente recepita del secondo rispetto al primo è solo il sintomo che si può fare di meglio, ma non connaturata in nessun modo con il fatto di essere open di per se, se non per l'innegabile fato che farlo costa di più (bisogna tener conto delle diverse variabili della portabilità, sia nel codice, che nell'eventuale GUI che nella guida).

[marcoc1712]

inotify serve proprio a quello: per evitare il "polling". Anziché dover verificare periodicamente se determinati files (o directory) sono stati modificati, puoi dire al kernel: "se modifichi uno di questi files/direcotries, avvisami" (dato che tutti i file-system sono gestiti dal kernel, il kernel sa sempre se/quando/cosa viene modificato). .

Immaginavo, segnalavo solo che LMS di suo non usa meccanismi simili, quindi nemmeno quello, mentre lo fa un plugin dedicato, che essendo portabile, probabilmente usa meccanismi analoghi (disponibili in librerie C e Java) o come fault back il vecchio e buon polling, ove questo non sia possibile per 'carenze' del kernel.

vedi che succede ad usare sempre interfacce e sistemi troppo "astratti"? si finisce per prendere fischi per fiaschi...

Non si sa mai, se mi capita sottomano il pc di filippo divento una capra stupida come una scimmia ed ubriaca come un cammello!