DSD in LMS con SOX

[RiRo]

Plugins::C3PO::Plugin::_setupTranscoder (1335) commandTable: {
"aif-dff-*-5a:5e:ce:56:65:ad" => {
capabilities => { D => "RESAMPLE=-r %d", F => "noArgs", R => "noArgs" },
command => "[sox] -q -t aif \$FILE\$ -t dff -b 1 - gain -h rate -v -M -b 90.7 11289600 sdm -f sdm-8",
profile => "aif-dff-*-5a:5e:ce:56:65:ad",
},
"alc-dff-*-5a:5e:ce:56:65:ad" => {
capabilities => { D => "RESAMPLE=-r %d", F => "noArgs", R => "noArgs" },
command => "[faad] -q -w -f 1 \$START\$ \$END\$ \$FILE\$ | [sox] -q -t wav - -t dff -b 1 - gain -h rate -v -M -b 90.7 11289600 sdm -f sdm-8",
profile => "alc-dff-*-5a:5e:ce:56:65:ad",
},
"flc-dff-*-5a:5e:ce:56:65:ad" => {
capabilities => { D => "RESAMPLE=-r %d", F => "noArgs", I => "noArgs", R => "noArgs" },
command => "[flac] -dcs --totally-silent \$START\$ \$END\$ -- \$FILE\$ | [sox] -q -t wav - -t dff -b 1 - gain -h rate -v -M -b 90.7 11289600 sdm -f sdm-8",
profile => "flc-dff-*-5a:5e:ce:56:65:ad",
},
"wav-dff-*-5a:5e:ce:56:65:ad" => {
capabilities => {
D => "RESAMPLE=-r %d",
F => "noArgs",
R => "noArgs",
T => "START=--skip=%t",
U => "END=--until=%v",
},
command => "[flac] -cs --totally-silent --compression-level-0 \$START\$ \$END\$ -- \$FILE\$ | [sox] -q -t flac - -t dff -b 1 - gain -h rate -v -M -b 90.7 11289600 sdm -f sdm-8",
profile => "wav-dff-*-5a:5e:ce:56:65:ad",
},
}

[marcoc1712]

Tokenized command: "C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\flac.exe" -dcs --totally-silent -- - | "C:\PROGRA~2\SQUEEZ~1\server\Bin\MSWin32-x86-multi-thread\sox.exe" -q -t wav - -t dff -b 1 - gain -h rate -v -M -b 90.7 11289600 sdm -f sdm-8

Direi che è perfetto, risponde anche alla mia domanda se in queste condizioni, usando FLAC per il decode funziona.


BTW, non hai FFMPEG Installato, probabilmente, se usi solo flac è lo stesso, ma se usi anche wav è meglio.

[RiRo]

dunque, funzia?
serve qualche altra schermata?
Posso tornare a settare ERROR, per ridurre le risorse impegnate?

[marcoc1712]

dunque, funzia?
serve qualche altra schermata?
Posso tornare a settare ERROR, per ridurre le risorse impegnate?

Si, il log è giusto, se funzia... devi dirmelo tu.
Vai tranquillo, adesso sai come fare per ripristinare il logging in caso di problemi.

[RiRo]

Uso solo Flac, iniziai a stoccare i cd per il telefonino, e ho continuato FLAC. Se mi dici che conviene istallarlo, tendendo conto l'equilibrio di risorse del sistema, e dove trovarlo, lo monto.
Grazie
R

[RiRo]

A tratti, molto raramente, all'avvio di un pezzo, il primo, ho dei "mutismi" di frazioni di secondo. Unico problemino, per ora, oltre ad alcuni bump a cambio pezzo, ma quello è il mirand, il jlsounds non lo fa

[marcoc1712]

A tratti, molto raramente, all'avvio di un pezzo, il primo, ho dei "mutismi" di frazioni di secondo. Unico problemino, per ora, oltre ad alcuni bump a cambio pezzo, ma quello è il mirand, il jlsounds non lo fa

il 'mutismo' è dovuto al buffering iniziale, se vuoi ridurlo puoi provare ad abbassare il buffer in ingresso di squeezelite, ma scambi latenza (mutismo) con 'isteresi' (uso impropriamente il termine per rendere il senso che quanto avviene prima, a monte, si fa sentire di più) devi provare e capire cosa è meglio per te ed i tuoi dacs.

