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

[UnixMan]

Ma in effetti non so se é cosa buona che un software abbia maggiore prioritá di un irq hw...

decisamente no. Abbassa la priorità di squeezelite...

[UnixMan]

Io non ho messo R2 tra i processi gestiti da rtirq. Invece, ho impostato la priorità RT del thread di output ad 89 tramite l'opzione "-p". Il mio attuale file di configurazione ("/etc/default/squeezelite"), su Debian:

# Defaults for squeezelite initscript
# sourced by /etc/init.d/squeezelite
# installed at /etc/default/squeezelite by the maintainer scripts

# The name for the squeezelite player:
SL_NAME="R2@$(hostname -s)"

# ALSA output device:
#SL_SOUNDCARD='default:CARD=Set'
#SL_SOUNDCARD='iec958:CARD=D20,DEV=0'
#SL_SOUNDCARD='hw:0,0'
#SL_SOUNDCARD='hw:CARD=Amanero,DEV=0'
SL_SOUNDCARD='hw:CARD=D20,DEV=0'
#SL_SOUNDCARD='hw:CARD=x20,DEV=0'

# Squeezebox server (Logitech Media Server): IP address of your squeezebox 
# server. Usually unnecessary as the server is automatically discovered.
#SB_SERVER_IP='192.168.x.y'
SB_SERVER_IP='127.0.0.1'

# Additional options to pass to squeezelite:
# Please do not include -z to make squeezelite daemonise itself.
# Example Daphile-like settings:
#SB_EXTRA_ARGS='-b 3072:4096 -R -u vME:::28 -x -c flac,pcm,mp3,ogg,dsd -r 44100,48000,88200,96000,176400,192000 -a 100:3:32:1 -p 45'
#
# The following variables are used only locally to build "SB_EXTRA_ARGS".

SB_MAC='-m nn:nn:nn:nn:nn:nn'

# ALSA output device params: -a <b>:<p>:<f>:<m> where:
# <b>   buffer time in milliseconds (values<500) or
#       size in bytes (default 40ms);
# <p>   period count (values<50) or size in bytes (def.=4);
# <f>   sample format (possible values: 16, 24, 24_3 or 32); 
# <m>   whether to use mmap (possible values: 0 or 1).
#
SL_OUT_PARM=''
#SL_OUT_PARM='-a 100:3:32:1'
#SL_OUT_PARM='-a :2'
#SL_OUT_PARM='-a 499:::'
#SL_OUT_PARM='-a 300:3'
#SL_OUT_PARM='-a 499:4' # last good
#recommended by Marco C.:
SL_OUT_PARM='-a 499:2::0'

# Buffering: -b <internal stream>:<output buffer> (KB)
#
SL_BUFFERS=''
#recommended by Marco C.: SL_BUFFERS='-b 1024000:1024000'
SL_BUFFERS='-b 102400:102400'
#SL_BUFFERS='-b 65535:65535'
#SL_BUFFERS='-b 20480:20480'
# good: SL_BUFFERS='-b 10240:10240' 
#SL_BUFFERS='-b 8192:12288'
#SL_BUFFERS='-b 6144:9216'
#SL_BUFFERS='-b 3072:4096'

# Codecs: -c <codec1>,...
# restrict codecs only to those specified. Use -h to get codec list.
#
#SL_CODECS='-c flac,pcm,mp3,ogg,dsd'
#SL_CODECS='-c aif,dsd,wav'
SL_CODECS=''

# Real time priority of output thread (1-99; default 45).
#SL_RTPRIO='-p 45'
#SL_RTPRIO='-p 98'
SL_RTPRIO='-p 89'

# Supported sample rate(s):
#
#SL_RATES='-r 44100,48000,88200,96000,176400,192000'
#SL_RATES='-r 384000'
#SL_RATES='-r 352800-384000'
SL_RATES=''

# Upsampling options (-R|-u 1:2:3:4:5:6:7)
# 1 <recipe>:           [v|h|m|l|q][L|I|M][s][E|X]
# 2 <flags>:            (see man page)
# 3 <attenuation>:      (dB)
# 4 <precision>:        (bits)
# 5 <passband_end>:     (% of Nyquist freq., def=91.3)
# 6 <stopband_start>:   (% of Nyquist freq., def=100)
# 7 <phase_response>    (0-100; 0=M, 25=I, 50=L)
#
#SL_UPSAMPLE='-u vME:::28'      # Daphile
#SL_UPSAMPLE='-u vLE:0:::98'
#SL_UPSAMPLE='-u vIE:0::64:98'
#SL_UPSAMPLE='-u vIE:2::64:98'
#SL_UPSAMPLE='-u vIE:8::64:98'
#SL_UPSAMPLE='-u vMX:32::64:95'
#SL_UPSAMPLE='-u vIX:32::64:90'
#SL_UPSAMPLE='-u vX:60:3:64:91:95:25'
#SL_UPSAMPLE='-u vX:8:3::::50'
SL_UPSAMPLE=''

