Guida a Logitech Media Server, Squeezelite e derivati.

[marcoc1712]

Risolto il problema di Squeeze Player, che si registra come player in LMS. Mi è bastato togliere la spunta da "Abilita 'stdIn' (es. Qobuz)" per tutti i file e la riproduzione avviene normalmente.
Invece il problema di foobar non so come intervenire...

Non capisco la relazione tra squeezeplay (vecchia versione di suqeezelite) e STDIN, mi riesci a postare l'ultimo comando usato (da C-3PO) nelle condizioni in cui ti dava errore?

Grazie.

Non hai toccato null'altro? (se uscivi in wav magari con resample, è normale quel tipo di errore con squeezeplay, serve R2).

Con foobar c'è di mezzo il plugin SqueezeUPNP con le sue impostazioni, probabilmente foobar si presenta coma capace solo di mp3, o il plugin è impostato per mp3, non so, anche in questo caso puoi vedere il comando da C-3PO e postarlo.

[Miclaud]

Avrei un quesito da porvi. Sto provando in questo momento a suonare "Skeleton Tree" di Nick Cave. Semplice album in flac.

La mia configurazione al momento è:

- LMS Server: un notebook con CPU i3-3217U, 8GB di RAM e disco SSD. La musica è provvisoriamente memorizzata in questo SSD interno. Uso C-3PO
- Squeezelite player: un cubox con processore arm quad core e 2 gb di RAM, in alternativa un thin-client con CPU Atom N270 e 2 GB di RAM

Ho un DAC con ingresso Amanero e supporto per Dop.

Con entrambi i player uso senza problemi il flusso in PCM fino a frequenza 384000.
Usando il formato DSF, non ho nessun problema anche con DSD64 mentre con DSD128 ho invece frequentissimi microsalti durante la riproduzione dei brani di questo album. Usando htop ho verificato le risorse sia del server che del player, ma il primo al massimo consuma 45% di CPU (nel complesso, i singoli core sono piuttosto scarichi) mentre il player è a un carico molto basso.
Il bello è che invece con un altro album, anche lui in flac e alla stessa campionatura originale 44khz/16bit, non ho il minimo problema anche in DSD128

Da cosa può essere dovuto il problema? I due pc sono collegati tramite un piccolo switch che lavora in ethernet 100Mbit, non conosco l'impegno di banda del flusso in DSD... possibile riesca a saturarlo?

Il mio player al momento gira con la seguente configurazione:
squeezelite-R2 -n Praim -d all=debug -f /var/log/squeeze-dsd.log -b 572864:572864 -D 50:dop -o iec958:CARD=Amanero,DEV=0



Vi ringrazio per ogni eventuale parere da parte vostra

[antonellocaroli]

Avrei un quesito da porvi. Sto provando in questo momento a suonare "Skeleton Tree" di Nick Cave. Semplice album in flac.

La mia configurazione al momento è:

- LMS Server: un notebook con CPU i3-3217U, 8GB di RAM e disco SSD. La musica è provvisoriamente memorizzata in questo SSD interno. Uso C-3PO
- Squeezelite player: un cubox con processore arm quad core e 2 gb di RAM, in alternativa un thin-client con CPU Atom N270 e 2 GB di RAM

Ho un DAC con ingresso Amanero e supporto per Dop.

Con entrambi i player uso senza problemi il flusso in PCM fino a frequenza 384000.
Usando il formato DSF, non ho nessun problema anche con DSD64 mentre con DSD128 ho invece frequentissimi microsalti durante la riproduzione dei brani di questo album. Usando htop ho verificato le risorse sia del server che del player, ma il primo al massimo consuma 45% di CPU (nel complesso, i singoli core sono piuttosto scarichi) mentre il player è a un carico molto basso.
Il bello è che invece con un altro album, anche lui in flac e alla stessa campionatura originale 44khz/16bit, non ho il minimo problema anche in DSD128

Da cosa può essere dovuto il problema? I due pc sono collegati tramite un piccolo switch che lavora in ethernet 100Mbit, non conosco l'impegno di banda del flusso in DSD... possibile riesca a saturarlo?

