upsampling (universo LMS/Squeezelite/Squeezeplay)

[marcoc1712]

tutto è relativo...

quindi, riassumendo, nella mia condizione (stream wav 384K da LMS, nessuna elaborazione da parte di SL), quali opzioni/parametri metteresti sulla riga di comando di squeezelite? "-b 30720:2048" ? o ti riferivi ai parametri dell'opzione "-a"?

NO!

io metterei

-a 40:2::0 -b 30720:30720.

30720:30720 (o qualiasi altro valore) sono uguali proprio perchè non c'è conversione di formato ne resampling, questo è il cardine del ragionamento: tenere uguali (o simili) le 'durate' dei buffer. In pratica, dato il formato, l'unica variabile è la durata che desideri.


Nello specifico dei valori:

-a 40:2::0

40 ms è il default ed a me pare tutto sommato un buon compromesso, 2 - sempre secondo me - migliora leggermente rispetto a valori superiori, se non manda in crisi la CPU lo terrei fisso, MMAP, almeno in assenza di conversioni, è certamente inutile.

-b 30720:30720.

equivale a 10 sec. per il formato 384/32 (3072 KB/sec). Diversi formati o divere durate originano diversi valori.

Però, se puoi modificare C-3PO in modo che questo utilizzi un binario diverso a tua scelta, non potresti banalmente fornirgli direttamente il path completo dell'eseguibile? (ad es. in questo caso "/usr/bin/sox").

In questo modo si eviterebbe la necessità di dover fare qualsivoglia modifica al sistema; per giunta, rendendo la cosa configurabile dall'utente, si potrebbe utilizzare lo stesso "meccanismo" su tutti i SO supportati. Ad es. potresti aggiungere una opzione (checkbox) "use custom sox binary", seguita da un input field dove specificare il path dell'eseguibile...

No, non riesco, o almeno non per i casi in cui non uso l'eseguibile C-3PO ma LMS nativo. In quei casi nella riga di configurazione C-3PO scrive [SOX] (o qualsiasi altra cosa) ed è LMS che recupera il binario da utilizzare in base ai suoi algoritmi di ricerca, come ti ho già detto, dovrei patchare LMS e non voglio farlo.

Comunque io continuo a non capire come si dovrebbe fare in Linux per avere due versioni dello stesso eseguibile, ad esempio per gestire la transizione negli upgrade di sistema, a scopo di test... Come fai a gestire un cambio di release graduale (con parallelo) in produzione, ad esempio?

[UnixMan]

Prova a lancaire la riga di comando togliendo l'opzione silenziosa (a memoria -q) Ricorda di mettere 'output su file, altrimenti hai la sagra di paese in casa!

"-q" si limita a disabilitare quella sorta di "Vu-meter"/progress bar:

In:41.3% 00:01:47.46 [00:02:32.66] Out:4.74M [  -===|==-   ] Hd:0.4 Clip:0

che di solito aggiunge automaticamente ad es. quando lo chiami con "play" (ed in alcuni altri casi), o che puoi (sempre) abilitare manualmente con l'opzione (globale) "-S".

Per vedere invece in dettaglio che cosa succede, abilita l'opzione "verbose", "-Vn", dove "n" è un intero... di solito conviene usare "-V3" (valori maggiori sono per il debugging di sox stesso).

[marcoc1712]

in questo caso il dithering viene eseguito in quanto è necessario per passare da 32bit (formato interno) a 24bit (uscita richiesta).

mmmh... Secondo me viene eseguito perchè l'input è 44100 e l'output è 48000, anche nel caso precedente c'era il passaggio a 32, ma NON lo eseguiva perchè non c'è stato resampling. Se qui esci a 44100 (24) a mio avviso non dovrebbe farlo in quanto non necessario.

- sempre con un resampling.
- sempre con una riduzione di profondità.

mai altrimenti. Io l'ho capita così, non ho capito una beata angelica?

Per il 24_3 mi riferivo all'opzione di sox per il noise shaping, che a tuo avviso può provocare differenze in quanto 32 e non 24.

[UnixMan]

io metterei

