DSD in LMS con SOX

[marcoc1712]

SoX è GPL, non esiste alcuna restrizione per la distribuzione binari. Ovviamente si devono mettere a disposizione anche i sorgenti, ma quelli sono già su git... quindi, qual è il problema?

SOX comprende librerie proprietarie che non si possono distribuire in binario (almeno LAME), è un fatto cui porre attenzione ed è sempre responsabilità di chi distribuisce il binario.

nei binari che ho prodotto io non c'è nessuna modifica.

Se per linux e (win minGW) non hai modificato nulla e dal semplice download del repo di mansr è possibile riprodurre ESATTAMENTE i tuoi binari, non hai bisogno di documentare nulla.

Quelle che eventualmente avete dovuto fare voi per riuscire a compilarlo con il compilatore M$ o per os/x mandatele a Måns in modo che le integri, ed il gioco è fatto (poi speriamo che anche le sue modifiche siano integrate quanto prima nella versione ufficiale...)..

No, non basta, altrimenti lo stesso potrebbe fare mansr nei confronti di sox.

Per osx c'è una patch pendente, per WIN ancora non lo so, parrebbe essere così per win32, proprio perchè abbiamo sempre operato di concerto con mansr..

Di mio, ho SEMPRE comunicato a Mansr ed altri e lo ha fatto anche Simone, ma non si può costringere nessuno a modificare i propri repo, l'obbligo di accertarsi della corrispondenza tra quanto distribuisco in binario, la sottostante documentazione e codice sorgente è di chi lo distribuisce, così come quello di produrlo a richiesta.

eviterei questa proliferazione di fork e di repositories... non ce n'è motivo, e si rischia di creare solo confusione. Cerchiamo di andare alla fonte, tanto più che non stiamo modificando il codice ma, casomai, solo sistemando dei bug nei "progetti" per il build.

Sono il primo a cercare di evitare quanto più possibile la proliferazione delle versioni, per questo ho insistito perchè Ralphy diventasse l manutentore 'ufficiale' di squeezelite per la community e per questo lo tengo SEMPRE informato diquello che faccio e lo stesso con Mansr.

Però, MOLTO peggio di un nuovo repostory - anche se inutile e ridondante - è una distribuzione non documentata e PEGGIO - non distinguibile dal mainstream o da altre per nome e/o versione.

Gli strumenti di controlo di configurazione come git (e gitHub) esistono ESATTAMENTE per questo, quindi - per quanto mi riguarda - se distribuisco qualcosa in binario non disponibile altrimenti, ci sarà sempre un repository sottostante configuato in modo da permettere a chiunque di produrre lo stesso binario e vsualizzare sorgenti ed impostazioni, magari come semplice clone o rimando al repository originario, anche se - di certo - non lo faccio al semplice scopo di cambiare nome o versione.

Non ti piace gitHub? vuoi tenerlo 'nascosto'? come vuoi, ma a richiesta sono informazioni che DEVI produrre, per la via meglio pubblicarle subito.

Come sempre ognuno risponde delle proprie azioni.

[UnixMan]

SOX comprende librerie proprietarie che non si possono distribuire in binario (almeno LAME), è un fatto cui porre attenzione ed è sempre responsabilità di chi distribuisce il binario.

LAME non è affatto proprietario, tutt'altro! È rilasciato con licenza LGPL. Non c'è nessun problema da quel punto di vista.

Il problema di Lame (così come di qualsiasi altro encoder e/o decoder mp3) è il fatto che l'algoritmo mp3 stesso, o meglio diverse tecniche su cui questo si basa, sono brevettate. A prescindere dall'implementazione (idem per AAC). È pura follia ma - nei paesi che riconoscono questa assurdità dei brevetti sul software - così è:

PI: Gli mp3 ora si pagano, player a rischio

o meglio, era. In UE (e presto anche negli US) il problema non si pone più:

“The basic MP3 decoding and encoding technology is patent-free in the European Union, all patents having expired there by 2012 at the latest. In the United States, the technology will be substantially patent-free on 31 December 2017 (see below). The majority of MP3 patents expired in the US between 2007 and 2015.”

da Wikipedia: MP3 Licensing and patent issues

Per ogni evenienza, puoi aggiungere una nota come questa:

“Please note that the use of this software may require the payment of patent royalties for MP3 and AAC format. You need to consider this issue before you start building derivative works. We are not warranting or indemnifying you in any way for patent royalities! YOU ARE SOLELY RESPONSIBLE FOR YOUR OWN ACTIONS!”

Comunque, per quanto mi riguarda possiamo anche compilare sox senza lame né altri formati affetti da problemi analoghi. A me serve solo FLAC, che è Open in tutto e per tutto...

Se per linux e (win minGW) non hai modificato nulla e dal semplice download del repo di mansr è possibile riprodurre ESATTAMENTE i tuoi binari, non hai bisogno di documentare nulla.

è così.

No, non basta, altrimenti lo stesso potrebbe fare mansr nei confronti di sox.

eh? Non direi: quella è una versione diversa, modificata, i sorgenti non sono gli stessi.

Per osx c'è una patch pendente, per WIN ancora non lo so, parrebbe essere così per win32, proprio perchè abbiamo sempre operato di concerto con mansr..

appunto. Se finisce tutto nel repo di Måns, e si fa riferimento a quello... problema risolto.

[SimoneFil]

Comunque, per quanto mi riguarda possiamo anche compilare sox senza lame né altri formati affetti da problemi analoghi. A me serve solo FLAC, che è Open in tutto e per tutto...

