DSD in LMS con SOX

[marcoc1712]

Io ho corretto il makefile.osx perchè quello in github non è corretto. Ho tolto sia lib_osx che include-osx; non servono.
Lo sto ricompilando ora per aggiornare il link però sembra che non compili dsd.c dop.c dsd2pcm.c

Se stai parlando del 'vecchio' Makefile.osx

a. come fai a compilare senza lib_osx che contiene portaudio.pa ? devi puntare ad un'altra directory che non è detto sia presente sul sistema di compilazione...
b. lo stesso dicasi per include_osx, dove cerchi le librerie di flc, mad ed altro (/usr/local/include) ? Come le carichi?

Se stai parlando del nuovo,

arrivaci in fondo poi lo provo, ma Ralphy di certo non compila dsd.c .... non ce l'ha, lo devi aggiungere all'elenco dei sorgenti da compilare.
OCCHIO allea doppia architettura, i386 è irrinunciabile (almeno per me).

[SimoneFil]

Se stai parlando del 'vecchio' Makefile.osx

a. come fai a compilare senza lib_osx che contiene portaudio.pa ? devi puntare ad un'altra directory che non è detto sia presente sul sistema di compilazione...
b. lo stesso dicasi per include_osx, dove cerchi le librerie di flc, mad ed altro (/usr/local/include) ? Come le carichi?

Se stai parlando del nuovo,

arrivaci in fondo poi lo provo, ma Ralphy di certo non compila dsd.c .... non ce l'ha, lo devi aggiungere all'elenco dei sorgenti da compilare.
OCCHIO allea doppia architettura, i386 è irrinunciabile (almeno per me).

a) c'è -lportaudio, la prende dal sistema
b) Come per a)

E sono le uniche due cose che cambiano nel make file, dovrebbe compilare comunque. P.s. se il tuo mac mini è >= 2007 ti conviene aggiornare a Sierra e stare sui 64bit

[marcoc1712]

infatti. Conviene importare quell'aggiornamento dal repository di Ralph, così da risolvere il problema in modo pulito e restando allineati. Marco?

Squeezelite-R2 NON origina dal repository di Ralphy ma da quello originario di Triode, unico punto comune ai 2 (e solo logicamente, tra l'altro, fisicamente originiamo da due cloni diversi del repository che era in google code), quindi non c'è nessuna automatismo nei due sensi, l'allineamento non è garantito ed avviene o per 'cherry picks' (se possibile) o in modo del tutto manuale, come con Daphile.

Quanto sopra sia per motivi storici (la decisione di Ralphy di manutenere al versione community, da me sollecitata e sostenuta, è successiva alla nascita di R2, prima era una versione parallela a quella, ai tempi ancora viva, di Triode in google code) che per scelta personale: quella versione contiene troppe cose, per i miei gusti e non ne contiene altre per me importanti (DSD per esempio).

Detto questo, io informo SEMPRE Ralphy di quanto faccio e lo invito ad integrarlo, anche quando la provenienza è Daphile (o altro), ma poi decide lui.

Detto questo, il modo per me è indifferente, se Simone vuole provare una merge sul suo repo (che è un clone del mio) è libero, alla fine per passare le modifiche 'upstream' dovrà fare una pool request che non dipende dall'origine delle modifiche stesse e non le traccia. Il risultato è analogo.

Personalmente lo sconsiglio, a meno che non sia coinvolto un solo file e si sia assolutamente certi che va bene per com'è, altrimenti meglio modificare manualmente e mettere eventuali credits nelle note.

[marcoc1712]

a) c'è -lportaudio, la prende dal sistema
b) Come per a)

E sono le uniche due cose che cambiano nel make file, dovrebbe compilare comunque. P.s. se il tuo mac mini è >= 2007 ti conviene aggiornare a Sierra e stare sui 64bit

Ripeto:

Se stai parlando del nuovo, arrivaci in fondo poi lo sostituiamo.

Se, però, stai parlando del vecchio non è come dici:

non c'è nulla che installi portaudio e nemmeno le headers di flac, mad,... tant'è che Makefile.osx punta ESPLICITAMENTE a quelle due directory, con il problema noto di dover recuperare portaudio.a da qualche parte e metterlo in lib_osx.

--

Il mio mac Mini ed il macbook Air sono del 2009, ma non è quello il punto, ho utenti che usano sistemi i386 e non posso/voglio costringerli all'upgrade di distema, in qualche modo rilascerò o due versioni dedicate o una a doppia architettura (preferibile).