-a 40:2::0 -b 30720:30720.

30720:30720 (o qualiasi altro valore) sono uguali proprio perchè non c'è conversione di formato ne resampling, questo è il cardine del ragionamento: tenere uguali (o simili) le 'durate' dei buffer. In pratica, dato il formato, l'unica variabile è la durata che desideri.

OK. Quindi, se ad es. volessi un buffer di 1s, dovrei mettere "-b 3072:3072", mentre per "-a" non cambia nulla, giusto?

MMAP, almeno in assenza di conversioni, è certamente inutile.

che c'entrano le conversioni? se non ho capito male, quella dovrebbe essere la modalità di accesso (per l'output) al device ALSA che (per i dispositivi per i quali è possibile) può utilizzare la modalità "memory mapped" (che è molto più veloce, "leggera" ed efficiente... e, almeno in teoria, sempre preferibile ove possa essere utilizzata).

No, non riesco, o almeno non per i casi in cui non uso l'eseguibile C-3PO ma LMS nativo. In quei casi nella riga di configurazione C-3PO scrive [SOX] (o qualsiasi altra cosa) ed è LMS che recupera il binario da utilizzare in base ai suoi algoritmi di ricerca, come ti ho già detto, dovrei patchare LMS e non voglio farlo.

ovviamente no. Ma quali sono i casi nei quali usi LMS?

Non puoi by-passarlo sempre, gestendo tutte le diverse modalità supportate direttamente da C-3PO?

In caso contrario, anche se non è proprio il massimo, al limite nulla vieterebbe di utilizzare due versioni diverse di sox nei due casi...

Comunque io continuo a non capire come si dovrebbe fare in Linux per avere due versioni dello stesso eseguibile, ad esempio per gestire la transizione negli upgrade di sistema, a scopo di test... Come fai a gestire un cambio di release graduale (con parallelo) in produzione, ad esempio?

con i pacchetti, normalmente... non si fa. Quelli sono pensati per fare upgrade completi ed "immediati": in sostanza è un sistema basato su transazioni, "o tutto o niente", un po' come nei DBMS (per contro, in linea di principio sono già testati e verificati, per cui degli eventuali problemi se ne sono già occupati i "maintainers" della distribuzione / dei pacchetti stessi).

Diversamente devi installare (a mano) in posti diversi e/o con nomi diversi.

BTW: le sostituzioni "graduali" dei sistemi in produzione tipicamente si fanno "affiancando" macchine (reali o -oggi più spesso- virtuali) con il nuovo sistema a quelle vecchie.

mmmh... Secondo me viene eseguito perchè l'input è 44100 e l'output è 48000, anche nel caso precedente c'era il passaggio a 32, ma NON lo eseguiva perchè non c'è stato resampling.

No. Non lo eseguiva perché i dati non erano stati modificati e quindi, anche se rappresentati con "parole" di 32bit, continuavano ad essere quelli originali. Lo dice abbastanza chiaramente anche nella man page:

Dithering
       Dithering is a technique used to maximise the dynamic  range  of  audio
       stored   at  a  particular  bit-depth.  Any  distortion  introduced  by
       quantisation is decorrelated by adding a small amount of white noise to
       the  signal.   In  most  cases,  SoX can determine whether the selected
       processing requires dither and will add it during output formatting  if
       appropriate.

       Specifically,  by  default, SoX automatically adds TPDF dither when the
       output bit-depth is less than 24 and any of the following are true:

       ·   bit-depth reduction has been specified explicitly using a  command-
           line option

       ·   the  output file format supports only bit-depths lower than that of
           the input file format

       ·   an effect has increased effective  bit-depth  within  the  internal
           processing chain

       For  example,  adjusting  volume  with vol 0.25 requires two additional
       bits in which to losslessly  store  its  results  (since  0.25  decimal
       equals  0.01 binary).  So if the input file bit-depth is 16, then SoX's
       internal representation will utilise  18  bits  after  processing  this
       volume  change.   In order to store the output at the same depth as the
       input, dithering is used to remove the additional bits.

       Use the -V option to see what processing SoX has  automatically  added.
       The  -D option may be given to override automatic dithering.  To invoke
       dithering manually (e.g. to select  a  noise-shaping  curve),  see  the
       dither effect.