[marcoc1712]

Uso solo Flac, iniziai a stoccare i cd per il telefonino, e ho continuato FLAC. Se mi dici che conviene istallarlo, tendendo conto l'equilibrio di risorse del sistema, e dove trovarlo, lo monto.
Grazie
R

C-3PO Transcoding Helper - note libere

[SimoneFil]

Le idee sono sempre ben accette, lo sviluppo in se potrebbe anche essere fattibile (con calma), ma il problema è la distribuzione e lo sviluppo, prima chudiamo questa release e capiamo come organizzarci per la manutenzione futura, specie delle distribuzioni binarie che io non riesco a produrre.

Io sono sempre stato per la filosofia "se funziona, non si tocca"; quindi, a meno di modifiche importanti per aggiungere funzionalità interessanti, la manutenzione dei binari non dovrebbe essere nulla di impegnativo.
Ho aggiornato il link per il binario di squeezelite per raspbian, ora compilato correttamente con l'opzione -DDSD. Ho inoltre aggiunto quello compilato per RaspBSD, ma lo tengo in alpha perchè è ancora da testare approfonditamente. Copio sotto il makefile utilizzato:

CPPFLAGS = -I/usr/local/include -I/usr/local/include/portaudio2
CFLAGS  = -Wall -fPIC -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DDSD
LDFLAGS = -L/usr/local/lib -L/usr/local/lib/portaudio2 -lportaudio -lpthread -lm
EXECUTABLE = squeezelite-raspbsd

include Makefile

E' sottinteso che per quanto riguarda tutte le versioni di squeezelite l'utente dovrà installare le dipendenze perchè le librerie sono linkate dinamicamente.

Domanda: in Daphile SoX per la conversione lavora in multithread senza troppi problemi, inoltre mi pare che utilizzi molta più cpu rispetto a quella che usa ora C-3PO con SoX modificato; in particolare per una conversione in DSD128 con Daphile mi serviva un CPU con un punteggio in https://www.cpubenchmark.net/ >= 5000. Le domande quindi sono: nella nostra implementazione SoX lavora in single core o multi thread? E' essenziale che non lavori su un singolo core per evitare di escludere molte cpu. Come mai questa differenza di uso CPU? Daphile implementa qualche patch che rende la conversione più pesante?

[marcoc1712]

Io sono sempre stato per la filosofia "se funziona, non si tocca"; quindi, a meno di modifiche importanti per aggiungere funzionalità interessanti, la manutenzione dei binari non dovrebbe essere nulla di impegnativo.
Ho aggiornato il link per il binario di squeezelite per raspbian, ora compilato correttamente con l'opzione -DDSD. Ho inoltre aggiunto quello compilato per RaspBSD, ma lo tengo in alpha perchè è ancora da testare approfonditamente. E' sottinteso che per quanto riguarda squeezelite l'utente dovrà installare le dipendenze perchè le librerie sono linkate dinamicamente.

Domanda: in Daphile SoX per la conversione lavora in multithread senza troppi problemi, inoltre mi pare che utilizzi molta più cpu rispetto a quella che usa ora C-3PO con SoX modificato; in particolare per una conversione in DSD128 con Daphile mi serviva un CPU con un punteggio in https://www.cpubenchmark.net/ >= 5000. Le domande quindi sono: nella nostra implementazione SoX lavora in single core o multi thread? E' essenziale che non lavori su un singolo core per evitare di escludere molte cpu. Come mai questa differenza di uso CPU? Daphile implementa qualche patch che rende la conversione più pesante?

SOX in Daphile è arretrato rispetto al nostro che comprende già le patch rielaborate da mansr, non ho inverstigato su quali siano le differenze però.

In più, credo che Daphile usi le versioni non ottimizzate, dato che non ha meccanismi per installare diversamente su target diversi, quindi se va su un futro a 32bit non è certo compilato con il supporto per le istruzioni tipiche di un iCore di ultima generazione.

In merito alla manutenzione e supporto ci arriviamo.