[SimoneFil]

Ripeto:

Se stai parlando del nuovo, arrivaci in fondo poi lo sostituiamo.

Se, però, stai parlando del vecchio non è come dici:

non c'è nulla che installi portaudio e nemmeno le headers di flac, mad,... tant'è che Makefile.osx punta ESPLICITAMENTE a quelle due directory, con il problema noto di dover recuperare portaudio.a da qualche parte e metterlo in lib_osx.

--

Il mio mac Mini ed il macbook Air sono del 2009, ma non è quello il punto, ho utenti che usano sistemi i386 e non posso/voglio costringerli all'upgrade di distema, in qualche modo rilascerò o due versioni dedicate o una a doppia architettura (preferibile).

Quanto installi le dipendenze hai già tutto, in fase di compilazione c'è già tutto in /usr/local/include e in /usr/local/lib, e la stessa cosa vale per linux, su Ubuntu per Raspberry Pi l'ho compilato cancellando la cartella include (e va alla perfezione, e non ha nemmeno i problemi elencati da Paolo). Ora tento di capire perchè non mi compila dsd.c dop.c dsd2pcm.c ...

[UnixMan]

Personalmente lo sconsiglio, a meno che non sia coinvolto un solo file e si sia assolutamente certi che va bene per com'è, altrimenti meglio modificare manualmente e mettere eventuali credits nelle note.

banalmente il Makefile...

[marcoc1712]

Quanto installi le dipendenze hai già tutto, in fase di compilazione c'è già tutto in /usr/local/include e in /usr/local/lib, e la stessa cosa vale per linux, su Ubuntu per Raspberry Pi l'ho compilato cancellando la cartella include (e va alla perfezione, e non ha nemmeno i problemi elencati da Paolo). Ora tento di capire perchè non mi compila dsd.c dop.c dsd2pcm.c ...

In linux (debian), include non è usata dal makefile, infatti c'è la nota specifica di quali dipendenze dinamiche bisogna risolvere. La cosa NON mi piace, ma tant'è.

Per OSX, invece, scusa, ma ripeto di nuovo la domanda altrimenti non capisco:

Parli del vecchio Makefile.osx o del nuovo che stai facendo tu?

SE nel nuovo non so, avrà una sua coerenza interna, presumo, che verificheremo quando avrai finito. - STOP, non leggere oltre -

SE, invece, ti riferisci al vecchio, cosa vuol dire 'quando installi le dipendenze'? Dove vengono puntate /usr/local/include e in /usr/local/lib?

Ovviamente SE risolvi manualmente tutte le dipendenze, installando headers e librerie in cartelle diverse e cambi i link nel makefile funziona... ma il punto è proprio che il vecchio prevede che le headers siano in ./include_osx e portaudio.a in ./lib_osx, fornendo una 'struttura' che consente la compilazione senza installare nulla nel sistema, ovviamente se non sono li, non funziona.

E' questo che non capisco.

[marcoc1712]

banalmente il Makefile...

Evidentemente no. E' coinvolta almeno anche la struttura delle directory a supporto, almeno ./include_osx e ./lib_osx ed il loro contenuto, più le istruzioni a supporto in merito a dipendenze da risolvere esternamente, se non si usano più le librerie fornite a corredo.

[UnixMan]

Evidentemente no. E' coinvolta almeno anche la struttura delle directory a supporto, almeno ./include_osx e ./lib_osx ed il loro contenuto, più le istruzioni a supporto in merito a dipendenze da risolvere esternamente, se non si usano più le librerie fornite a corredo.

sì, certo... quelle vengono eliminate, e c'è l'indicazione di cosa fare e come.

[marcoc1712]

Mi servirebbe una prova veloce:

avendo individuato il formato che funziona con il vs. dac, poniamo u32le:

squeezelte-R2 -D u32le
squeezelte-R2 -D :u32le
squeezelte-R2 -D 0:u32le
squeezelte-R2 -D 1:u32le
squeezelte-R2 -D u32le:1
squeezelte-R2 -D u32le:0

funzionano tutti? (perchè li accetta tutti, ma non so quali suonano e quali no)

Stando quello che leggo nel codice, dovrebbero funzionare solo:

squeezelte-R2 -D :u32le
squeezelte-R2 -D 0:u32le
squeezelte-R2 -D 1:u32le

con un dubbio su,

squeezelte-R2 -D u32le

che forse si infila in un buco/baco.

Grazie.