In buona sostanza, puoi/devi aggiungere il dithering se hai alterato i dati (in un qualsiasi modo tale da "aggiungere" bit significativi).

BTW: da sostanziale ignorante in materia di DSP e affini, stavo riflettendo... dato che per l'informazione valgono principi analoghi ai tre principi della termodinamica e quindi è fuor di dubbio che, qualsiasi cosa io faccia, non posso ottenere in uscita da un qualsivoglia processo una quanità di informazione maggiore di quella che avevo in origine (anzi, sicuramente ne perderò almeno un po' per strada), se parto da uno stream a 16bit (quindi con max 96dB di dinamica...) ed esco con uno a 24 (o più) bit (dinamica >= 144dB), "cosa c'è" realmente in quei bit in più? che significato fisico hanno? Sarà mica che alla fine non è nient'altro che rumore (verosimilmente correlato...) e che quindi se entro con "n" bit è bene che non esca mai con più di "n" bit? Cioè che in pratica sarebbe bene utilizzare il dithering per eliminare tutti i bit "extra" e "decorrelare" così il rumore?

Questa IMO è una prova da fare (cioè, uscire -con dithering- a 16bit con materiale a 16 bit, a 24 con materiale a 24, ecc). Se all'ascolto la cosa dovesse risultare positiva (possibile, per non dire addirittura probabile), ci sarebbe altro lavoro per te...

(C-3PO infatti dovrebbe diventare abbastanza "furbo" da cambiare formato di uscita o quanto meno "precisione" effettiva ottenuta con "-p" in modo da uscire con una risoluzione sempre minore o uguale a quella di ingresso, in funzione di questa e della risoluzione/dinamica effettiva del DAC utilizzato).

[marcoc1712]

"è fuor di dubbio che, qualsiasi cosa io faccia, non posso ottenere in uscita da un qualsivoglia processo una quanità di informazione maggiore di quella che avevo in origine"

Questo direi che non è in discussione, nè per la profondità nè per la frequenza di campionamento. Puoi usare algoritmi complicati fin che vuoi, ma l'informazione in se è persa, andata, stai solo cercando di ricostruirla matematicamente ed applicando correzioni psicoacustiche.

Se nel farlo usi mantisse più ampie hai - matematicamente - un risultato più preciso, quanto questo poi sia 'reale' o 'rumore' è tutto un'altro discorso, da qui i processi psicoaucustici, tra cui il dithering.

Non ho capito come riportare 'indietro' la precisione potrebbe risultare benefico. Secondo me non consideri che il ditering viene applicato SOLO se la precisione risultante è minore di 24 bit. A 24 bit ed oltre, la precisione è talmente alta da NON richiedere l'applicazione del dithering ANCHE quando sia stata modificata la porzione significatva dei dati e/o si sia incrementata la profondità tramite un effetto. Questo, almeno, è quello che sostengono.

Se invece il tuo dubbio è: faccio resampling ed aumento (fittiziamente) la precisone, quindi cosa finisce nel byte meno significativo se non lo 'sterile' risulato di un calcolo? Non può essere che questo calcolo reintroduca patterns che risultano in distorsione?

Nel caso la risposta è: Bella domanda! Ma non so che dirti...

[marcoc1712]

BTW: le sostituzioni "graduali" dei sistemi in produzione tipicamente si fanno "affiancando" macchine (reali o -oggi più spesso- virtuali) con il nuovo sistema a quelle vecchie.

Lo spieghi tu ai clienti che devono 'raddoppiare' la potenza di calcolo? L'ho visto succedere solo nei progetti SAP e solo lato server, MAI lato client, non è sostenibile SE in alternativa puoi usare il vecchio hw semplicemente rinominando l'eseguibile...

[bigtube]

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.

aggiunto "dither -S" .....devo dire che mi piace...mi convince.....buona dritta
Per Squeezelite uso solo opzioni "default" e sto benissimo

[marcoc1712]

