Guida a Logitech Media Server, Squeezelite e derivati.

[lucadita]

Ciao sono nuovo su questo forum.
Quali sono le credenziali per collegarsi con ssh?

se ho capito bene la domanda e nel frattempo le credenziali sono rimaste le stesse dall'ultima volta in cui ho usato daphile:
user: root
password: zaq

[bigtube]

Ciao sono nuovo su questo forum.
Quali sono le credenziali per collegarsi con ssh?

Caro tinoza
sei nuovo in questo forum....ma a parte la domanda un po' da "oracolo di Delfi"
che non ti sei preso la briga di chiarire meglio....ti abbiamo risposto gentilmente
in tre....tu nemmeno un grazie....ci hai preso per "bancomat"

Qui a volte i confronti possono essere aspri ma sempre con il massimo rispetto
e considerazione della dignita' personale....vedi di adeguarti...non sei al supermarket del quartiere.

[UnixMan]

Non è cosi Paolo, io ti ascolto sempre con interesse autentico ma se fai il prepotente
facendo finta di non capire le mie misere ragioni di piccolo utente linux io
nel mio piccolo mi incazzo.

Eh!? da quando in qua fornire spiegazioni significa "fare il propotente"?

Io ho solo dato dei consigli utili ed argomentati (che per giunta non implicano alcuna difficoltà aggiuntiva. Tutt'altro). Poi sta a te decidere se seguirli o meno.

Lasciami il diritto di fare le mie scelte .

e come potrei fare diversamente? ...non ti ho mica hackerato il sistema per ri-configurarlo come piace a me!

Comunque, neanche a farlo apposta, mi spiace (perché, contrariamente a quello che a quanto pare credi, sono qui per collaborare costruttivamente e non per criticarti) ma almeno parzialmente sono costretto a smentirti: a quanto pare, il parametro "nrpacks" (del modulo "snd-usb-audio") è obsoleto. Esisteva in una qualche vecchia versione di ALSA, ma in quelle più recenti non c'è più.

Per scoprire se/queli parametri sono disponibili per un dato modulo del vostro sistema basta utilizzare il comando "modinfo" (contrazione di "MODule INFOrmations"). Ad esempio:

modinfo snd-usb-audio

questo è l'output che se ne ottiene con un kernel recente (per chiarezza ho eliminato alcune righe di "alias", che in questo contesto non ci interessano):

filename:       /lib/modules/4.0-2.dmz.2-liquorix-686-pae/kernel/sound/usb/snd-usb-audio.ko
license:        GPL
description:    USB Audio
author:         Takashi Iwai <tiwai@suse.de>
alias:          usb:v*p*d*dc*dsc*dp*ic01isc01ip*in*
[...]
alias:          usb:v0403pB8D8d*dc*dsc*dp*ic*isc*ip*in*
depends:        snd-usbmidi-lib,snd-pcm,snd,snd-hwdep
intree:         Y
vermagic:       4.0-2.dmz.2-liquorix-686-pae SMP preempt mod_unload modversions 686 
parm:           index:Index value for the USB audio adapter. (array of int)
parm:           id:ID string for the USB audio adapter. (array of charp)
parm:           enable:Enable USB audio adapter. (array of bool)
parm:           vid:Vendor ID for the USB audio device. (array of int)
parm:           pid:Product ID for the USB audio device. (array of int)
parm:           device_setup:Specific device setup (if needed). (array of int)
parm:           ignore_ctl_error:Ignore errors from USB controller for mixer interfaces. (bool)
parm:           autoclock:Enable auto-clock selection for UAC2 devices (default: yes). (bool)

quello che ci interessa in questo caso sono le righe "parm:", che indicano tutti i parametri disponibili per il modulo "interrogato". Come puoi vedere, "nrpacks" non è (più) tra questi.

Viceversa "vm.swappiness" è tutt'ora un parametro valido ed in effetti potrebbe essere una buona idea ridurne il valore.

Ora però, se non ti arrabbi, vorrei darti/dare un altro paio di suggerimenti.

1) a meno che non siano in uso, i "moduli" del kernel si possono scaricare e ricaricare "al volo", senza bisogno di riavviare il sistema. Questo non solo può essere comodo per velocizzare le prove, ma consente di accorgersi facilmente di eventuali errori quali parametri obsoleti, errori di sintassi, ecc. Ad es., nel caso di "snd-usb-audio" bastava fermare il player e dare due semplici comandi.

Per "scaricare" (rimuovere) il modulo:

