upsampling (universo LMS/Squeezelite/Squeezeplay)

[antonellocaroli]

Filippo, scusa se ti correggo ma sull'argomento c'è già abbastanza confusione. Squeezelite usa libsoxr (è l'unica libreria sox presente nella cartela di installazione) non libsox0.

Un picco iniziale, specialmente con Output buffer alto, è normale, dato che per evitare i classici problemi al cambio di frequenza di campionamento tra tracce successive, LMS 'ricostruisce' il buffer solo ad inizio traccia.

Allo stesso scopo probabilmente fa ripartire l'applicazione SOX.exe, bisognerebbe verificare.

La verità e che LMS in se non sa nulla di resampling e conversioni, le 'delega' ad eseguibili esterni (SOX), con tutte le - possibili - inefficienze (e complicazioni) del caso, mentre Squeezelite include il software necessario come libreria, un metodo potenzialmente molto più efficiente.

In ogni caso 25% (di un core, spero) di un i7 è tantissimo.

Giusta precisazione!!!
comunque il 25% di uso é per pochi secondi....

[UnixMan]

Ho messo questi parametri ma solo fino a 352K. A un primo ascolto sembra molto molto buono ma il mio PC non regge,cpu alle stelle e talvolta dropout.....il mio PC non ce la fa'...non è adeguato alla richiesta.....

strano. Che macchina usi?

...io non ho nessun problema a fare resampling con sox (da riga di comando Linux, non con LMS) con un ormai vecchiotto "core2 duo" neanche dei più performanti (ed anche con le opzioni più pesanti il processo è ben lungi dal "saturare" la CPU).

BTW:

[flac] -dcs $START$ $END$ -- $FILE$ | [sox] -q -t wav - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 352000 dither -S

come mai "-b 24" e non "-b 32"? è (solo) quello il formato che accetta LMS?

(in caso contrario probabilmente conviene uscire con lo stesso formato utilizzato internamente da sox, cioè a 32bit).

Prove di ascolto no...ho visto solo se funzionava...anche se da un ascolto fugace e superficiale sembra migliore fatto da LMS...

quello probabilmente è molto dipendente dalle opzioni che dai a sox... con squeezelite sei limitato a dover scegliere tra pochi "preset", mentre con LMS ("pipe" sox a linea di comando) puoi giocare quasi all'infinito nel personalizzare come vuoi l'algoritmo di resampling.

ma con un picco di uso della cpu (appena inizia la song) anche del 25% poi si stabilizza al 2% usato da sox.exe...

stando a quanto ho letto in giro (anche qui), il picco iniziale potrebbe avere a che fare più con la libreria che con il resampling (il 25% iniziale è complessivo o si riferisce al solo processo di sox?).

Questo a meno che LMS non riempia un buffer con i dati già pre-processati, nel qual caso inizialmente potrebbe ricampionare i dati alla massima velocità possibile prima di assestarsi su quella media dello stream, cosa che ovviamente causerebbe un sensibile "picco" iniziale.

Non c'è modo di farglielo fare con libsox anche a LMS ?

ni. LMS è scritto in Perl, il che significa che non puoi utilizzare direttamente la libsoxr da LMS. Per poterlo fare è necessario scrivere (in C/C++) un apposito "modulo" Perl di interfaccia alla libsoxr. Oppure (se si possono scrivere "plugin" di LMS direttamente in C o C++) probabilmente si potrebbe fare scrivendo un apposito plugin di resampling che usa libsoxr.

Vista la differenza, in termini di consumo di risorse, credo sia una cosa desiderabile

se sox consuma il 2% di CPU, non mi pare che ci sia tutta questa differenza...

[marcoc1712]

strano. Che macchina usi?

...io non ho nessun problema a fare resampling con sox (da riga di comando Linux, non con LMS) con un ormai vecchiotto "core2 duo" neanche dei più performanti (ed anche con le opzioni più pesanti il processo è ben lungi dal "saturare" la CPU).

Confermo, anche con il mio core2 con XP non ho avuto problemi (fatto solo per prova, non faccio resampling abitualmente).

[marcoc1712]

ni. LMS è scritto in Perl, il che significa che non puoi utilizzare direttamente la libsoxr da LMS. Per poterlo fare è necessario scrivere (in C/C++) un apposito "modulo" Perl di interfaccia alla libsoxr. Oppure (se si possono scrivere "plugin" di LMS direttamente in C o C++) probabilmente si potrebbe fare scrivendo un apposito plugin di resampling che usa libsoxr.

Credevo di aver già risposto, ma evidentemente ho schiacciato il tasto sbagliato.

Si può scrivere un plugin, 'tipo' DSDPlay in C richiamando Libsoxr. La cosa più semplice sarebbe isolare il codice di Squeezelite che lo fa, che è quello che è stato fatto (con procedimento inverso) per DSDPlay. Non credo sarebbe difficile.

Per ottenere i migliori risultati, in termini di usabilità, richiede un minimo di lavoro anche su LMS. Ho già mandato appelli e proposte a Triode e Micheal, ma uno non risponde (..che sia in Vietnam anche lui?) e l'altro è impegnato nel mettere al sicuro LMS dalla imminente dipartita di mysdqueezebox.com e non si fa distrarre. Volendo spezzare una lancia in loro favore, in effetti si tratterebbe solo di 'cosmesi', dato che è tutto già fattibile, quindi capisco non lo valutino fondamentale.

[antonellocaroli]

stando a quanto ho letto in giro (anche qui), il picco iniziale potrebbe avere a che fare più con la libreria che con il resampling (il 25% iniziale è complessivo o si riferisce al solo processo di sox?).

Questo a meno che LMS non riempia un buffer con i dati già pre-processati, nel qual caso inizialmente potrebbe ricampionare i dati alla massima velocità possibile prima di assestarsi su quella media dello stream, cosa che ovviamente causerebbe un sensibile "picco" iniziale.

No il picco é dato da sox.exe...ma non credo sia un problema questo il picco dura pochi secondi e poi si stabilizza...

se sox consuma il 2% di CPU, non mi pare che ci sia tutta questa differenza...

Infatti!!! Paolo ma a te risulta che le due situazioni (libsoxr e sox) "suonino" in modo diverso?

[marcoc1712]

Questo a meno che LMS non riempia un buffer con i dati già pre-processati, nel qual caso inizialmente potrebbe ricampionare i dati alla massima velocità possibile prima di assestarsi su quella media dello stream, cosa che ovviamente causerebbe un sensibile "picco" iniziale.

Filippo ha già riportato che si tratta di sox.exe ad avere il picco, quindi bisogna escludere cover art ed altro.

I buffer sono diversi, uno è di SOX, LMS ha il suo (impostazioni, Audio) ed un'altro lo ha il player (se squeezelite, -b). come ho già scritto, un'altra causa da verificare è che probabilmente ad evitare glitch al cambio di traccia se cambia la frequenza di campionamento, SOX viene fatto ripartire ogni volta, da qui il picco, quello che mi suona strano è la durata, 'alcuni secondi' sono un'eternità...

[antonellocaroli]

Non é che sox fa na conversione flac>wav? e quello é il picco?
D -q -t wav - -t flac -e signed -C 0 -b 24 - rate -v -b 98 -L -a 384000

[marcoc1712]

Infatti!!! Paolo ma a te risulta che le due situazioni (libsoxr e sox) "suonino" in modo diverso?

quello probabilmente è molto dipendente dalle opzioni che dai a sox... con squeezelite sei limitato a dover scegliere tra pochi "preset", mentre con LMS ("pipe" sox a linea di comando) puoi giocare quasi all'infinito nel personalizzare come vuoi l'algoritmo di resampling.

Secondo me la differenza, se c'è, è in quello che scrive UnixMan, il che complicherebbe non poco la scrittura di un eventuale plug in, non basterebbe 'copiare' da Squeezelite, ma bisognerebbe reimplementare tutte le opzioni di SOX, anche nella GUI...

Ma sono così 'scarse' le opzioni di squeezelite?

Perchè, parliamoci francamente, se devo mettere un pc + potente vicino al dac per fare upsampling allora mi preoccupo e ci penso 10 volte, ma se il pc che c'è già è in grado di farlo al costo di un 2% di maggiore utilizzo della cpu, mantenendola sempre e comunque sotto al 10%, non credo possa provocare alcun danno, anzi, limitando SENSIBILMENTE il traffico di rete potrei addirittura ottenere dei vantaggi (è quello che sosteneva JS nel progettare lo SB replacement).

Quanto sopra è in apparente contrasto con quanto ho sempre sostenuto e praticato (io faccio streaming del PCM e non del flac, perchè secondo me lo SB+ ne risente), ma il 'saldo' tra un 2% di CPU in più ed il 95% di traffico di rete in meno è difficilmente negativo, vale la pena provare, ascoltare e possibilmente misurare.

Chiaro che se mi serve proprio quello che solo LMS può fare, non ho chance.

[marcoc1712]

Non é che sox fa na conversione flac>wav? e quello é il picco?
D -q -t wav - -t flac -e signed -C 0 -b 24 - rate -v -b 98 -L -a 384000

Mi pare che piuttosto faccia il contrario, wav -> flac, non chiedermi perchè.

La conversone (flac->wav) è normalmente eseguita già su sb2, un micorporcessore del 2003, non è paragonabile, come carico, all'upsampling 8x e comunque avviene negli stessi tempi, dovendo alimentare gli stessi buffers.

La escluderie come causa dei blocchi di bigtube.

[bigtube]

strano. Che macchina usi?

athlon(TM) 64 3200+2 Ghz....hai poco da scherzare ....è peggio del tuo.... stabilizzato poi oscilla fra il 60 e l'80% con picchi al 100%

...io non ho nessun problema a fare resampling con sox (da riga di comando Linux, non con LMS) con un ormai vecchiotto "core2 duo" neanche dei più performanti (ed anche con le opzioni più pesanti il processo è ben lungi dal "saturare" la CPU).

Non lo metto in dubbio....ma il mio si siede...

siete pregati di non fare commenti....me lo compro un PC piu' moderno...se pesco qualcuno che ride sotto i baffi lo seziono per benino

BTW:

come mai "-b 24" e non "-b 32"? è (solo) quello il formato che accetta LMS?

un banale errore di copia e incolla....nel file ho messo 32.....nella fretta succede......ribadisco che và bene