OK. Quindi, se ad es. volessi un buffer di 1s, dovrei mettere "-b 3072:3072", mentre per "-a" non cambia nulla, giusto?

-b corretto, per -a:

il buffer size è già espresso in ms (se usi valori inferiori a 500) , per questo non cambia, in realtà la dimensione del buffer in bytes cambia 'dinamicamente' in funzione del formato e del samplerate.

il period count (se usi valori inferiori a 50) è espresso in numero di periodi nel buffer, quindi il period size diventa buffer size/period count.

In questo modo rimani INDIPENDENTE dal reale formato e sample rate utilizzato, fatti un favore e NON complicarti la vita usando valori espressi in bytes...

che c'entrano le conversioni? se non ho capito male, quella dovrebbe essere la modalità di accesso (per l'output) al device ALSA che (per i dispositivi per i quali è possibile) può utilizzare la modalità "memory mapped" (che è molto più veloce, "leggera" ed efficiente... e, almeno in teoria, sempre preferibile ove possa essere utilizzata).

MMAP è relativo alla chiamata di pcm_writeI o a quella analoga ma che usa MMAP, più leggera per accessi random perchè non richiede il carimanento preventivo in memoria, ma solo a richiesta (lazy load). Ma nel nostro caso, la lettura dal buffer di output è SEMPRE da memoria precaricata, quindi MMAP è inutile, ciòè a maggior ragione vero quando l'input e l'output sono 'sincroni', avendo lo stesso formato. (stiamo parlando del formato di output e di quello della scheda audio).


The only case where there is a separate buffer is when the data written
by the application is not the same as the data to be written to the
hardware, i.e., when using dmix or sample format conversion.

IO francamente dubito ci sia un vantaggio anche nel secondo caso, comunque, di certo non c'è quando i formati sono gli stessi.

[UnixMan]

Secondo me non consideri che il ditering viene applicato SOLO se la precisione risultante è minore di 24 bit. A 24 bit ed oltre, la precisione è talmente alta da NON richiedere l'applicazione del dithering ANCHE quando sia stata modificata la porzione significatva dei dati e/o si sia incrementata la profondità tramite un effetto. Questo, almeno, è quello che sostengono.

sì. Questo, presumo, in base al fatto che l'intervallo dinamico dell'orecchio umano si stima essere intorno ai 120 -:- 140 dB circa(*); poiché 24 bit corrispondono a circa 144dB, a livello di LSB dovremmo essere già abbondantemente oltre la max "risoluzione" dell'orecchio umano, per cui qualsiasi effetto a quei livelli dovrebbe risultare già di per sé stesso del tutto inaudibile (e quindi con bit-depth>=24bit applicare il dithering dovrebbe essere superfluo).

(*) per altro si tratta di un range dinamico per certi versi fittizio, in quanto ottenuto grazie ai meccanismi dell'orecchio medio che si comportano come una sorta di "amplificatore" (meccanico) dotato di "AGC" (controllo automatico del guadagno), ovvero come un compressore della dinamica. In sostanza l'orecchio si adatta all'intensità dei suoni cui è esposto, diminuendo progressivamente la sua sensibilità all'aumentare della pressione acustica e viceversa (con tutti i fenomeni di mascheramento che ne conseguono...).

Se invece il tuo dubbio è: faccio resampling ed aumento (fittiziamente) la precisone, quindi cosa finisce nel byte meno significativo se non lo 'sterile' risulato di un calcolo? Non può essere che questo calcolo reintroduca patterns che risultano in distorsione?

Nel caso la risposta è: Bella domanda! Ma non so che dirti...

esattamente, il dubbio era proprio questo!

(ovviamente, intendendo "distorsione" in senso lato; penso che nel caso sarebbe più corretto parlare di "rumore correlato" o di "modulazione del rumore", che sono comunque fenomeni che rivestono una importanza tutt'altro che trascurabile a livello di percezione/psicoacustica).

[antonellocaroli]

Comunque il play parte...ma niente suono

Questo il log di LMS
Nuovo documento di testo (9).txt

Stesso risultato se disattivo C-3PO e cambio il custom-convert a mano