modprobe -v -r  snd-usb-audio

come risultato questo dovrebbe scrivere qualcosa del genere:

rmmod snd_usb_audio
rmmod snd_usbmidi_lib
rmmod snd_rawmidi

Per (ri)caricare il modulo con i nuovi parametri:

modprobe -v snd-usb-audio  nrpacks=1

come risultato questo dovrebbe scrivere qualcosa del genere:

insmod /lib/modules/4.0-2.dmz.2-liquorix-686-pae/kernel/sound/core/seq/snd-seq-device.ko
insmod /lib/modules/4.0-2.dmz.2-liquorix-686-pae/kernel/sound/core/snd-rawmidi.ko
insmod /lib/modules/4.0-2.dmz.2-liquorix-686-pae/kernel/sound/usb/snd-usbmidi-lib.ko
insmod /lib/modules/4.0-2.dmz.2-liquorix-686-pae/kernel/sound/usb/snd-usb-audio.ko index=-2 nrpacks=1

Ma attenzione: dopo ogni comando, dare sempre il comando "dmesg"

dmesg

e leggere attentamente le ultime righe. Da questi messaggi si può capire "come il kernel ha reagito" ai nostri comandi (o anche al collegamento di un nuovo dispositivo, ecc).

Nella fattispecie, dando il comando "dmesg" subito dopo aver provato ad inserire il modulo "snd-usb-audio" con il parametro "nrpacks=1" (con il comando di cui sopra), tra le ultime righe si legge qualcosa del genere:

[ 5920.018756] snd_usb_audio: unknown parameter 'nrpacks' ignored
[ 5920.018996] usbcore: registered new interface driver snd-usb-audio

da cui si capisce subito che c'è qualcosa che non va... (guarda caso è proprio così che mi sono accorto del problema...).


2) Anche il parametro "vm.swappiness" si può cambiare "al volo", senza riavviare, ancora più facilmente (ed in almeno un paio di modi diversi).

La prima cosa che conviene fare è chiedere al kernel come è settato attualmente:

cat /proc/sys/vm/swappiness

che ci ritorna il numero corrispondente (di solito di default è 60).

Per cambiarlo (al volo, ma solo temporaneamente, fino al prossimo riavvio) si può semplicemente "scrivere" il nuovo valore nello stesso file, ad es. così:

echo 10 > /proc/sys/vm/swappiness

N.B.: il file system "/proc" (al pari di "/sys" ed alcuni altri) non rappresenta il contenuto di una memoria di massa ("disco") ma è invece una vera e propria interfaccia interattiva con il kernel sotto forma di file-system ("virtuale"):
*) quando si legge il contenuto di un "file" in /proc (o /sys) in realtà si sta interrogando il kernel (che ci risponde in tempo reale).
*) quando si scrive qualcosa in uno di tali files, in realtà si sta dando un ordine diretto (ed immediato) al kernel stesso.

In alternativa si può anche utilizzare il comando "sysctl", così:

sysctl vm.swappiness=10

anche in questo caso però si tratta di una modifica temporanea.

Per rendere la modifica permanente vale quanto hai giustamente scritto: il parametro va inserito nel file di configurazione di sysctl. Per farlo si può aggiungere il parametro al file "/etc/sysctl.conf" oppure (meglio) si può creare il file "/etc/sysctl.d/99-swappiness.conf" ed aggiungere lì dentro la definizione della variabile, ad es.:

echo "vm.swappiness=10" > /etc/sysctl.d/99-swappiness.conf

Per "attivare" immediatamente tali modifiche (senza bisogno di riavviare il sistema) è sufficiente dire a sysctl di "rileggere" la sua configurazione, ad es. con questo comando:

sysctl --system

(dopo di che per sicurezza conviene comunque verificare che la modifiche sia effettivamente stata applicata con il comando mostrato in precedenza).

Ciò detto, mi viene però da fare un'altra considerazione: perché limitarsi a ridurre la "swappiness" anziché eliminare del tutto lo swap?

Se hai RAM sufficiente (e per i nostri scopi normalmente ne serve ben poca...), Linux può benissimo funzionare anche completamente senza swap!

Per disabilitare "al volo" lo swap basta dare il comando:

swapoff -v -a

(per riattivarlo al volo basta usare "swapon" al posto di "swapoff", con le stesse opzioni "-v" e "-a").