Eviterei sinceramente di pubblicare sox privato di formati che comunque sono molto diffusi così come l'mp3. Ovviamente per un uso personale ognuno fa quel che vuole, ma in visione di una pubblicazione di tutto questo lavoro (anche solo nel forum) non limiterei così tanto sox, almeno non per quando riguarda i formati più diffusi e usati, IMHO.

Mi rendo conto che per quanto riguarda la pubblicazione ognuno abbia una propria "filosofia" o etica. Fosse per me pubblicherei binari e script bash che installi tutto in automatico e stop, poi se qualcuno vuole sorgente e/o istruzioni può scrivermi per e-mail.

OVVIAMENTE comprendo perfettamente ciò che dice Marco a riguardo. Ed è per questo che, per rendere il lavoro più facile, ho deciso di contribuire con GitHub ora e in futuro quando mi occuperò della parte riguardante la compilazione per Raspberry (abbiate pazienza, fino al 22 ho veramente poco tempo, dopo sarò più libero); nonostante sia uno strumento che non uso (Github). Quando si distribuirà il tutto mi impegnerò a mantenere aggiornati i binari da distribuire per quando riguarda i s.o. che ho deciso di trattare per dare una mano.

Detto ciò mi pare si stia discutendo di ciò che si farà giunti alla meta mentre siamo ancora in viaggio

[antonellocaroli]

Quello che abbiamo visto con Marco, su Windows con Visual Studio si puó fare solo a 32 bit

32 bit normale
32 bit SSE2
32 bit AVX

Ma non saprei se servono....visto che Paolo giá ha fatto le due versione 32 e 64 per win....

[marcoc1712]

Quello che abbiamo visto con Marco, su Windows con Visual Studio si puó fare solo a 32 bit

32 bit normale
32 bit SSE2
32 bit AVX

Ma non saprei se servono....visto che Paolo giá ha fatto le due versione 32 e 64 per win....

hai verificato signiicative differenze di prestazioni tra le tre?

[antonellocaroli]

hai verificato signiicative differenze di prestazioni tra le tre?

l´unica Cosa che ho confrontato é la velocitá di conversione...che é praticamente identica!!! quello che non ho controllato l´uso della cpu in LMS...devo vedere...

[marcoc1712]

l´unica Cosa che ho confrontato é la velocitá di conversione...che é praticamente identica!!! quello che non ho controllato l´uso della cpu in LMS...devo vedere...

Se le differenze non sono enormi, terrei la sola verisone a 32 bit 'semplice' anche perchè non riesco a distribuire 3 versioni diverse per la stessa archtettura (win32), senza implementare qualcosa di specifico nel plugin.

Bisognerebbe capire che versioni di windows sono in grado di eseguirla (XP no, purtroppo, come abbiamo visto, ma compilata per xp rallenta realmente troppo anche sulle altre versioni).

Altra prova da fare sarebbe un confronto di prestazioni con le verisoni prodotte con minGW in cross compiling, così decidiamo quali distribuire, se arrivassimo ad 1 o max 2 (32 e 64) sarebbe perfetto, poi i più esperti potranno sempre compilarsi la loro.

[marcoc1712]

AH, mi è venuta l'illuminazione adesso...

Ovviamente, è possibile fare un plugin a se stante per la sola installazione di sox, così da poterlo 'caricare' come si vuole, se in c-3po diventa troppo complicato...

[SimoneFil]

Sto provando a compilare per rpi, durante la compilazione mi dà vari errori: risolti tutti tranne il seguente, secondo voi cosa può essere?

pi@raspberrypi:~/squeezelite-R2 $ make -f Makefile.rpi
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include main.c -c -o main.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include slimproto.c -c -o slimproto.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include utils.c -c -o utils.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include buffer.c -c -o buffer.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include stream.c -c -o stream.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include decode.c -c -o decode.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include flac.c -c -o flac.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include pcm.c -c -o pcm.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include mad.c -c -o mad.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include vorbis.c -c -o vorbis.o
cc -Wall -fPIC -s -O3 -march=armv6 -mfloat-abi=hard -mfpu=vfp -DVISEXPORT -DDSD -DGPIO -DRPI -DIR -I./include output_alsa.c -c -o output_alsa.o
output_alsa.c: In function ‘alsa_open’:
output_alsa.c:422:17: error: ‘SND_PCM_FORMAT_DSD_U16_BE’ undeclared (first use in this function)
   alsa.format = SND_PCM_FORMAT_DSD_U16_BE; break;
                 ^
output_alsa.c:422:17: note: each undeclared identifier is reported only once for each function it appears in
output_alsa.c:424:17: error: ‘SND_PCM_FORMAT_DSD_U32_LE’ undeclared (first use in this function)
   alsa.format = SND_PCM_FORMAT_DSD_U32_LE; break;
                 ^
output_alsa.c:426:17: error: ‘SND_PCM_FORMAT_DSD_U32_BE’ undeclared (first use in this function)
   alsa.format = SND_PCM_FORMAT_DSD_U32_BE; break;
                 ^
Makefile.rpi:20: recipe for target 'output_alsa.o' failed
make: *** [output_alsa.o] Error 1

[antonellocaroli]

Altra prova da fare sarebbe un confronto di prestazioni con le verisoni prodotte con minGW in cross compiling, così decidiamo quali distribuire, se arrivassimo ad 1 o max 2 (32 e 64) sarebbe perfetto, poi i più esperti potranno sempre compilarsi la loro.

Mi prometto di farle...non si protrebbe mettere in prima pagina i link ai vari binari prodotti fino ad adesso?