DSD in LMS con SOX

[SimoneFil]

Infatti mettendo come OPTS RESAMPLE la compilazione ha funzionato senza problemi.
L'ho testato sia con PCM che DSD e funziona senza problemi, ho aggiornato il link nel post https://www.nexthardware.com/forum/p...tml#post972504

Ora mi aggiungo al testing di C-3PO

[marcoc1712]

Nel frattempo, sto lavorando per produrre i binari "portabili" (semi-statici) di sox e squeezelite.

Pro-memoria:

Alla fine ho fatto due "chroot" con deboostrap, con installazioni ultra-minimali di Jessie a 32bit (i386) e l'altra a 64 (x86_64), e quindi sto usando quelle per produrre i binari.

Per compilare sox, alla fine sono arrivato a questo:

#!/bin/bash

export PREFIX="/usr/local"

export PKG_CONFIG_PATH=${PREFIX}/lib/pkgconfig

export CFLAGS=" -O3 "
export CXXFLAGS=" -O3 -static-libstdc++"
export LDFLAGS=" -static-libstdc++ "


function doinstall() {
  [[ "$1" == "--uninstall" ]] && ( UNINSTALL="true" ; shift ) || unset UNINSTALL
  pckg="$1"
  shift
  options="$@"
  pushd "$pckg"*
  cat <<-EOF

        ########################################################################
        # Now processing: $pckg
        ########################################################################
EOF
  pwd
  echo
  [[ -v UNINSTALL ]] && colormake uninstall
  colormake clean
  colormake distclean
  #autoreconf
  #autoreconf -Wall --prepend-include=${PREFIX}/include -i
  #autoreconf --include=${PREFIX}/include -i
  #
  ./configure --prefix=${PREFIX} ${options}
  [ $? -eq 0 ] || exit 1
  echo
  read -t 10 -p "Press enter to build and install, Ctrl+C to quit."
  echo
  colormake || exit 2
  echo
  colormake install || exit 3
  popd
}


doinstall zlib                  --static
doinstall file                  --enable-shared=no --enable-static=yes
doinstall fftw3                 --enable-shared=no --enable-static=yes --enable-openmp=no --enable-sse2 --enable-threads
#doinstall alsa-lib             --enable-shared=no --enable-static=yes --enable-pcm --with-pcm-plugins=all
doinstall libao                 --enable-shared=no --enable-static=yes --enable-static=alsa --enable-alsa --enable-alsa-mmap
doinstall libpng                --enable-shared=no --enable-static=yes
doinstall libogg                --enable-shared=no --enable-static=yes
doinstall libvorbis             --enable-shared=no --enable-static=yes
doinstall libmad                --enable-shared=no --enable-static=yes
doinstall flac                  --enable-shared=no --enable-static=yes --enable-sse
doinstall wavpack               --enable-shared=no --enable-static=yes --enable-mmx
doinstall libsndfile            --enable-shared=no --enable-static=yes
doinstall libsamplerate         --enable-shared=no --enable-static=yes --enable-sndfile
doinstall libid3tag             --enable-shared=no --enable-static=yes
doinstall twolame               --enable-shared=no --enable-static=yes
doinstall lame                  --enable-shared=no --enable-static=yes
doinstall sox                   --disable-shared --disable-openmp

il tutto produce un binario che supporta tutto quel che serve (manca il supporto per ALSA, ma per quel che ci serve non credo sia un problema) ma dipende esclusivamente dalla glibc.

Bisogna capire come lo si distribuirà. Se ad uso solo di C-3PO, al di fuori di quello verrà usato quello distribuito con LMS o installato nel sistema, quindi c'è sicuramente anche troppo, se - invece - lo si vuole sostituire a quello già presente anche per altri usi, forse la mancanza di ALSA può essere un problema (non in LMS però).

Al momento io ho messo solo delle note in merito in C-3PO, per altro da integrare, ma è un aspetto da definire prima di uscire dalla fase beta.

[marcoc1712]

Testati cue sheet: OK.

In che senso? in Wav, Flac o dsf/dff?

Li ho appena disabilitati in dsf/dff, se vanno li riattivo, ma mi devi dire cosa hai usato per fare lo split.

Testato DSD->PCM: funziona. Però c'è qualcosa di strano:

*** /var/log/squeezeboxserver//server.log ***
[17-02-23 22:49:44.5373] Slim::Utils::Scanner::Local::rescan (181) Discovering audio files in /home/data/audio/DSD
[17-02-23 22:49:44.6290] Slim::Utils::Scanner::Local::__ANON__ (193) Start processing found tracks
[17-02-23 22:49:44.6292] Slim::Utils::Scanner::Local::__ANON__ (201) Connect do DB
[17-02-23 22:49:44.6293] Slim::Utils::Scanner::Local::__ANON__ (204) Get latest ID
[17-02-23 22:49:44.6297] Slim::Utils::Scanner::Local::__ANON__ (226) Delete temporary table if exists
[17-02-23 22:49:44.6299] Slim::Utils::Scanner::Local::__ANON__ (229) Re-build temporary table
[17-02-23 22:49:45.2083] Slim::Utils::Scanner::Local::__ANON__ (278) Get deleted tracks count
[17-02-23 22:49:45.2085] Slim::Utils::Scanner::Local::__ANON__ (285) Get new tracks count
[17-02-23 22:49:45.2088] Slim::Utils::Scanner::Local::__ANON__ (290) Get changed tracks count
[17-02-23 22:49:45.6412] Slim::Utils::Scanner::Local::__ANON__ (296) Removing deleted audio files (0)
[17-02-23 22:49:45.6414] Slim::Utils::Scanner::Local::__ANON__ (374) Scanning new audio files (0)
[17-02-23 22:49:45.6416] Slim::Utils::Scanner::Local::__ANON__ (454) Rescanning changed audio files (0)