Se si vuole rendere permanente la modifica (facendo cioè in modo che ai riavvii successivi lo swap non venga più attivato) basta commentare (aggiungere un carattere '#' all'inizio de) la riga che definisce la/le partizione/i di swap nel file /etc/fstab, ad es.:

#UUID=41a6e3b3-58cd-15fc-d3a5-fb4629be8cfe   none    swap    sw     0       0

buone prove... :-)

[antonellocaroli]

A me sembra un ottima collaborazione....complimenti ad entrambi!!!

[bigtube]

Eh!? da quando in qua fornire spiegazioni significa "fare il propotente"? ;
........................................omissis.....................................
buone prove... :-)

Paolo cio' che mi ha infastidito e' che non ti voleva arrivare il messaggio seguente:
devo seguire un metodo per il neofita e solo uno per il momento....non posso darne due o tre .....il neofita si è già dato alla fuga.
purtroppo è cosi . So che alcuni hanno dovuto ripetere alcune procedure due o tre volte e se non avessi scritto i passaggi
riducendoli all'osso mi avrebbero detto che scrivevo fesserie o che ero troppo complicato.
Veniamo a noi. Innanzitutto grazie per la lezione che ti ripeto io gradisco a prescindere. Io amo apprendere e aumentare la
mia autonomia di conoscenze anche se purtroppo cio' richiederebbe da parte mia una superiore velocità di acquisizione. Te l'ho detto...son lento.
Che il modulo nrpacks sia ignorato dal kernel lo sapevo gia' proprio dando il comando "dmesg" e ne avevo parlato anche con Fabrizio che l'aveva proposto e che
aveva constatato anche lui con il medesimo comando.Inoltre mi ero letto in rete ampia documentazione in merito.
Tuttavia avevamo osservato empiricamente tutti e due che ometterlo produceva effetti meno graditi in riproduzione....perchè? non lo so....tu hai qualche idea?
Abbiamo deciso di lasciarlo...
argomento swap. Anch'io ho provato a eliminarlo del tutto. Andava meglio non arrivare a questo livello. Il livello nel mio sistema piu' consono sta a 5. Perchè?....idem come sopra.
Quindi nel mio piccolo le prove le ho fatte.....mi piacerebbe a questo punto sentire la tua opinione.

[bigtube]

faccio osservare che in altra sede Bibo mi ha fatto in pratica le stesse domande a proposito dei parametri nrpacks e ovviamente ho dato
la stessa risposta.
Colgo l'occasione per dire che al momento Daphile (modificato) offre una prestazione a dir poco spettacolare e sta mietendo successi presso
gli utenti con significativa costanza. Sono ben accetti consigli e stimoli per ulteriori suggerimenti . Paolo....datti da fare....

[UnixMan]

devo seguire un metodo per il neofita e solo uno per il momento....non posso darne due o tre

Oh... ecco il misunderstanding... incomprensione totale! Non era questo che intendevo!

Io ti ho suggerito (e spiegato) le altre due possibili alternative per lasciare a te la scelta di quale inserire nella guida (dovessi scriverla io, probabilmente sceglierei le label), NON intendevo affatto suggerire di creare confusione includendoci più di una possibilità!

Che il modulo nrpacks sia ignorato dal kernel lo sapevo gia' proprio dando il comando "dmesg" e ne avevo parlato anche con Fabrizio che l'aveva proposto e che aveva constatato anche lui con il medesimo comando. Inoltre mi ero letto in rete ampia documentazione in merito.
Tuttavia avevamo osservato empiricamente tutti e due che ometterlo produceva effetti meno graditi in riproduzione....perchè? non lo so....tu hai qualche idea?

le cose funzionano così: quando il modulo viene caricato (così come quando si avvia un programma), come prima cosa viene eseguita una porzione di codice che fa il "parsing" della stringa che contiene le opzioni. Quando un parametro noto viene riconosciuto viene attivata un'altra parte di codice (specifica) che si occupa di mettere in atto le azioni necessarie affinché (in seguito) il comportamento del modulo sia modificato di conseguenza.

Se invece il parser incontra un parametro sconosciuto, ovviamente di quel "parametro" il software non sa che cosa farsene. In questo caso il codice di quel modulo si limita a scrivere un messaggio di errore ed ignorare il parametro sconosciuto, scartandolo e proseguendo l'esecuzione come se tale opzione/parametro non fosse mai stato specificato.

Una volta che la fase di configurazione iniziale è terminata ed il modulo comincia a svolgere le sue normali funzioni, delle eventuali opzioni sconosciute non rimane traccia alcuna. Invece di "nrpacks=1" potresti anche scriverci "chiù_pilu_pe_tutti=1": il risultato sarebbe esattamente lo stesso.