# SL logging/debugging options:
# -d slimproto=info
# -d stream=info
# -d decode=info
# -d output=info
# -d ir=debug
# -d all=info
# -f /var/log/squeezelite.log
#
SL_LOG_ARGS=''
#SL_LOG_ARGS='-d stream=info -d decode=info -d output=debug -d ir=debug -f /tmp/squeezelite.log'
SL_LOG_ARGS='-d all=debug -d slimproto=info -f /tmp/squeezelite.log'
#
# Add '-D' for DoP DSD support.
# Add "-x" to disable downsampling.
#
SB_EXTRA_ARGS="
        $SB_MAC         \
        -C 1            \
        $SL_BUFFERS     \
        $SL_CODECS      \
        $SL_UPSAMPLE    \
        $SL_RATES       \
        $SL_OUT_PARM    \
        $SL_RTPRIO      \
        $SL_LOG_ARGS    \
"

[antonellocaroli]

Io non ho messo R2 tra i processi gestiti da rtirq. Invece, ho impostato la priorità RT del thread di output ad 89 tramite l'opzione "-p". Il mio attuale file di configurazione ("/etc/default/squeezelite"), su Debian:

Pensavo che quel -p non funzionasse...invece ha un suo senso

gentooplayerP RTapp # ps -eLo rtprio,pri,cmd | grep squeezelite-R2
     -  39 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
     -  39 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
    89 129 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
     -  39 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
     -  19 grep --colour=auto squeezelite-R2

Un thread prende quella prioritá

rtapp chiaramente la "sovrascrive"

gentooplayerP RTapp # ps -eLo rtprio,pri,cmd | grep squeezelite-R2
    75 115 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
    75 115 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
    75 115 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
    75 115 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
     -  19 grep --colour=auto squeezelite-R2

[antonellocaroli]

L´uso eccessivo di cpu da parte della usb potrebbe essere un problema simile a questo?

https://forums.gentoo.org/viewtopic-...6-start-0.html

[marcoc1712]

L´uso eccessivo di cpu da parte della usb potrebbe essere un problema simile a questo?

https://forums.gentoo.org/viewtopic-...6-start-0.html

Per quello che ho potuto capire non is tratta dello stesso problema dello SSD lì riportato, paradossalmente l'uso di CPU da parte del driver USB3 è più lato 'on idle' che non mentre il sistema lavora, nel qual caso raggiunge livelli 'analoghi' a quelli di ethernet (12-15%) mentre on idle arriva nahce a 25%.

Che poi non siano valori significativi, dato che la CPU lavora per un totale del 99,8% è un altro fatto, ma credo che il punto sia che il driver manda 'troppi' interrut alla CPU, che deve comunque rispondere, anche se l'impegno per ogni interrupt è minimo.

Ieri sera, però, facendo delle prove, mi è capitato di verificare come degli 'spegnimenti e riaccensioni ' della JLSOUND (con relativo bump, bump) ed in effetti l'ultimo post di questo THD indirizza verso un problema analogo, verificando con:

dmesg:

[ 6290.649573] perf: interrupt took too long (2513 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
[10444.124193] perf: interrupt took too long (3150 > 3141), lowering kernel.perf_event_max_sample_rate to 63000
[14955.923260] perf: interrupt took too long (3949 > 3937), lowering kernel.perf_event_max_sample_rate to 50000
[23859.892856] perf: interrupt took too long (4937 > 4936), lowering kernel.perf_event_max_sample_rate to 40000

Dove il sample rate, se ben capisco, è la frequenza con cui il driver 'interorga' lo stato del dispositivo e manda l'inetrrupt di controllo. il meccanismo abbassa dinamicamente il numero di richieste , ad evitare che vengano assorbite tutte le risorse disponibili e nel farlo, per qualche ragione, disconnette e riconnette il dispositivo.

Sarei pronto a scommettere che si tratta di una funzionalità di debug lasciata nel codice, che la versione corrente in debian rsolve. Bisognerebbe indagare SE la stessa nuova verisone (di cosa?) è disponibile per gentoo.

N.B::

Si verifica solo con rtIRQ installato MA disattivato, prima di installarlo non is è mai verificato e con il srvizio attivo non mi si è mai verifiato (ancora).

[bigtube]

Per quello che ho potuto capire non is tratta dello stesso problema dello SSD lì riportato, paradossalmente l'uso di CPU da parte del driver USB3 è più lato 'on idle' che non mentre il sistema lavora, nel qual caso raggiunge livelli 'analoghi' a quelli di ethernet (12-15%) mentre on idle arriva nahce a 25%.

Che poi non siano valori significativi, dato che la CPU lavora per un totale del 99,8% è un altro fatto, ma credo che il punto sia che il driver manda 'troppi' interrut alla CPU, che deve comunque rispondere, anche se l'impegno per ogni interrupt è minimo.

Ieri sera, però, facendo delle prove, mi è capitato di verificare come degli 'spegnimenti e riaccensioni ' della JLSOUND (con relativo bump, bump) ed in effetti l'ultimo post di questo THD indirizza verso un problema analogo, verificando con:

dmesg:

[ 6290.649573] perf: interrupt took too long (2513 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
[10444.124193] perf: interrupt took too long (3150 > 3141), lowering kernel.perf_event_max_sample_rate to 63000
[14955.923260] perf: interrupt took too long (3949 > 3937), lowering kernel.perf_event_max_sample_rate to 50000
[23859.892856] perf: interrupt took too long (4937 > 4936), lowering kernel.perf_event_max_sample_rate to 40000

Dove il sample rate, se ben capisco, è la frequenza con cui il driver 'interorga' lo stato del dispositivo e manda l'inetrrupt di controllo. il meccanismo abbassa dinamicamente il numero di richieste , ad evitare che vengano assorbite tutte le risorse disponibili e nel farlo, per qualche ragione, disconnette e riconnette il dispositivo.

Sarei pronto a scommettere che si tratta di una funzionalità di debug lasciata nel codice, che la versione corrente in debian rsolve. Bisognerebbe indagare SE la stessa nuova verisone (di cosa?) è disponibile per gentoo.

N.B::

Si verifica solo con rtIRQ installato MA disattivato, prima di installarlo non is è mai verificato e con il srvizio attivo non mi si è mai verifiato (ancora).

oh bella....finisce che rtirq lo togliamo tutti al volo....usiamo tutti la jlsounds

[antonellocaroli]

oh bella....finisce che rtirq lo togliamo tutti al volo....usiamo tutti la jlsounds

???? perché??

Si verifica solo con rtIRQ installato MA disattivato, prima di installarlo non is è mai verificato e con il srvizio attivo non mi si è mai verifiato (ancora).

questo é strano....rtIRQ é uno script....se non lo avvii non ha nessun impatto sul sistema....l´installazione non fa altro che mettere i file di conf a loro posto e l´init script al suo....perché la semplice installazione dovrebbe avere qualche effetto?

[marcoc1712]

oh bella....finisce che rtirq lo togliamo tutti al volo....usiamo tutti la jlsounds

Io credo che il porblema non sia la JLSOUND, ma piuttosto il driver intell di USB3 presente sul sistema, su debian è stato risolto da una upgrade, FIlippo riporta che con driver diversi (per hw diversi) non sucede.

Sarebbe meglio trovare la maniera di cambiare driver...

[marcoc1712]

Pensavo che quel -p non funzionasse...invece ha un suo senso

gentooplayerP RTapp # ps -eLo rtprio,pri,cmd | grep squeezelite-R2
     -  39 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
     -  39 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
    89 129 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
     -  39 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
     -  19 grep --colour=auto squeezelite-R2

Un thread prende quella prioritá

rtapp chiaramente la "sovrascrive"

gentooplayerP RTapp # ps -eLo rtprio,pri,cmd | grep squeezelite-R2
    75 115 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
    75 115 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
    75 115 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
    75 115 /usr/bin/squeezelite-R2 -C 1 -o hw:CARD=J20,DEV=0 -p 89 -b 1024000 1024000 -a 499 2  0
     -  19 grep --colour=auto squeezelite-R2

IL THD cui squezelite modifica la priorità è quello di OUTPUT, cioè quello che muove dal buffer applicativo di output (-b in:out) verso quello di alsa (499:3::0)) mediante le opportune chiamate alle API di ALSA che poi inoltra alla scheda audio via USB. In pratica il player vero e propio.

Se c'è un senso, allora direi che questo modo è certamente meglio che non quello di rtirq, che non tocca le priorita del processo di out ed anche di rtapp, che li alza tutti indistintamente.

Rimane invariato il punto di se conviene o meno assegnare ad un porcesso applicativo priorità più alta rispetto a processi di sistema ed anche se in situzioni senza contenzioso ha un senso tout court, rtIRQ sicuramente provoca qualcosa ed a mio avviso si sente anche, senza sapere se i due effetti sono direttamente collegati e nemmeno se sono legati alla latenza o meno.

[bigtube]

IL THD cui squezelite modifica la priorità è quello di OUTPUT, cioè quello che muove dal buffer applicativo di output (-b in:out) verso quello di alsa (499:3::0)) mediante le opportune chiamate alle API di ALSA che poi inoltra alla scheda audio via USB. In pratica il player vero e propio.

Se c'è un senso, allora direi che questo modo è certamente meglio che non quello di rtirq, che non tocca le priorita del processo di out ed anche di rtapp, che li alza tutti indistintamente.

Rimane invariato il punto di se conviene o meno assegnare ad un porcesso applicativo priorità più alta rispetto a processi di sistema ed anche se in situzioni senza contenzioso ha un senso tout court, rtIRQ sicuramente provoca qualcosa ed a mio avviso si sente anche, senza sapere se i due effetti sono direttamente collegati e nemmeno se sono legati alla latenza o meno.

In cosa consiste....vediamo se abbiamo le stesse idee