DSD in LMS con SOX

[marcoc1712]

anche lì, in realtà non dovrebbero servire affatto. Servono solo perché chi ha compilato la versione OSX non ha installato sul suo sistema qualche libreria (con i relativi headers... proprio quelli aggiunti lì dentro).

mi dici come fai se devi produrre binari per 10.5, 10.7 o 11.x? che usano versioni NECESSARIAMENTE diverse di librerie?

[UnixMan]

mi dici come fai se devi produrre binari per 10.5, 10.7 o 11.x? che usano versioni NECESSARIAMENTE diverse di librerie?

se le librerie nuove sono retro-compatibili, compili su/per 10.5 e va bene per tutti.

In caso contrario semplicemente non fai... serve un binario per ogni versione, altrimenti non funziona.

edit:

per inciso, compilare utilizzando degli include "locali" equivale ad utilizzare librerie diverse da quelle presenti nel sistema. Finché queste sono perfettamente compatibili con quelle effettivamente presenti sui sistemi di destinazione va tutto bene. Ma se per caso invece non lo sono, il binario che hai così prodotto poi non funziona.

Peggio ancora se tra la versione di una o più lib corrispondenti ai tuoi "include locali" e quelle effettivamente presenti nel sistema ci sono delle incompatibilità minori. Nel qual caso magari R2 riesce anche a partire, ma poi ti da problemi strani e difficilmente comprensibili a run time.

[marcoc1712]

se le librerie nuove sono retro-compatibili, compili su/per 10.5 e va bene per tutti.

In caso contrario semplicemente non fai... serve un binario per ogni versione, altrimenti non funziona.

E come faccio a produrre i binari diversi, se non tenendomi diverse versioni di header da includere in funzione del target? si chiama cross compiling...

[UnixMan]

E come faccio a produrre i binari diversi, se non tenendomi diverse versioni di header da includere in funzione del target? si chiama cross compiling...

certo (vedi quanto avevo aggiunto).

Ma come te la cavi con le lib di sistema, in particolare proprio quelle del compilatore?

Non so come funzionino le cose in OSX, ma dubito che se compili qualcosa sull'ultima versione del sistema il binario poi ti funziona anche su quelle più vecchie... a meno che non sia previsto qualche "trucco" apposito. Nel qual caso staresti appunto ("cross-")compilando "per" la versione vecchia.

[SimoneFil]

Compilare per ogni versione è improbabile, e sperare che ogni utente finale si compili da solo per il suo sistema è ancora più improbabile.

Compilare linkando staticamente è un po' un macello, mi sto informando in questi giorni ma non pare per nulla semplice... soprattutto per osx, su linux sembra più fattibile. Non si possono far felici tutti quindi basta farne felici molti, rilasciando i binari per i maggiori O.S. mentre per quelli minori/troppo vecchi basteranno le istruzioni, dettagliate, per la compilazione che scriveremo. Quindi mi sembra sensata la rimozione delle cartelle include (in macOS, rimuovendo la cartella include-osx si compila alla perfezione ... diversa la questione per libportaudio.a)

[marcoc1712]

certo (vedi quanto avevo aggiunto).

Ma come te la cavi con le lib di sistema, in particolare proprio quelle del compilatore?

Non so come funzionino le cose in OSX, ma dubito che se compili qualcosa sull'ultima versione del sistema il binario poi ti funziona anche su quelle più vecchie... a meno che non sia previsto qualche "trucco" apposito. Nel qual caso staresti appunto ("cross-")compilando "per" la versione vecchia.

No, non funziona così, ti scarichi la SDK che permette di produrre i binari per il sistema target ed usi quella, impostando opportunamente i FLAGS (v. make). Ma non è così solo in mac, è così ovunque tu voglia fare cross compiling. La differenza rispetto alla cartella ./include nel progetto è solo di opportunità di distribuirla, certo non includerai le sdk...

Stessa cosa in Win, dove per far funzionare l'eseguibile in XP devo compilarlo con il supporto specifico e magari distribuire le DLL Runtime di vsc e sono convinto (ma non lo per certo) che se vuoi compilare per Debian in Ubuntu (con ALSA 1.0.29) dovrai avere le header di ALSA 1.0.28 installate da qualche parte e far riferimento a quelle., altrimenti su debian non andrà.

Non è questione di filosofia, se vuoi fare cross compiling, una cosa è il sistema running (ospite), un'altra la configurazione target e devono poter convivere.

