upsampling (universo LMS/Squeezelite/Squeezeplay)

[blueray]

Infatti dovrebbe esser il resampling lato squeezelite la differenza all' ascolto è netta.

[UnixMan]

Infatti dovrebbe esser il resampling lato squeezelite la differenza all' ascolto è netta.

puoi postare la riga di comando di squeezelite completa, con tutte le opzioni?

[blueray]

puoi postare la riga di comando di squeezelite completa, con tutte le opzioni?

eccola:

nice --20 /usr/local/bin/squeezelite-mc2-i386 -z -p 99 -D -a 7:3:: -b 256:256 -u vL:2:3:28 -o front:CARD=x20,DEV=0

[marcoc1712]

eccola:

nice --20 /usr/local/bin/squeezelite-mc2-i386 -z -p 99 -D -a 7:3:: -b 256:256 -u vL:2:3:28 -o front:CARD=x20,DEV=0

Stai usando un buffer size bassissimo ed anche i buffer 'applicativi' sono molto bassi, NO ROLLOFF, 'solo' 3db di attenuazione, di certo non sarà attufato!

[blueray]

Stai usando un buffer size bassissimo ed anche i buffer 'applicativi' sono molto bassi, NO ROLLOFF, 'solo' 3db di attenuazione, di certo non sarà attufato!

Infatti Marco, suono tutt' altro che "attuffato" anzi ed è una configurazione che sta usando anche Alberto con molte soddisfazioni all' ascolto

[marcoc1712]

Infatti Marco, suono tutt' altro che "attuffato" anzi ed è una configurazione che sta usando anche Alberto con molte soddisfazioni all' ascolto

A mio personalissimo avviso, nel mio impianto, con le mie orecchie... un buffersize <40 ms diventa "vetroso", mentre il period count puoi abbassarlo fino a 2, aumentando il senso di 'velocità'.

Per i buffer applicativi 256 mi sembra realmente troppo basso, meno di 0,1 secondi a 384/32, il rischio di buffer underrun è troppo alto.

Bisogna però considerare che Squeezelite ricalcola l'output buffer in funzione del resample, quindi, in realtà, se entri a 44.100 ed esci a 384.000 quel 256 diventa 2.229, sempre basso, soprattutto se nel contempo hai alzato la profondità a 32 bit, ma almeno siamo nell'ordine di 0.725 s.

Lo scrivo in funzione di chi, invece, fa resampling sul server, in quel caso 256 Kb di buffer sono 0.083 s TROPPO pochi, di certo gli underrun saranno frequenti ed è a mio avviso il motivo della maggiore 'brillantezza' (a mio avviso asperità) del suono, che si stempera con buffer di dimensioni di almeno 4096, sufficienti a contenere un secondo e più di musica a 384/32, per ammorbidirsi ulteriormente con dimensioni 8 o 16 x (65536). L'unico limite è la memoria disponibile, bisogna ASSOLUTAMENTE evitare di costringere il sistema a paginare, ma di certo non succede con 130 Mb di buffer...

A mio parere questa è l'impostazione che più si fa sentire ed io prediligo buffer alti, aumenta di molto la naturalezza, a scapito di velocità e brillantezza, ma mi rendo conto che per qualcuno quello che io definisco smooth - e cerco sempre - può facilmente diventare 'attufato' o assenza di dettaglio.

[blueray]

Ho seguito il tuo consiglio Marco ed ho alzato leggermente il buffer mettendolo a 320 e l' Alsa-count l' ho abbassato a 2 ed effettivamente m la riproduzione è migliorata più corpo agli strumenti riproduzione più "smooth" e molte meno "asperità".

[marcoc1712]

Ho seguito il tuo consiglio Marco ed ho alzato leggermente il buffer mettendolo a 320 e l' Alsa-count l' ho abbassato a 2 ed effettivamente m la riproduzione è migliorata più corpo agli strumenti riproduzione più "smooth" e molte meno "asperità".

Cioè adesso usi -a 7:2:: -b 320:320 ?

Se è così non hai cambiato un granchè, sei sempre attorno al 1/10 secondo. Considera che il default (senza upsample, valido con materiale 44100/16) è

2*1024 : 44100* 8 *10 /1024 -> 2048 : 3446.

Devo però correggere quanto scritto prima, il ricalcolo del buffer in base all'upsampling lo fa SOLO se non lo specifichi manualmente, nel qual caso lo devi fare tu, quindi se lasci 320:320, il 'collo di bottiglia' è il buffer in uscita di 320 Kb, pari a circa 0.12 secondi, tutte le operazioni a monte si adegueranno di conseguenza, compreso l'attività di rete, che sarà distribuita per tutto il periodo di play, invece che concentrata solo nei primi secondi, come avviene con buffer grandi.

Se hai avvertito differenze, probabilmente sei su valori critici e già aumentando quel poco hai ridotto il problema in modo sensibile, ma non è detto tu l'abbia risolto del tutto, fossi in te farei la prova partendo con valori più rilassati (es. lo standard corretto in funzione dell'upsampling che pratichi) per poi diminuirli fino a che non cominci a sentire differenze negative.