Il mio player al momento gira con la seguente configurazione:
squeezelite-R2 -n Praim -d all=debug -f /var/log/squeeze-dsd.log -b 572864:572864 -D 50:dop -o iec958:CARD=Amanero,DEV=0



Vi ringrazio per ogni eventuale parere da parte vostra

Non so se dipende da quello, anzi, sicuramente no, ma quel "-D 50:dop" cos é? credo non sia una opzione valida e probabilmente in auto squeezelite vada in dop...ma sarebbe meglio mettere solo direttamente -D e basta...

PS: prova a togliere il -b 572864:572864

[Miclaud]

Non so se dipende da quello, anzi, sicuramente no, ma quel "-D 50:dop" cos é? credo non sia una opzione valida e probabilmente in auto squeezelite vada in dop...ma sarebbe meglio mettere solo direttamente -D e basta...

PS: prova a togliere il -b 572864:572864

Ciao Filippo, grazie ancora per il tuo aiuto!

In realtà sia il 50:dop (confermo che il dop viene preso di default, ma si può comunque specificare, almeno leggendo l'help) che il buffer sono cose che ho aggiunto io cercando di risolvere il problema.

La stringa che ho sempre usato è questa:
squeezelite-R2 -n Praim -d all=debug -f /var/log/squeeze-dsd.log -o iec958:CARD=Amanero,DEV=0


Ho però scoperto qualcosa in più. Questo file non è un classico 44/16!

Usando soxi ho scoperto questo:

soxi 01\ Jesus\ Alone.flac

Input File : '01 Jesus Alone.flac'
Channels : 2
Sample Rate : 44100
Precision : 24-bit
Duration : 00:05:52.25 = 15534372 samples = 26419 CDDA sectors
File Size : 66.5M
Bit Rate : 1.51M
Sample Encoding: 24-bit FLAC

In effetti altre volte mi è successo con file ad alta risoluzione, nella conversione in DSD. Ribadisco che la CPU non soffre minimamente, hai qualche idea sul perché con i file in HD dia questo problema? Che verifiche potrei fare?

[marcoc1712]

Ciao Filippo, grazie ancora per il tuo aiuto!

In realtà sia il 50:dop (confermo che il dop viene preso di default, ma si può comunque specificare, almeno leggendo l'help) che il buffer sono cose che ho aggiunto io cercando di risolvere il problema.

La stringa che ho sempre usato è questa:
squeezelite-R2 -n Praim -d all=debug -f /var/log/squeeze-dsd.log -o iec958:CARD=Amanero,DEV=0


Ho però scoperto qualcosa in più. Questo file non è un classico 44/16!

Usando soxi ho scoperto questo:



In effetti altre volte mi è successo con file ad alta risoluzione, nella conversione in DSD. Ribadisco che la CPU non soffre minimamente, hai qualche idea sul perché con i file in HD dia questo problema? Che verifiche potrei fare?

DSD158 = 11.289.600 b/sec, in una rete T100 non dovrebbe essere un problema, ma tu sia con la riga di prima che con quella attuale non stai usando DSD128 ma DOP, con che bitrate dipende dalle impostazioni di C-3PO. Al di la del dato medio, non ci sono mai picchi della CPU al 100%?

p.s.
50:dop significa un ritardo di 50 msec nel passaggio tra pcm e dsd.

[Miclaud]

DSD158 = 11.289.600 b/sec, in una rete T100 non dovrebbe essere un problema, ma tu sia con la riga di prima che con quella attuale non stai usando DSD128 ma DOP, con che bitrate dipende dalle impostazioni di C-3PO. Al di la del dato medio, non ci sono mai picchi della CPU al 100%?

p.s.
50:dop significa un ritardo di 50 msec nel passaggio tra pcm e dsd.

Ciao! Sì, nella mia ignoranza ho pensato che un ritardo potesse aiutare. Dopo averlo impostato ho l'impressione che per un paio di secondi "regga", poi però iniziano inesorabili i salti. Come se fosse qualcosa legato a un buffer che si svuota e non riesce a rimanere al passo con la riproduzione (tutte supposizioni, eh, conosco ancora poco la teoria che sta dietro la riproduzione nel mio setup).

Uso DOP perché se non sbaglio l'Amanero che uso non supporta DSD nativo. Ora mi informo meglio su questo aspetto.

Ad ogni modo, se può essere utile per descrivere meglio il mio setup, nel mio LMS imposto il formato DSF e abilito il solo DSD128 tra i formati disponibili.

[marcoc1712]

Ciao! Sì, nella mia ignoranza ho pensato che un ritardo potesse aiutare. Dopo averlo impostato ho l'impressione che per un paio di secondi "regga", poi però iniziano inesorabili i salti. Come se fosse qualcosa legato a un buffer che si svuota e non riesce a rimanere al passo con la riproduzione (tutte supposizioni, eh, conosco ancora poco la teoria che sta dietro la riproduzione nel mio setup).

Uso DOP perché se non sbaglio l'Amanero che uso non supporta DSD nativo. Ora mi informo meglio su questo aspetto.

Ad ogni modo, se può essere utile per descrivere meglio il mio setup, nel mio LMS imposto il formato DSF e abilito il solo DSD128 tra i formati disponibili.

I sintomi indicano che quanto sta dietro al DAC non tiene il passo, quale sia l'elemento è difficile dirlo, potrebbe essere qualsiasi cosa. Il file dov'è? Se è su un NAS, devi aggiungere il traffico per spostarlo sul server, quindi la banda usata aumenta.

Puoi giocare con i Buffer, se aumentandoli migliora, significa che il problema non è a monte del player, altrimenti non riuscirebbe comunque a mantenerli minimamente pieni, il fatto che migliori con un leggero ritardo, però, sembra indicare esattamente il contrario. Puoi aumentare il ritardo del playback fino a qualche secondo in Player -> Audio, ma sono tutti palliativi, hai un collo di bottiglia e quello va eliminato.

La prova empirica più significativa da fare è provare a suonare un file DSD128 (magari il tuo convertito staticamente), se non da problemi allora non è un problema di banda. Prima di tutto però prova ad aumentare anche il buffer di ALSA, almeno a 120:3 o 240:4.

Comunque, testando Leia, sono incappato anch'io in file FLAC xx/24 che danno problemi a SOX, non solo convertendoli in DSD, non so dirti da dove arrivassero, ero su librerie di terzi.

[Miclaud]

I sintomi indicano che quanto sta dietro al DAC non tiene il passo, quale sia l'elemento è difficile dirlo, potrebbe essere qualsiasi cosa. Il file dov'è? Se è su un NAS, devi aggiungere il traffico per spostarlo sul server, quindi la banda usata aumenta.

Puoi giocare con i Buffer, se aumentandoli migliora, significa che il problema non è a monte del player, altrimenti non riuscirebbe comunque a mantenerli minimamente pieni, il fatto che migliori con un leggero ritardo, però, sembra indicare esattamente il contrario. Puoi aumentare il ritardo del playback fino a qualche secondo in Player -> Audio, ma sono tutti palliativi, hai un collo di bottiglia e quello va eliminato.

La prova empirica più significativa da fare è provare a suonare un file DSD128 (magari il tuo convertito staticamente), se non da problemi allora non è un problema di banda. Prima di tutto però prova ad aumentare anche il buffer di ALSA, almeno a 120:3 o 240:4.

Comunque, testando Leia, sono incappato anch'io in file FLAC xx/24 che danno problemi a SOX, non solo convertendoli in DSD, non so dirti da dove arrivassero, ero su librerie di terzi.

Grazie, consigli preziosissimi! Proverò stasera a fare qualche test

[UnixMan]

Ho un DAC con ingresso Amanero e supporto per Dop.

La Amanero supporta anche DSD nativo (se il tuo non lo fa potresti aver bisogno di aggiornare il firmware), che è molto meglio (anche dal punto di vista della qualità del suono... metà banda=meno disturbi, probabilmente). Ovviamente sul "player" (cubox o thin-client che sia) hai bisogno di un Kernel recente con una versione aggiornata di ALSA, che includa il supporto per il DSD nativo (e la cmd line di squeezeplay va modificata opportunamente).

Usando il formato DSF, non ho nessun problema anche con DSD64 mentre con DSD128 ho invece frequentissimi microsalti durante la riproduzione dei brani di questo album. Usando htop ho verificato le risorse sia del server che del player, ma il primo al massimo consuma 45% di CPU (nel complesso, i singoli core sono piuttosto scarichi)

Per caso hai abilitato il multi-threading di SoX? Nel caso prova a disabilitarlo. In diverse versioni l'implementazione ha qualche problema e, anziché migliorare la situazione, la peggiora notevolmente. Nel dubbio, meglio che SOX giri in single thread su un solo core.

Da cosa può essere dovuto il problema? I due pc sono collegati tramite un piccolo switch che lavora in ethernet 100Mbit, non conosco l'impegno di banda del flusso in DSD... possibile riesca a saturarlo?

di certo non la banda nominale, che è ampiamente sovrabbondante. Vero che gli switch per uso domestico (e/o economici) possono soffrire di problemi di latenze esagerate e/o banda effettiva di gran lunga inferiore a quella nominale, ma c'è tanto di quel margine che è improbabile che il problema sia lì. Tanto più che se il problema fosse lì non dovresti notare differenze tra un tipo di file ed un altro (in ingresso) dato che, dopo la conversione, gli stream DSF in uscita sulla rete sono tutti uguali, a prescindere dal formato di partenza.

Il mio player al momento gira con la seguente configurazione:
squeezelite-R2 -n Praim -d all=debug -f /var/log/squeeze-dsd.log -b 572864:572864 -D 50:dop -o iec958:CARD=Amanero,DEV=0

non usare "iec958", che va usato solo nel caso di uscita su S/PDIF o Toslink (PCM, eventualmente codificato AC3). Usa sempre il raw device: "hw:CARD=Amanero,DEV=0".

[Miclaud]

Ciao Paolo (giusto...? ), grazie anche a te per l'aiuto.

La Amanero supporta anche DSD nativo (se il tuo non lo fa potresti aver bisogno di aggiornare il firmware), che è molto meglio (anche dal punto di vista della qualità del suono... metà banda=meno disturbi, probabilmente). Ovviamente sul "player" (cubox o thin-client che sia) hai bisogno di un Kernel recente con una versione aggiornata di ALSA, che includa il supporto per il DSD nativo (e la cmd line di squeezeplay va modificata opportunamente).

Il firmware attualmente in uso non dovrebbe supportare DSD nativo, sto valutando di aggiornarlo ma devo assicurarmi che non dia problemi con il DAC Buffalo II al quale è interfacciato con qualche ricerca.

Al momento il kernel nel cubox, operativo in una Gentoo che ho appositamente installato, è questo:

Linux lms-cubox 4.19.10-rt-rt8 #2 SMP PREEMPT RT Fri Apr 26 14:54:37 CEST 2019 armv7l ARMv7 Processor rev 10 (v7l) Freescale i.MX6 Quad/DualLite (Device Tree) GNU/Linux

Mentre Alsa:

alsactl -v
alsactl version 1.1.8

aplay --version
aplay: version 1.1.8 by Jaroslav Kysela <perex@perex.cz>

Per caso hai abilitato il multi-threading di SoX? Nel caso prova a disabilitarlo. In diverse versioni l'implementazione ha qualche problema e, anziché migliorare la situazione, la peggiora notevolmente. Nel dubbio, meglio che SOX giri in single thread su un solo core.

Ho provato a leggere la sezione "comandi risultanti" di C-3PO (presumo essere la sezione dove si descrive il comando effettivamente eseguito nelle varie conversioni) e nel mio caso ho questo

flc dsf * d0:63:b4:00:27:1f
# I noArgs, F noArgs, D RESAMPLE=-r %d, R noArgs

[flac] -dcs --totally-silent $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t dsf -b 1 --buffer 32768 --multi-threaded - gain -h rate -v -I -b 90.7 -f 5644800 sdm -f sdm-8

Ho provato quindi a disattivarlo, purtroppo non risolve il problema, però lo lascerò single-thread. Grazie per la dritta!
Anche alzare il parametro "--buffer" a 128 non ha aiutato.

Tanto più che se il problema fosse lì non dovresti notare differenze tra un tipo di file ed un altro (in ingresso) dato che, dopo la conversione, gli stream DSF in uscita sulla rete sono tutti uguali, a prescindere dal formato di partenza.

Giusta osservazione.

non usare "iec958", che va usato solo nel caso di uscita su S/PDIF o Toslink (PCM, eventualmente codificato AC3). Usa sempre il raw device: "hw:CARD=Amanero,DEV=0".

Ok, grazie!


[QUOTE=marcoc1712;994949]I sintomi indicano che quanto sta dietro al DAC non tiene il passo, quale sia l'elemento è difficile dirlo, potrebbe essere qualsiasi cosa. Il file dov'è? Se è su un NAS, devi aggiungere il traffico per spostarlo sul server, quindi la banda usata aumenta.
[QUOTE]

I file di prova che sto usando sono nello stesso SSD della Gentoo che esegue LMS, quindi la miglior situazione possibile. Escluderei quindi un collo di bottiglia sull I/O con i file della libreria musicale.

Puoi giocare con i Buffer, se aumentandoli migliora, significa che il problema non è a monte del player, altrimenti non riuscirebbe comunque a mantenerli minimamente pieni, il fatto che migliori con un leggero ritardo, però, sembra indicare esattamente il contrario. Puoi aumentare il ritardo del playback fino a qualche secondo in Player -> Audio, ma sono tutti palliativi, hai un collo di bottiglia e quello va eliminato.

Ho provato a impostare "-D 3000:dop". In effetti - posto che il brano inizia chiaramente 2-3 secondi dopo l'avvio - riesce a reggere molto di più. A volte sono riuscito ad eseguire un intero brano con giusto un paio di microsalti, mentre passando alla traccia successiva i salti sono iniziati dopo pochi secondi, ma comunque molti di più rispetto all'uso senza delay iniziale, con il quale i salti iniziano praticamente da subito.

La prova empirica più significativa da fare è provare a suonare un file DSD128 (magari il tuo convertito staticamente), se non da problemi allora non è un problema di banda. Prima di tutto però prova ad aumentare anche il buffer di ALSA, almeno a 120:3 o 240:4.

Come mi consigli di convertirlo? Posso usare sox da riga di comando o è necessario usare cose tipo Saracon?


Comunque, impostando il buffer a 120:3 la riproduzione funziona bene!

Ora però mi piacerebbe capire questa cosa strana: provando al volo un altro server lms, ovvero il notebook dal quale vi sto scrivendo, dove gira la Ubuntu che uso normalmente per lavorare e fare tutto il resto, il tutto funziona a meraviglia! E pensate che raggiungo il player dalla wifi, quindi neanche usando la ethernet.
Ok, è un notebook molto più potente perché ha 16GB di RAM e una CPU i7-7500U, ma anche l'altro con i3 non aveva picchi di carico sulla CPU (anche se curiosamente hanno entrambi il carico medio al 50% durante la riproduzione. Mi sarei aspettato molto meno carico su una CPU decisamente più potente dell'i3)


edit: ho messo a confronto le impostazioni delle due LMS, sia quella dell'i3 di riferimento che dell'i7 del mio notebook. Ho scoperto che nell'i7, dove tutto funziona a meraviglia, ho il buffer a 8



Impostandolo ad 8 anche nell'LMS dell'i3 funziona alla perfezione, senza neanche dover impostare il buffer alsa a 120:3!
Quale può essere il motivo per il quale il buffer di C-3PO influisca in questo modo?


Recapitolando, al momento attuale il mio comando è questo:

"/usr/bin/flac" -dcs --totally-silent -- - | "/usr/bin/sox" -q -t wav - -t dsf -b 1 --buffer 8192 - gain -h rate -v -I -b 90.7 -f 5644800 sdm -f sdm-8