[marcoc1712]

Compilare per ogni versione è improbabile, e sperare che ogni utente finale si compili da solo per il suo sistema è ancora più improbabile.

Compilare linkando staticamente è un po' un macello, mi sto informando in questi giorni ma non pare per nulla semplice... soprattutto per osx, su linux sembra più fattibile. Non si possono far felici tutti quindi basta farne felici molti, rilasciando i binari per i maggiori O.S. mentre per quelli minori/troppo vecchi basteranno le istruzioni, dettagliate, per la compilazione che scriveremo. Quindi mi sembra sensata la rimozione delle cartelle include (in macOS, rimuovendo la cartella include-osx si compila alla perfezione ... diversa la questione per libportaudio.a)

Per 10.7 l'ultima volta che l'ho fatto serviva, verificherò nuovamente.

[UnixMan]

Compilare linkando staticamente è un po' un macello, mi sto informando in questi giorni ma non pare per nulla semplice...

per sox l'ho fatto, altrimenti -dato il gran numero di dipendenze- distribuire dei binari che funzionino per tutte le infinite varianti in circolazione sarebbe stata una impresa praticamente impossibile.

Per squeezelite-R2, se ci limitiamo ad includere solo lo stretto indispensabile (nessuna lib esterna opzionale, i.e. OPTS="-DALSA -DDSD" e niente altro), sostanzialmente non serve. Un build minimale dipende praticamente solo dalle glibc e dalla lib di ALSA:

$ ldd /usr/local/bin/squeezelite-R2
        linux-vdso.so.1 (0x00007fff1bead000)
        libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007fcfb115a000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcfb0f3d000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcfb0c3b000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcfb0a33000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcfb082f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcfb0483000)
        /lib64/ld-linux-x86-64.so.2 (0x0000556ee2c4c000)

Se le lib "di sistema" sono compatibili con quelle utilizzate per il build, non c'è problema (anche con link dinamico). Se invece sono incompatibili, in questo caso anche una eventuale versione con link statico non funzionerebbe comunque. Per cui non ci guadagneresti nulla.

Diverso il discorso se vuoi includere nel build anche tutte le altre opzioni, nel qual caso le dipendenze aumentano.

No, non funziona così, ti scarichi la SDK che permette di produrre i binari per il sistema target ed usi quella, impostando opportunamente i FLAGS (v. make). [...]

ehm... guarda che alla fine stiamo dicendo esattamente la stessa cosa.

sono convinto (ma non lo per certo) che se vuoi compilare per Debian in Ubuntu (con ALSA 1.0.29) dovrai avere le header di ALSA 1.0.28 installate da qualche parte e far riferimento a quelle., altrimenti su debian non andrà.

no, con gli header di libasound2 v. 1.0.28 la versione attuale di R2 non la puoi proprio compilare! È del tutto incompatibile.

Jessie (as-is) non è più supportabile, full stop.

Al massimo per Jessie (come per altre distro che hanno ALSA<1.0.29) puoi produrre una versione dedicata priva del supporto DSD. Escludendo quello dovrebbe essere possibile compilare senza errori anche con versioni più datate delle alsa lib (se non lo è sarebbe un piccolo baco nel codice... facilmente risolvibile).

[marcoc1712]

ho aggiunto la versione per windows (senza dll, uso minimale) nei link in testa. Compilata con MSVC2015, con toolset x 8.1 e supporto XP. Testata su XP e win10, funziona, sarebbe da verificare su win 7 ed 8.

[UnixMan]

«
[16-May-16]
[...]
Moved TEAC-501 patch to archive. Patch was close but not sufficient.
Investigation not complete due to lack of (access to) a TEAC-501.
»
https://github.com/lintweaker/xmos-native-dsd

No, il tuo Teac non è supportato. [...]

Simone, big news per te: nell'ultima versione (4.10) del kernel è stato (re)introdotto il supporto:

“usb-audio: Add native DSD support for TEAC 501/503 DAC”

ALSA: usb-audio: Add native DSD support for TEAC 501/503 DAC
This patch adds native DSD support for the following devices.

- TEAC NT-503
- TEAC UD-503
- TEAC UD-501

(1) Add quirks for native DSD support for TEAC devices.
(2) A specific vendor command is needed to switch between PCM/DOP and
    DSD mode, same as Denon/Marantz devices.

https://git.kernel.org/cgit/linux/ke...0e292e45dba6ad