Rimango molto perplesso dei 7 ms di buffer per alsa, costringi la CPU ad un interrupt ogni 3.5 ms per muovere pochi K di dati per volta, tra l'altro usando MMAP, ammesso e non concesso che ALSA rispetti quel valore (cosa vedi nel log di squeezelite in merito all'apertura della scheda audio?).

In buona sostanza, stai chiedendo al tuo sistema di lavorare poco ma spesso secondo un profilo ''costante' di attività per tutte le componenti del processo, che - nel tuo caso - comprende:

a. attività di rete.
b. decodifica e upsampling
c. output di alsa

con un sicuro overhead nella sincronizzazione dei processi dovuto all'esigua dimensione del buffer di output. Almeno quello proverei a ridimensionarlo adeguatamente.

Per chi (come me) crede che l'attività del sistema si faccia sentire, questo è un buon modo per palesarlo, come sempre il giudizio sul mi piace/non mi piace è soggettivo.

[UnixMan]

Per la cronaca, sul lato squeezelite io invece attualmente sto usando praticamente tutti i default; questa la linea di comando che viene eseguita:

/usr/bin/squeezelite-R2 -n R2@XXXX -o hw:CARD=D20,DEV=0 -s 127.0.0.1 -m YYYY -x -C 1

(dove "XXXX" è il nome della macchina e "YYYY" il suo MAC address).

Il tutto accoppiato a questa configurazione di C-3PO: C-3PO.jpg


...ed il risultato (nel mio sistema, per i miei gusti, ecc, ecc) è semplicemente eccellente.

IMHO, buona parte del merito è probabilmente da imputare al dithering/noise-shaping.

N.B.: per funzionare con queste impostazioni è necessario rinominare o sostituire l'eseguibile di sox fornito da LMS con una versione più aggiornata (ad es. quello fornito da Debian).

In teoria si dovrebbe ottenere lo stesso identico risultato (anche con la versione di sox fornita con LMS) impostando "3 Byte, 24 bit" nel campo "bit-depth" e scrivendo semplicemente "dither -S" in quello "Additional effects".

P.S.: ho anche messo "nice" a "-20" (max priorità) sia a squeezelite che a LMS, modificando i corrispondenti init scripts per aggiungere l'opzione "--nicelevel -20" al comando "start-stop-daemon".

Questo per quanto riguarda "/etc/init.d/squeezelite":

        start-stop-daemon --start --quiet --nicelevel -20 --pidfile $PIDFILE --exec $DAEMON \
                --test > /dev/null || return 1
        start-stop-daemon --start --quiet --nicelevel -20 --pidfile $PIDFILE --exec $DAEMON \
                --background --make-pidfile -- $DAEMON_ARGS || return 2

questo invece per quanto riguarda "/etc/init.d/logitechmediaserver":

d_start() {
        # Use squeezeboxserver_safe to restart the daemon when
        # it dies. This must be done to handle mysql restarts.
        start-stop-daemon --start --quiet \
                --nicelevel -20 \
                --chuid $SLIMUSER \
                --pidfile $PIDFILE \
                --exec $DAEMON_SAFE \
                --background \
                --make-pidfile \
                -- \
                $DAEMON \
                --prefsdir $PREFSDIR \
                --logdir $LOGDIR \
                --cachedir $CACHEDIR \
                --charset=$CHARSET \
                $SLIMOPTIONS
}

d_start_direct() {
        start-stop-daemon --start --quiet \
                --nicelevel -20 \
                --chuid $SLIMUSER \
                --pidfile $PIDFILE \
                --exec $DAEMON \
                -- \
                --pidfile $PIDFILE \
                --daemon \
                --prefsdir $PREFSDIR \
                --logdir $LOGDIR \
                --cachedir $CACHEDIR \
                --charset=$CHARSET \
                $SLIMOPTIONS
}

(in entrambi i casi, riporto solo la parte modificata).

[marcoc1712]

.

N.B.: per funzionare con queste impostazioni è necessario rinominare o sostituire l'eseguibile di sox fornito da LMS con una versione più aggiornata (ad es. quello fornito da Debian).

Allora ti sei abbassato ad utilizzare gli sporchi trucchi winzozziani!!!
Ma se rinomini quello di LMS, quando reinstalla non ti trovi sia la versione rinominata che quella 'originale'?

Per il resto, credo anch'io che le impostazioni di default di squeezelite vadano più che bene ed infatti il mio setting si discosta pochissimo, in pratica ho solo messo 2 nel period count invece di 4 ed adeguato i buffer all'utilizzo di 48KHz/24 bit invece di 44100/16, 40 à il default per il buffer size di Alsa.

Per il nicelevel hai cambiato il pacchetto, così che al prossimo update verrà aggiornato a tutti?

Per il noise shaping/dither vedrò di inserirlo, ma prima bisogna trovare un modo 'intelligente' per sostituire SOX in modo che non venga rimpiazzato ad ogni update di LMS (intanto fai da cavia e vedi se funziona tutto...).

EDIT: su tuo consiglio ho aggiunto il dither - S alla stringa di comando, che adesso è diventata

"remix -m 1v0.95 2 dither -S"

ed in effetti mi pare che la pulizia in alto sia aumentata, si perde - forse - qualche dettaglio ma l'ascolto è più piacevole e 'leggero'. Bisogna conviverci per un po.