Ergo, le conclusioni puoi trarle anche da solo: fisicamente non cambia (e non può cambiare) assolutamente nulla. Percettivamente... mai sentito parlare di placebo?

argomento swap. Anch'io ho provato a eliminarlo del tutto. Andava meglio non arrivare a questo livello. Il livello nel mio sistema piu' consono sta a 5. Perchè?....idem come sopra.

In questo caso un effetto concreto di quei settings sul sistema esiste, quindi eventuali "effetti collaterali" che possano in qualche modo influire (indirettamente) sulla riproduzione audio -pur essendo abbastanza improbabili- non si possono escludere del tutto a priori (ancora meno probabile è che tali eventuali effetti siano effettivamente percepibili, ma questo è un'altro discorso). Comunque sia, ammesso (e non concesso) che un tale effetto esista, le ipotesi possibili sono le solite: effetti indiretti sul "timing" dello stream USB e/o sul rumore EM prodotto dal computer. Purtroppo non conosco abbastanza a fondo tutti i dettagli del funzionamento del kernel (che per altro cambiano da una versione all'altra, e perfino da una configurazione all'altra) per poter dare una qualche risposta sensata alla tua domanda.

[bigtube]

Ergo, le conclusioni puoi trarle anche da solo: fisicamente non cambia (e non può cambiare) assolutamente nulla. Percettivamente... mai sentito parlare di placebo?

Non c'è bisogno di essere dei geni.....è lapalissiano....io infatti sull'argomento avrei glissato per le giuste critiche che sarebbero arrivate e puntualmente eccoci qua' a farci la psicoterapia.....siccome
alcuni sono convinti dei benefici....io da buon dottore non mi faccio mancare nessuna risorsa terapeutica somministro senza ritegno ( e non mi vergogno per giunta ). A parte gli scherzi
mi incuriosice sentire il maggior numero di opinioni proprio in senso antropologico.....


per il resto degli interventi comunque sono del tutto convinto dell'efficacia e non posso far altro che consigliarne la attuazione....poi ognuno si farà un giudizio personale.

La prossima mossa sarà sperimentare un'altra patch che stavolta coinvolge Squeezelite. State in campana.....è un colpo epocale .....o no?!!

Ps : Antonio Albanese è impagabile .....

[tinoza]

Ha. Ok grazie

[bigtube]

Patch RT di Squeezelite (player Daphile)

Questo provvedimento ha lo scopo di dare al player Squeezelite in Daphile
il massimo della priorità da parte del kernel quando il software è in
esecuzione.
Per attuare questo obbiettivo eseguiamo l’accesso al terminale di Daphile
La prima necessita’ è sapere come ALSA riconosce le schede audio connesse
al PC, pertanto daremo questo codice:

cat /proc/asound/cards

dopo Invio sulla tastiera avremo piu’ o meno questo risultato

0 Dummy

1 Intel audio 

2 XMOS-USB 2.0

In questo ordine progressivo noi riconosciamo quale numero è
assegnato alla scheda che ci interessa perchè correlata al DAC.
In questo caso il n. è il 2 che corrisponde nel linguaggio di
ALSA ad hw:2,0 che poi è la XMOS-USB 2.0.Fosse stato 1 alsa lo
avrebbe nominato hw:1,0
Bene per eseguire la patch RT si darà questo codice:

echo -e “chrt -f -p 95 /usr/local/bin/squeezelite -o hw:2,0 -p 97 -n yabber1 -z\n$(cat /etc/rc.local | grep -v “^#” | grep -v “^$”)” >/etc/rc.local

Riavvio della macchina . Nuovo accesso al terminale. Per sapere se
la patch è stata introdotta correttamente daremo il comando :

cat /etc/rc.local

se è andato a buon fine avremo questra risposta:

chrt -f 95 /usr/local/bin/squeezelite -o hw:2,0 -p 97 -n yabber1 -z

Lo scheduling RT è stato assegnato a Squeezelite.
Ricordare che la sintassi dei comandi è la garanzia di risultato quindi
massima attenzione a ogni lettera e spazio.

do’ un consiglio : il comando piu’ lungo selezionatelo e copiatelo in un editor
di testo in modo che stia su una sola riga. se lo copiate a mano non potrete
sbagliare gli spazi da lasciare. Se potete incollatelo pari pari usando Putty.