DSD in LMS con SOX

[UnixMan]

Altra cosa strana: la nuova versione usa (leggermente) più CPU... e mi da pure l'impressione che suoni peggio?!

...fortunatamente ho tenuto sia il binario che i sorgenti dell'altra. Se vuoi faccio un diff globale per riferimento.

[marcoc1712]

Ahi... però con questa versione sono ricomparsi i rumoracci tra una traccia e l'altra...

.stai sereno (come diceva uno che ha fatto una brutta fine e tenta di trasformarla in bell'inizio...)

a. 1_8_4 è un 'tappabuchi' per eventuali necessità di intervento su release, senza cambiar release. Non ha DSD.

b. Makefile.gentoo è praticamente identico, come eseguibile prodotto, a Makefile.debian (Io l'ho sempre detto che si poteva prendere l'eseguibile di debian ed appoggiarlo in gentoo...) tranne che imposta EXTRALIBS invece di LDFLAGS, perchè così vuole gentoo.

Non so da dove prendi quello che posti e che ha ancora i LDFLAGS.

Questo è il mio.

CFLAGS  ?= -Wall -fPIC -O2 $(OPTS) 
#LDFLAGS ?= -lasound -lpthread -lm -lrt 
EXTRALIBS ?= -lasound -lpthread -lm -lrt 
EXECUTABLE ?= squeezelite-R2
...

Lo devi lanciare impostando le OPTS da riga di comando o lasciarlo fare a portage con le useflags (immagino).

c. la versione DSD... non compila(va) con -DALSA, per un baco, adesso compila ma ci sono warnings che non mi piacciono, ci devo lavorare sopra.

d. La versione 'buona' per compilare in win10 ed XP ce l'ha Filippo, io ho solo l'eseguibile di XP., quando arriva la nuova macchina mi attrezzo con MSVC2015 e l'avrò anchio

.

[marcoc1712]

La versione DSD... adesso si compila senza errori o warnings, non so dirvi se suona però...

l'errore era una c...a mia, che però non vedevo senza compilare con DSD ed ALSA attivi, le warnings qualcosa di più subdolo introdotto dall'ultima patch, ma adesso dovrebbe essere risolto.

Provate e vediamo di chiudere il giro.

p.s.

nel frattempo ho rilasciato anche una versione corretta di C-3PO, ma non sono riuscito a riprodurre l'errore segnalato da SimoneFil uscendo in wav, uscendo in dsf/dff si e l'ho corretto.

Provate anche questo per favore.

[SimoneFil]

Sto chiudendo la release di Squeezelite-R2 e cerco di raccapezzarmi in meito ai makefile che sono stati usati e verificati per comes ono, quelli che così come sono non funzionano e le eventuali modifiche (a loro o alla struttura delle cartelle di include e lib) da apportare per farle funzionare.

Stare dietro a tutto quetso è mortale e richiede sforzi che io NON sono disponibile a grantire per manutenzione futura, voglio chiudere questo inventario facendo un punto 0, indicando quello che so, ma vi pego di NON RISPONDERE qui è troppo dispersivo, so di certo che Simone mi aveva amandato qualcosa, non ricordo a proposiito di che, ma non lo trovo più.

Il metodo è mandatemi una segnalazione (issue o molto meglio pull request) sul repository, così non rischio nemmeno di sbagliare nel riportarle.

Per farlo è necessario iscriversi, ma è gratis e così possiamo impostare anche metodi più efficaci di collaborazione su tutto.

Una nota di attenzione, dato che so che è successo, ma non ricordo dove:

SE per far funzionare un makefile dovete cambiare il contenuto di ./include, allora occorre differenziare ./include, come ho fatto per osx.

la versone attuale è ok per debian linux e win e direi di mantenerla com'è. Nella richiesta o pull request mandatemei anche la nuova cartella con il suo contenuto (solo header però, NO librerie dinamiche o statiche, quelle non le distribuisco (non possono nemmeno stare in github), magari mettiamo un readme con nome, versione ed origine di quelle provate e funzionanti).

Nel file di istruzioni io ho catalogato i files di supporto alla compilazione come segue:

- Makefile.minimal
- Makefile.osx
- squeezelite.vproj*

sono testati e garantiti funzionanti, in quanto usati da me per produrre le versioni binarie distribuite con la release.

- Makefile.pa
- Makefile.resample

sono esempi di come aggiungere opzioni in linux, in questo caso.

- Makefile.debian-i386
- Makefile.debian-x86-64
- Makefile.gentoo
- Makefile.freebsd
- Makefile.rpi
- Makefile.osx-i386
- Makefile.osx-ppc
- Makefile.osx-ppc64
- Makefile.osx-x86_64

sono versioni inserite da terzi (rispetto a me) che hanno funzionato almeno una volta ma che non vengono necessariamnete verificate PRIMA del rilascio di ogni nuova versione.

Per ognuna di queste (o altre che si vorranno aggiungere) vorrei specificare:

- chi le ha realizzate (con una indicazione di contatto, mail o altro).
- per quale release min/max sono 'certificate' funzionanti.
- ev. indicazioni a supporto, quali versioni di librerie usare, dove recuperarle, dove posizionarle
- ev. link al sito da cui fare il download dell'eseguibile prodotto usando quelle impostazioni

Se mi fornite il materiale COMPLETO per quelle che avete personalmente verificato, elimino definitivamente le altre (es. osx-ppc ????) ed aggiungo le nuove.

Fatto questo, rilascio la versione 1.8.4 (R2)

Con le tue ultime modifiche ha compilato, domani testo e vedo se funziona tutto. Aggiorno pure C-3PO e ri-testo l'upsampling su OSX. Risolte queste due cose ti mando una pull request con tutte le cose da modificare

[antonellocaroli]

se me le mandi (o mi dici dove andarle a prendere), le metto con le altre.

quella fatta in win 10 si trova qua https://www.nexthardware.com/forum/p...tml#post972501

[antonellocaroli]

Ps: per il discorso del download automatico del binario di sox tramite c-3po , non è propio automatico giusto? Nel senso chiederà qualche conferma all utente? O come la state pensando?


Inviato dal mio iPhone utilizzando Tapatalk

[SimoneFil]

Ancora sto errore:

output_alsa.c:423: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:423:17: note: each undeclared identifier is reported only once for each function it appears in
output_alsa.c:425: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:427:17: error: ‘SND_PCM_FORMAT_DSD_U32_BE’ undeclared (first use in this function)
   alsa.format = SND_PCM_FORMAT_DSD_U32_BE; break;
                 ^
Makefile:82: recipe for target 'output_alsa.o' failed
make: *** [output_alsa.o] Error 1

Credo che a sto punto non abbia molto senso tentare di aggirare l'errore ma dichiarare ste variabili; solo che non so di che tipo sono e quindi come mettere giù la dichiarazione; qualcuno può darmi una mano?

[marcoc1712]

Con le tue ultime modifiche ha compilato, domani testo e vedo se funziona tutto. Aggiorno pure C-3PO e ri-testo l'upsampling su OSX. Risolte queste due cose ti mando una pull request con tutte le cose da modificare

tancchiu

[UnixMan]

.stai sereno (come diceva uno che ha fatto una brutta fine e tenta di trasformarla in bell'inizio...)

a. 1_8_4 è un 'tappabuchi' per eventuali necessità di intervento su release, senza cambiar release. Non ha DSD.

Oh! Capisco.

...ma allora com'è che (dopo aver risolto il problema con il make) si è "bevuto" l'opzione "-D u32be" senza protestare?

BTW: ecco perché "mi sembrava" che suonasse peggio... stava andando in DoP o addirittura riconvertendo in PCM?

b. Makefile.gentoo è praticamente identico, come eseguibile prodotto, a Makefile.debian (Io l'ho sempre detto che si poteva prendere l'eseguibile di debian ed appoggiarlo in gentoo...)

la possibilità di usare un binario prodotto su una distribuzione per un'altra ha poco o nulla a che vedere con quello... il problema principale sono soprattutto le librerie, che possono essere diverse (ed incompatibili) da una distro all'altra.

Per quanto riguarda i Makefile, quello ".debian" (che si limita ad abilitare varie opzioni prima di includere quello principale) l'ho usato solo a suo tempo solo per i pacchetti .deb, per restare compatibile con (cioè, per offrire le stesse funzionalità di) quelli "ufficiali", che quel pacchetto andava a rimpiazzare.

Attualmente per R2 ho abbandonato i pacchetti... mi limito a produrre un binario minimale con le sole funzionalità che mi servono (-DALSA, -DDSD) ed a copiarlo a mano in /usr/local/bin.

tranne che imposta EXTRALIBS invece di LDFLAGS, perchè così vuole gentoo.

sì, ho visto.

Proprio questo intendevo: sono praticamente identici... per cui mi pare una duplicazione del tutto inutile: IMHO nulla vieta di "fonderlo" con quello principale, di modo che ce ne sia uno solo (compatibile sia con Gentoo che con l'uso "standard" su altre piattaforme). Dovrebbe essere sufficiente modificare quello per gentoo grosso modo così:

CFLAGS  ?= -Wall -fPIC -O2 
CFLAGS += $(OPTS) 
LDFLAGS ?= -lasound -lpthread -lm -lrt 
EXTRALIBS ?= $(LDFLAGS)
EXECUTABLE ?= squeezelite-R2
...

...e poi sostituirlo a quello principale (casomai Gentoo richieda la presenza di un Makefile.gentoo, a quel punto basta crearne uno "dummy" che si limita ad includere quello principale, così che non sia necessario mantenerne due versioni).

Non so da dove prendi quello che posti e che ha ancora i LDFLAGS.

da git (1_8_4_dev), dove altro? :wow

c. la versione DSD... non compila(va) con -DALSA, per un baco, adesso compila ma ci sono warnings che non mi piacciono, ci devo lavorare sopra.

OK. Poi riprovo e ti faccio sapere.

d. La versione 'buona' per compilare in win10 ed XP ce l'ha Filippo, io ho solo l'eseguibile di XP.

Ho aggiunto quello di Filippo e quelli di Simone per OSX e BSD:

AudioFaiDaTe: SoX including DSD support

Se quello di Filippo non funziona su XP, mandami anche il tuo che ci metto pure quello.

La versione DSD... adesso si compila senza errori o warnings, non so dirvi se suona però...
[...]
nel frattempo ho rilasciato anche una versione corretta di C-3PO, ma non sono riuscito a riprodurre l'errore segnalato da SimoneFil uscendo in wav, uscendo in dsf/dff si e l'ho corretto.

stasera provo entrambi e ti faccio sapere.

[marcoc1712]

Ps: per il discorso del download automatico del binario di sox tramite c-3po , non è propio automatico giusto? Nel senso chiederà qualche conferma all utente? O come la state pensando?


Inviato dal mio iPhone utilizzando Tapatalk

Ancora non lo so, in win potrei farlo automatico, ma in linux ed osx non c'è l'analoga funzionalità, dovrei realizzarla a nuovo e comunque temo il vortice dei casini installa/non installa/ riavvia/aspetta...

Oltre a questo, io non ho modo di differenziare win XP da Win7, 8 o 10 nelle architetture, quindi non potrei usare nemmeno l'attuale metodo standard, per non parlare dei diversi 'flavours' di linux, dovrei realizzare e mantenere repository diversi, lasciando all'utente il compito di selezionare quello giusto. Per la via, allora, meglio fargli selezionare solo il download di SOX e sostituirlo nell acartella di LMS, non nel plugin, così da renderlo permanente anche al cambio di release di C-3PO (altrimenti i binari andrebbero riscaricati ogni volta, dato che l'aggiornamento del plugin cancella la cartella radice e la sostituisce integralmente ogni volta).

Probabilmente almeno inizialmente sarà manuale, e metterò il link (già previsto ma da valorizzare) ad un sito esterno con i file da scaricare, magari completi di uno script di installazione o quant'altro, ma almeno con le istruzioni da seguire passo passo.

Per me questo ha anche il vantaggio che non mi devo preoccuapare della manutenzione di quella parte, che non è poco.

E' un aspetti di cui dobbiamo parlare.

Però oggi vacanza, è arrivata la nuova macchina, devo cominciare a muovere tutto...