non è un errore, semplicemente hai usato disk and folders o browse music folder su files non ancora nel DB.

[17-02-23 22:50:05.0382] Slim::Player::TranscodingHelper::getConvertCommand2 (443) Error: Didn't find any command matches for type: dsf

qui. Che vuol dire quell'errore?

Nulla, è solo un messaggio del tutto fuorviante che avvisa di non aver trovato il corrisponendte profilo 'transcode' per il downsampling/transcoding automatico eventualmente richiesto dai players (a noi no interessa, anzi, l'abbiamo diabilitato volutamente).

C'è sempre stato, anche per PCM, per tutti i profili non gestiti nel convert.conf.

;2 ;1

Ottimo!

[marcoc1712]

Buona sera a tutti, finalmente mi sono liberato dagli impegni di questi giorni; ho visto che avete fatto progressi enormi, grandi!

Io mi sono messo a compilare Squeezelite per Raspberry pi, ho risolto qualche problema di dipendenze ma non riesco ancora a venire a capo di questo errore:

dsd.o: In function `dsd_decode':
dsd.c:(.text+0xbe4): undefined reference to `process'
dsd.c:(.text+0x1790): undefined reference to `process'
collect2: error: ld returned 1 exit status
Makefile:77: recipe for target 'squeezelite-rpi' failed
make: *** [squeezelite-rpi] Error 1

Avete qualche idea?

nel codice mancano le definzioni alla label process , da una rapida scorsa ho visto cheil tipo di process è processstate che è definto in header se è PROCESS che è definito se RESAMPLE.

Senza averci guardato, farei una prima prova abilitandol'opzione di compilzione RESAMPLE, anche se...

[marcoc1712]

ad occhio e croce, non trova questa:

extern struct processstate process;

...che è definita in "squeezelite.h":

#if PROCESS
struct processstate {
    u8_t *inbuf, *outbuf;
    unsigned max_in_frames, max_out_frames;
    unsigned in_frames, out_frames;
    unsigned in_sample_rate, out_sample_rate;
    unsigned long total_in, total_out;
};
#endif

...all'interno di un blocco condizionale: possibile che per qualche motivo venga escluso. Verifica.

Edit:

Lo stato di "PROCESS" dipende da quello di "RESAMPLE": (sempre da squeezelite.h):

#if defined(RESAMPLE) || defined(RESAMPLE_MP)
#undef  RESAMPLE
#define RESAMPLE  1 // resampling
#define PROCESS   1 // any sample processing (only resampling at present)
#else
#define RESAMPLE  0
#define PROCESS   0
#endif

...che a sua volta è definito esternamente (opzioni di compilazione):

// make may define: PORTAUDIO, SELFPIPE, RESAMPLE, RESAMPLE_MP, VISEXPORT, IR, DSD, LINKALL to influence build

non avvo visto che avevi già risposto, scusa.

COmuqnue è così, confermo, anche s emi pare che on sia così in win, da verificare.

[marcoc1712]

Infatti mettendo come OPTS RESAMPLE la compilazione ha funzionato senza problemi.
L'ho testato sia con PCM che DSD e funziona senza problemi, ho aggiornato il link nel post https://www.nexthardware.com/forum/p...tml#post972504

Ora mi aggiungo al testing di C-3PO

Quindi squeezelite-R2 si è compilato per il PI e funziona bene con DSD?

Grande.

Rimane solo da capire prechè sul PI richiede il resample ed in WIN no.

Che opzioni hai usato in definitiva? (squeezeliteR2-? ultima riga) In mac lo hai messo?

@Paolo in linux hai dovuto abilitare resampling?

Sarebbe scocciante, io vorrei eliminare del tutto il resampling da R2...

Bene, adesso vi lascio giocare un po con il DSD e C-3PO, quando saremo abbastanza sicuri di aver trovato e risolto buona parte dei buchi (vi prego di provare le più disparate combinazioni di parametri), rilascerò la release ufficiale, ma in contemporanea dovrò farlo anche per Squeezelite ed in qualche modo anche per SOX.

[marcoc1712]

@FIlippo, mi sono accorto che non abbiamo meso il link ala tua versione per WIN di Squeezelite-R2 e, d'altra parte, non abbiamo nemmemo riportato le modifiche ai files di progetto necessari (ammesos ce ne fossero, io non ne ricordo, tranne l'lenco delle librerie, che dovrebbe essere aggiornato nel mio repo. Confermi?

Temo poi dovremo produrre due configurazioni diverse per XP/10 e non abbiamo testato 7 ed 8... QUalcuno con Win7 e/o win 8 si presta come volontario?

@Per tutti, ho bisogno di raccogliere le eventuali modifiche ai files di supporto alla compilazione/strutture delle direcotries da includere nel repo di squeezelite, segnalatemene per confronto con l'attuale verisone del repository (in git è facile fare un diff e produrre una patch complessiva, poi la spoccio io).

Per SOX... dobbiamo decidere il da farsi. Accetto proposte.

[antonellocaroli]

@FIlippo, mi sono accorto che non abbiamo meso il link ala tua versione per WIN di Squeezelite-R2 e, d'altra parte, non abbiamo nemmemo riportato le modifiche ai files di progetto necessari (ammesos ce ne fossero, io non ne ricordo, tranne l'lenco delle librerie, che dovrebbe essere aggiornato nel mio repo. Confermi?

Confermo che non l abbiamo mai fatto , oggi sono a casa...se vuoi ci colleghiamo.
in realtá io avevo provato, ma senza esito, probabilmente non ho capito bene di cosa ha bisogno e dove...

PS: Tu un binario lo avevi prodotto, mi ricordo...lo avevi messo da qualche parte, che io avevo provato in windows...

[UnixMan]

Infatti mettendo come OPTS RESAMPLE la compilazione ha funzionato senza problemi.
L'ho testato sia con PCM che DSD e funziona senza problemi, ho aggiornato il link nel post https://www.nexthardware.com/forum/p...tml#post972504

Bene. Però è piuttosto strano: se quella struttura serve solo per il resampling, se questo non è abilitato non dovrebbe essere utilizzata da nessuna parte, quindi non dovrebbe dare errori (in caso contrario la sua definizione non dovrebbe essere esclusa). D'altro canto su x86 si compila senza problemi, anche senza abilitare il resampling.

Perciò sospetto che ci sia qualche problema con il Makefile: quale hai usato?

N.B. per impostare il rate dsd in SoX, la versione macOS "digerisce" la sintassi $[ X* 2822400 ], la versione FreeBSD no, bisogna scrivere direttamente il rate.

quello è un comando della shell: è la shell che calcola il risultato dell'operazione e sostituisce il valore corrispondente prima di passare la riga di comando all'eseguibile. Ma si tratta di un "bashism" (sintassi propria di bash): se su FreeBSD hai una "Bourne shell" originale (o altra shell Posix standard, inclusa la stessa bash avviata come "/bin/sh" oppure con l'opzione "--posix"), ovviamente quella sintassi non funziona.

In che senso? in Wav, Flac o dsf/dff?

ingresso flac.

non è un errore, semplicemente hai usato disk and folders o browse music folder su files non ancora nel DB.

err... no, non era quella la cosa strana cui mi riferivo... ma a questa:

Nulla, è solo un messaggio del tutto fuorviante che avvisa di non aver trovato il corrisponendte profilo 'transcode' per il downsampling/transcoding automatico eventualmente richiesto dai players (a noi no interessa, anzi, l'abbiamo diabilitato volutamente).

C'è sempre stato, anche per PCM, per tutti i profili non gestiti nel convert.conf.

Non ci avevo mai fatto caso... OK, allora nessun problema.

Rimane solo da capire prechè sul PI richiede il resample ed in WIN no.
[...]
@Paolo in linux hai dovuto abilitare resampling?

No, su Linux x86 nessun problema. Presumo che ci sia un problema con il Makefile, oppure non ha usato quello "giusto"...

Bisogna capire come lo si distribuirà. Se ad uso solo di C-3PO, al di fuori di quello verrà usato quello distribuito con LMS o installato nel sistema, quindi c'è sicuramente anche troppo, se - invece - lo si vuole sostituire a quello già presente anche per altri usi, forse la mancanza di ALSA può essere un problema (non in LMS però).

è pensato per essere utilizzato esclusivamente da/per LMS e/o C-3PO.

L'idea è che quando installi C-3PO questo provveda ad installare opportunamente anche tutto ciò di cui ha bisogno per funzionare a pieno, con tutte le sue features (quindi "sox-dsd", in questo caso). Così che tutti possano utilizzarlo semplicemente installando il plugin da LMS, senza dover far altro (ed in particolare senza dover "mettere le mani" sul sistema).

N.B.: non puoi sostituire la versione di SoX fornita con il sistema: quella deve essere compilata dinamicamente, e deve essere la stessa versione distribuita con il sistema, o quanto meno una perfettamente compatibile: mezza distribuzione dipende da libsox...

@Per tutti, ho bisogno di raccogliere le eventuali modifiche ai files di supporto alla compilazione/strutture delle direcotries da includere nel repo di squeezelite,

per quanto riguarda Linux - almeno su x86 - non è necessaria nessuna modifica da nessuna parte.

[marcoc1712]

per quanto riguarda Linux - almeno su x86 - non è necessaria nessuna modifica da nessuna parte.

parlavo di Squeeezelite, in questo caso, va bene quello nel mio repo?