DSD in LMS con SOX

[SimoneFil]

AAARGH, ferma!!!

Così facendo stai installando (o tentando di installare) un pacchetto destinato ad una distribuzione diversa!!! (testing o Sid, se non addiritura experimental!)

È una cosa che non si fa. Rischi di fare dei disastri inenarrabili.

Al limite, in qualche caso - ma con molta prudenza - si può ricorrere casomai ai "backports":

https://backports.debian.org/

Ma si tratta comunque di cose che non vanno assolutamente fatte se devi compilare dei binari destinati ad essere distribuiti ad altri!!

(...non per caso sox l'ho compilato staticamente, per giunta in una "chroot" con una installazione fresca, intonsa e minimale).

In generale (ed in particolare nel caso specifico) se ti trovi ad aver a che fare con un sistema troppo datato per ciò di cui hai bisogno, di solito la cosa migliore (nonché la più sicura) è aggiornare l'intera distribuzione alla versione successiva, cioè a "testing" (che in questo momento è "Stretch") oppure, se necessario, anche fino ad unstable/Sid.


partire forse partirà anche... ma poi funziona? (in DSD?)

In verità avevo inizialmente aggiornato tutto "il gruppo alsa" per fare una cosa quanto meno decente. Quello compilato poi funzionava senza problemi su raspbian pulito. Intanto scarico ubuntu server e vi tengo aggiornati.

la e-mail ce l'ho praticamente sempre sott'occhio. Un tuo mail (inviato dal forum) l'ho ricevuto e ti ho anche risposto... ore fa. Non hai ricevuto la risposta?

mmm niente di niente, puoi inviare di nuovo direttamente a info@simonefilippini.it ? Grazie mille

[marcoc1712]

In verità avevo inizialmente aggiornato tutto "il gruppo alsa" per fare una cosa quanto meno ...

Signori. la mia (poca) pazienza con Linux si è esaurita. Per quanto mi riguarda, questa versione di squeezelite ha come requisito ALSA v. 1.0.29 e quindi non è adatta a Debian.

...Mi sembra sempre di sbattere contro muri che si sapeva dall'inizio che fossero li...

p.s.

La cartella include NON è usata nella compilazione per debian, se la togli il risultato non cambia.

[SimoneFil]

Signori. la mia (poca) pazienza con Linux si è esaurita. Per quanto mi riguarda, questa versione di squeezelite ha come requisito ALSA v. 1.0.29 e quindi non è adatta a Debian.

...Mi sembra sempre di sbattere contro muri che si sapeva dall'inizio che fossero li...

p.s.

La cartella include NON è usata nella compilazione per debian, se la togli il risultato non cambia.

Hai ragione Marco non ricordavo. Solo per le versioni ARM è utilizzata. La cosa fa girare parecchio i cosiddetti visto che debian è una delle maggiori distribuzioni linux ... sarà una cosa da scrivere.

[UnixMan]

In verità avevo inizialmente aggiornato tutto "il gruppo alsa" per fare una cosa quanto meno decente.

beh, mi pare ovvio... altrimenti ti trovi dipendenze irrisolte, pezzi diversi con versioni potenzialmente incompatibili... e non funziona nulla. Il problema è che, con ogni probabilità, le lib di Stretch (o di Sid) dipendono a loro volta da altre librerie - quanto meno le glibc - in versioni più aggiornate (e quindi facilmente incompatibili) rispetto a quanto presente su Jessie.

mmm niente di niente, puoi inviare di nuovo direttamente a ...@...... ? Grazie mille

OK.

Per quanto mi riguarda, questa versione di squeezelite ha come requisito ALSA v. 1.0.29

Per la precisione, ALSA >= v. 1.0.29.

Ovvio che è così! E non può essere altrimenti. Chi è che ha pensato il contrario?

e quindi non è adatta a Debian.

rectio: non è adatta a Debian Jessie. Con Stretch (attualmente = "testing") e Sid (AKA "unstable") non ci sono problemi.

La cartella include NON è usata nella compilazione per debian, se la togli il risultato non cambia.

Hai ragione Marco non ricordavo. Solo per le versioni ARM è utilizzata. La cosa fa girare parecchio i cosiddetti visto che debian è una delle maggiori distribuzioni linux ... sarà una cosa da scrivere.

sarà mica che hai (e non avresti) dovuto fare quel gioco sporco (e molto poco raccomandabile) banalmente perché sul raspi non avevi installato il pacchetto "libasound2-dev"? Oppure perché magari c'era, ma in una versione troppo vecchia?

Se anche quella è una Jessie, sicuramente.

Io quegli "include alieni" li toglierei proprio di torno. Completamente. Tutti. Per qualsiasi sistema. Costituiscono una porcata inguardabile, foriera di una infinità di possibili problemi di difficile identificazione e soluzione. Sia per chi mantiene il codice che (soprattutto) per chi poi lo usa.

Invece di fare cose "strane", è necessario trovare il modo più "giusto" e corretto per ottenere il risultato. Laddove ciò sia possibile.

Cosa che poi consiste banalmente nell'assicurarsi che nel sistema su cui si fa il build siano state correttamente installate tutte le dipendenze (librerie e relativi headers) che servono, in versioni compatibili con quanto richiesto dai sorgenti di squeezelite.

Se questo "non si può fare", o non lo si può fare in un modo ragionevolmente "pulito" e semplice (anche e soprattutto per l'utente finale, che poi dovrà fare altrettanto per poter usare i binari prodotti) allora quel sistema va semplicemente dichiarato "incompatibile" e non può essere supportato (e non ha senso tentare di farlo!). In tal caso banalmente se ne supporta una versione più recente (se ne esiste una adeguata), oppure lo si abbandona del tutto in favore di altri.

Tutto questo per ribadire che - su qualsiasi architettura - Debian Jessie non supporta il DSD e non dispone di librerie compatibili con questa versione di R2(*). Pertanto deve essere abbandonato, non può essere incluso tra i sistemi supportati. Full stop.

(*) a meno di non fare magheggi tipo quelli che faccio io. Ma poi quella non è più una Jessie, e neanche una Debian: diventa un sistema "custom", del tutto personalizzato ed "unico". Che non fa testo. Evidentemente non può essere supportato né ha senso farlo: chi sia in grado di mettere in piedi e far funzionare una cosa del genere non ha certo difficoltà a scaricarsi i sorgenti di R2 e compilarseli da solo, sul suo sistema... come ho fatto io.

Lo stesso vale per qualsiasi altro sistema (Linux o altro che sia).

[SimoneFil]

beh, mi pare ovvio... altrimenti ti trovi dipendenze irrisolte, pezzi diversi con versioni potenzialmente incompatibili... e non funziona nulla. Il problema è che, con ogni probabilità, le lib di Stretch (o di Sid) dipendono a loro volta da altre librerie - quanto meno le glibc - in versioni più aggiornate (e quindi facilmente incompatibili) rispetto a quanto presente su Jessie.


OK.


Per la precisione, ALSA >= v. 1.0.29.

Ovvio che è così! E non può essere altrimenti. Chi è che ha pensato il contrario?


rectio: non è adatta a Debian Jessie. Con Stretch (attualmente = "testing") e Sid (AKA "unstable") non ci sono problemi.



sarà mica che hai (e non avresti) dovuto fare quel gioco sporco (e molto poco raccomandabile) banalmente perché sul raspi non avevi installato il pacchetto "libasound2-dev"? Oppure perché magari c'era, ma in una versione troppo vecchia?

Se anche quella è una Jessie, sicuramente.

Io quegli "include alieni" li toglierei proprio di torno. Completamente. Tutti. Per qualsiasi sistema. Costituiscono una porcata inguardabile, foriera di una infinità di possibili problemi di difficile identificazione e soluzione. Sia per chi mantiene il codice che (soprattutto) per chi poi lo usa.

Invece di fare cose "strane", è necessario trovare il modo più "giusto" e corretto per ottenere il risultato. Laddove ciò sia possibile.

Cosa che poi consiste banalmente nell'assicurarsi che nel sistema su cui si fa il build siano state correttamente installate tutte le dipendenze (librerie e relativi headers) che servono, in versioni compatibili con quanto richiesto dai sorgenti di squeezelite.

Se questo "non si può fare", o non lo si può fare in un modo ragionevolmente "pulito" e semplice (anche e soprattutto per l'utente finale, che poi dovrà fare altrettanto per poter usare i binari prodotti) allora semplicemente quel sistema va semplicemente dichiarato "incompatibile" e non può essere supportato (e non ha senso tentare di farlo!). In tal caso banalmente se ne supporta una versione più recente (se ne esiste una adeguata), oppure lo si abbandona del tutto in favore di altri.

Tutto questo per ribadire che - su qualsiasi architettura - Debian Jessie non supporta il DSD e non dispone di librerie compatibili con questa versione di R2(*). Pertanto deve essere abbandonato, non può essere incluso tra i sistemi supportati. Full stop.

(*) a meno di non fare magheggi tipo quelli che faccio io. Ma poi quella non è più una Jessie, e neanche una Debian: diventa un sistema "custom", del tutto personalizzato ed "unico". Che non fa testo. Evidentemente non può essere supportato né ha senso farlo: chi sia in grado di mettere in piedi e far funzionare una cosa del genere non ha certo difficoltà a scaricarsi i sorgenti di R2 e compilarseli da solo, sul suo sistema... come ho fatto io.

Lo stesso vale per qualsiasi altro sistema (Linux o meno che sia).

Sono completamente d'accordo con te Paolo ma ci sono ancora cose che mi sfuggono, è per questo motivo che ho provato anche a fare quelli che tu chiami "giochi sporchi", che nient'altro sono che metodi a casaccio per capire quale è la causa di un mal funzionamento. Jessie dà problemi, i DSD li riproduce in DOP, purtroppo in nativo non ho potuto provare ... da quel che so nemmeno con Daphile il mio Teaca UD-501 va in Nativo (mentre ad esempio l'ud-503 sì), ma questo non lo ritengo un problema grosso visto che sia in DoP che in "nativo" rimane limitato a DSD128.

Nell'arco di mezz'ora proverò a compilare squeezelite-R2 in Ubuntu server 16.10 per Rpi2 (sta volta ho preso l'ultima versione perchè non voglio problemi di librerie non aggiornate). Se tutto va come devo andare nella guida per l'uso su piattaforme ARM lo metteremo come distro consigliata ... poi ovvio che chi sa come fare non si pone nemmeno il problema e si piglia la distro che vuole e se qualcosa non va "lo fa andare" aggiornandola; ma in questo caso manco leggerebbe la guida.

Concordo anche per la faccenda della cartella "include", mi rendo conto del fatto che può apparire un metodo "poco ortodosso" (anche se non sono solito ragionare in questi termini) per far compilare squeezelite in più piattaforme possibili (anche se spesso causa danni); però bisogna considerare che l'alternativa PULITA sarebbe compilare con tutte le librerie linkate staticamente in modo tale da non dipendere da link dinamici a librerie del' O.S. che non si sa mai a che versione possano essere. (il linking dinamico ... questa sì che l'ho sempre considerata una enorme porcata per risparmiare qualche kb quando ormai vendono HDD da 8TB)
PURTROPPO qui subentra la mia ignoranza nel creare binari linkati staticamente; per curiosità imparerò di certo ma nel breve periodo mi rendo conto che tu Paolo su questo hai conoscenze ben più profonde delle mie.

[UnixMan]

[...] questo non lo ritengo un problema grosso visto che sia in DoP che in "nativo" rimane limitato a DSD128.

se/dove puoi, è comunque meglio andare in "nativo": data-rate dimezzato, meno rumore, meno carico per i sistemi, ... suono migliore. La differenza è piccola, ma sensibile.

Nell'arco di mezz'ora proverò a compilare squeezelite-R2 in Ubuntu server 16.10 per Rpi2 (sta volta ho preso l'ultima versione perchè non voglio problemi di librerie non aggiornate).

Nono, ferma. Usa la 16.04LTS!

Le versioni non-LTS vanno aggiornate ogni 6 mesi. Un incubo. La 16.04 ha già tutti i requisiti necessari. E per le LTS vengono resi disponibili aggiornamenti continui per almeno 5 anni. Inclusi "upgrade" -ufficiali- di parti critiche, come il kernel.

Concordo anche per la faccenda della cartella "include", mi rendo conto del fatto che può apparire un metodo "poco ortodosso" (anche se non sono solito ragionare in questi termini) per far compilare squeezelite in più piattaforme possibili (anche se spesso causa danni); però bisogna considerare che l'alternativa PULITA sarebbe compilare con tutte le librerie linkate staticamente in modo tale da non dipendere da link dinamici a librerie del' O.S. che non si sa mai a che versione possano essere.

No... per alcune cose (e.g. ALSA) non funziona neanche quello. Puoi ottenere il binario statico, e quello magari si avvia su qualsiasi sistema... ma se poi la versione di ALSA che quello "ha dentro" è incompatibile con quella che c'è nel Kernel, non funziona nulla.

Semplicemente, devi creare un binario specifico per ogni sistema supportato, o quanto meno per ogni "classe" di sistemi supportati ragionevolmente simili e compatibili tra loro. Non si scappa.

(il linking dinamico ... questa sì che l'ho sempre considerata una enorme porcata per risparmiare qualche kb quando ormai vendono HDD da 8TB)

non è stata pensata per risparmiare spazio su disco ma (soprattutto) per ridurre le richieste in termini di memoria! E non si tratta di pochi KB... una distribuzione completa in cui ogni binario fosse compilato staticamente occuperebbe una quantità di spazio mostruosa, sia in memoria che su disco.

[marcoc1712]

beh, mi pare ovvio... altrimenti ti trovi dipendenze irrisolte, pezzi diversi con versioni potenzialmente incompatibili... e non funziona nulla. Il problema è che, con ogni probabilità, le lib di Stretch (o di Sid) dipendono a loro volta da altre librerie - quanto meno le glibc - in versioni più aggiornate (e quindi facilmente incompatibili) rispetto a quanto presente su Jessie.


OK.


Per la precisione, ALSA >= v. 1.0.29.

Ovvio che è così! E non può essere altrimenti. Chi è che ha pensato il contrario?

Cosa che poi consiste banalmente nell'assicurarsi che nel sistema su cui si fa il build siano state correttamente installate tutte le dipendenze (librerie e relativi headers) che servono, in versioni compatibili con quanto richiesto dai sorgenti di squeezelite.

Se questo "non si può fare", o non lo si può fare in un modo ragionevolmente "pulito" e semplice (anche e soprattutto per l'utente finale, che poi dovrà fare altrettanto per poter usare i binari prodotti) allora quel sistema va semplicemente dichiarato "incompatibile" e non può essere supportato (e non ha senso tentare di farlo!). In tal caso banalmente se ne supporta una versione più recente (se ne esiste una adeguata), oppure lo si abbandona del tutto in favore di altri.

Tutto questo per ribadire che - su qualsiasi architettura - Debian Jessie non supporta il DSD e non dispone di librerie compatibili con questa versione di R2(*). Pertanto deve essere abbandonato, non può essere incluso tra i sistemi supportati. Full stop.

(*) a meno di non fare magheggi tipo quelli che faccio io. Ma poi quella non è più una Jessie, e neanche una Debian: diventa un sistema "custom", del tutto personalizzato ed "unico". Che non fa testo. Evidentemente non può essere supportato né ha senso farlo: chi sia in grado di mettere in piedi e far funzionare una cosa del genere non ha certo difficoltà a scaricarsi i sorgenti di R2 e compilarseli da solo, sul suo sistema... come ho fatto io.

Lo stesso vale per qualsiasi altro sistema (Linux o altro che sia).

Io ho pensato il contrario, visto il tuo OK di qualche giorno fa.

Per me è stata francamente una sorpresa scoprire che su un debian jessie non va, ma ancora di più che lo sapevi e lo davi per scontato, dato che almeno nella mia testa, mi aspettavo di ricevere eventuali warning ed il 'go' finale per la specifica distribuzione da:

Win Io/Filippo
Osx Simone
Debian i386/arm64 Paolo

Altri

Gentoo Io/Filippo
FreBSD Simone
Raspbian Simone
RaspBSD Simone

con lo scopo di non dover provare personalmente tutto (cosa che non riesco materialmente a fare) e comunque di provvedere prima o poi a quanto c'è già in giro (pacchetto .deb ed easetup), rimanendo inteso che il contributo di tutti è prezioso su ogni aspetto, ma smarcare i singoli obiettivi in modo preciso è fondamentale, altrimenti non si riesce a chiudere nulla.

Possiamo fare punto zero e stabilire che è così, d'ora in poi?

BTW, da qualche parte, mentre cercavo la soluzione, ho letto che compilando tutto alsa (alsa lib ed alsa utils) non è più indispensabile cambiare il kernel, diventa un ambiente concluso a se stante. Probabilmente quello che ha verificato Simone.

Detto questo, mi aspetto le note da mettere a riguardo di Debian, qulasiasi esse siano.

[SimoneFil]

Ubuntu per Raspberry Pi 2 : compilato tutto

Allego il makefile utilizzato (è per Rpi2, posso farlo specifico pure per Rpi3 o Rpi volendo)

OPTS = -DDSD -DALSA -I./include-rpi
CFLAGS  ?= -Wall -fPIC -s -O3 -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard $(OPTS)
LDFLAGS ?= -s -lasound -lpthread -lm -ldl -lrt -Wl,-rpath,/usr/local/lib
EXECUTABLE ?= squeezelite-rpi2

Per quanto riguarda Raspbian le uniche indicazioni che mi sento sinceramente di dare sono: non usarlo. C'è ubuntu che è pronto all'uso, veramente non c'è motivo di impazzire con raspbian. Se proprio uno vuole farlo come hai detto te c'è da compilare un bel po' di roba... io l'ho fatto ma ne vale la pena? Non ho trovato delle immagini stretch per Raspbian ma solo repo.

Per quanto riguarda Debian, se ne occupa Paolo, ma da quel capito basterebbe indicare di utilizzare una stretch -> https://www.debian.org/devel/debian-installer/
Ma ripeto, per questo lascio la parola a Paolo.

[marcoc1712]

Ubuntu per Raspberry Pi 2 : compilato tutto

Allego il makefile utilizzato (è per Rpi2, posso farlo specifico pure per Rpi3 o Rpi volendo)

OPTS = -DDSD -DALSA -I./include-rpi
CFLAGS  ?= -Wall -fPIC -s -O3 -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard $(OPTS)
LDFLAGS ?= -s -lasound -lpthread -lm -ldl -lrt -Wl,-rpath,/usr/local/lib
EXECUTABLE ?= squeezelite-rpi2

Per quanto riguarda Raspbian le uniche indicazioni che mi sento sinceramente di dare sono: non usarlo. C'è ubuntu che è pronto all'uso, veramente non c'è motivo di impazzire con raspbian. Se proprio uno vuole farlo come hai detto te c'è da compilare un bel po' di roba... io l'ho fatto ma ne vale la pena? Non ho trovato delle immagini stretch per Raspbian ma solo repo.

Per quanto riguarda Debian, se ne occupa Paolo, ma da quel capito basterebbe indicare di utilizzare una stretch -> https://www.debian.org/devel/debian-installer/
Ma ripeto, per questo lascio la parola a Paolo.

Mai provato Volumio? Per la precedente versione avevo inserito squeezelite a fianco di MPD, adesso sono solo MPD, ma... E' Debian.

Togliamo Rapsbian e metti quello che vuoi, ma ti chiedo una cortesia, puoi rivedere il tuo precedente messaggio con gli include e tutto il resto in forma defintiva? no so più se Fresbd ha bisogno dellì'include o no, se ha lo stesso problema di Debian con ALSA e RaspBSD?

Grazie.

[SimoneFil]

Mai provato Volumio? Per la precedente versione avevo inserito squeezelite a fianco di MPD, adesso sono solo MPD, ma... E' Debian.

Togliamo Rapsbian e metti quello che vuoi, ma ti chiedo una cortesia, puoi rivedere il tuo precedente messaggio con gli include e tutto il resto in forma defintiva? no so più se Fresbd ha bisogno dellì'include o no, se ha lo stesso problema di Debian con ALSA e RaspBSD?

Grazie.

Il Makefile postato appena sopra è FUNZIONANTE per Raspberry Pi2 e Raspberry Pi 3 in UBUNTU 16.04. Con ovviamente la cartella include-rpi che ti ho inviato per e-mail.

Visto che me l'hai chiesto FreeBSD e RaspBSD non soffrono di questo problema per il semplice fatto che non esiste alsa nei sistemi *BSD. Come per OSX squeezelite si appogia a portaudio che interagisce con OSS. Ti prego però per queste due versioni di dichiararla come ALPHA .. cioè ancora in fase di testing (non hanno problemi a compilare però devo approfondire il testing). Quindi i makefile che ti avevo mandato per questi due OS sono corretti e NON da modificare.


Infine Volumio l'ho provato sì .. forse Michelangelo aveva fatto ciò che abbiamo fatto io e Paolo ... cioè aggiornare alsa, ma è solo una supposizione.