DSD in LMS con SOX

[UnixMan]

[...] mi sembra più prioritario l'integrazione in c-3po per rendere il tutto effettivamente usabile (in modo comodo), per poi rifinire i particolari.

assolutamente.

@Marco, a proposito: sarebbe molto utile (e comodo) includere in C-3PO la possibilità di installare (sostituire) automaticamente la versione di SoX fornita da LMS con una "che fornisce lui". È possibile farlo?

Purtroppo conosco diversi possibili utenti che si troverebbero in difficoltà a farlo a mano, e rischierebbero pure di fare pasticci.

In realtà molti usano un raspberry come client, io incluso! Quindi prossimamente ci proverò

ottimo!

Per quanto riguarda squeezelite su FreeBSD, Si può fare? Sì. Ha effettivamente senso?

il senso è di quelli da tacere su Hydrogenaudio e affini...

Cioè: se (ammesso e non concesso che) diamo per assodato che software, driver ed OS diversi - e perfino versioni diverse degli stessi - "suonano" in modo differente tra loro, diventa molto interessante provare anche quello. In particolare proprio perché usa uno stack audio diverso dagli altri (oltre a tutte le altre differenze a livello di Kernel, ecc). Chissà mai che non si riveli una carta vincente...

1- OSS non ha un buon supporto per i DAC usb, alcuni vanno, altri no; nemmeno paragonabile al supporto che ha ALSA.

seccante.

Speriamo che funzioni con le Xmos che usiamo noi...

Probabilmente lo farò comunque pure per FreeBSD, ma direi che è completamente in fondo alla to-do list.

senza dubbio.

[marcoc1712]

assolutamente.

@Marco, a proposito: sarebbe molto utile (e comodo) includere in C-3PO la possibilità di installare (sostituire) automaticamente la versione di SoX fornita da LMS con una "che fornisce lui". È possibile farlo?

Purtroppo conosco diversi possibili utenti che si troverebbero in difficoltà a farlo a mano, e rischierebbero pure di fare pasticci.

Su sistemi Linux/osx potreste/dovreste gestire le varie modalità via pacchetti.

in alterativa, certo che si, verificando di poterlo fare come eseguibile (ma lms lo fa ed anche daphile, quindi...) esattamente allo stesso modogià utilizzato in windows per c3po, posizionandolo nella opportuna cartella come fa lms stesso ma in /Bin/arch.. ma in Plugin/C-3PO/Bin/arch..., il che significa che sarà utilizzabile SOLO da c-3PO, non universalmente.

Servirà comunque mantenere attivo un repo di distribuzione dei binari, che poi verranno riferiti dal pacchetto di distribuzione di c-3PO, o in alternativa ne terrò una copia 'statica' io che mi direte di sostituire alla bisogna inviandomo le versioni compilate per le diverse piattaforme.

Quando arriverò a pensarci vedremo come, ma nulla di che, solo briga in manutenzione (che non voglio certo sobbarcarmi per più del minimo indispensabile).

[UnixMan]

Su sistemi Linux/osx potreste/dovreste gestire le varie modalità via pacchetti.

in teoria hai ragione, ma... per sostituire un solo file bisognerebbe rifare (e mantenere) l'intero pacchetto di LMS, e per tutti i sistemi supportati! Una follia, non ci penso neanche!

Sebbene sia "poco ortodosso" è infinitamente più semplice fare solo un eseguibile statico di sox e sostituirlo a posteriori a quello installato da LMS nella sua dir.

in alterativa, certo che si, verificando di poterlo fare come eseguibile (ma lms lo fa ed anche daphile, quindi...) esattamente allo stesso modogià utilizzato in windows per c3po, posizionandolo nella opportuna cartella come fa lms stesso ma in /Bin/arch.. ma in Plugin/C-3PO/Bin/arch..., il che significa che sarà utilizzabile SOLO da c-3PO, non universalmente.

non potresti fargli rimpiazzare proprio quello installato da LMS, in /Bin/arch/...?

Sarebbe la cosa migliore. Comunque, se non fosse possibile, alla peggio va bene anche metterlo tra i binari specifici del plugin (tanto chi non è in grado / non ha voglia di sostituire un eseguibile non si prende certo la briga di modificare a mano convert.conf o altro...).

Servirà comunque mantenere attivo un repo di distribuzione dei binari, che poi verranno riferiti dal pacchetto di distribuzione di c-3PO, o in alternativa ne terrò una copia 'statica' io che mi direte di sostituire alla bisogna inviandomo le versioni compilate per le diverse piattaforme.

pensavo più alla seconda opzione (copia dei vari eseguibili "dedicati" di sox inclusi direttamente nell'archivio dei files di C-3PO), così si installa tutto in un colpo solo e riduciamo il numero di possibili "failure point". Ma non c'è problema, nel caso fosse necessario possiamo senz'altro fare anche un repository dedicato per i vari binari di "sox-dsd".

[bigtube]

Lo devo dire....il dsd non mi interessa....ma state facendo un lavoro davvero di gran valore...BRAVISSIMI

[DacPassion]

Lo devo dire....il dsd non mi interessa....ma state facendo un lavoro davvero di gran valore...BRAVISSIMI

Dai procurati un DACchetto dsd ...giusto per giocare

[bigtube]

Dai procurati un DACchetto dsd ...giusto per giocare

Vade retro....e poi devo giocare con altro ....per colpa vostra

[marcoc1712]

Vade retro....e poi devo giocare con altro ....per colpa vostra

E sì, una bella cenetta pagate ci starebbe, ma secondo me tra me e te non gli conviene...

[marcoc1712]

Lo devo dire....il dsd non mi interessa....ma state facendo un lavoro davvero di gran valore...BRAVISSIMI

pernsa che non interessa nemmeno a me... Quando si dice un contributo disinteressato...

[marcoc1712]

in teoria hai ragione, ma... per sostituire un solo file bisognerebbe rifare (e mantenere) l'intero pacchetto di LMS, e per tutti i sistemi supportati! Una follia, non ci penso neanche!

Sebbene sia "poco ortodosso" è infinitamente più semplice fare solo un eseguibile statico di sox e sostituirlo a posteriori a quello installato da LMS nella sua dir.

vedi che a mettere le mani in pasta si diventa meno pasdaran?

non potresti fargli rimpiazzare proprio quello installato da LMS, in /Bin/arch/...?

beh, no, quello saebbe terrorismo...metti che qualche plugin o latro ne abbia bisogno (è una versione 'speciale' per lms) e per farlo dovrei comunque manutenere una serie separata di pacchetti di lms...

[marcoc1712]

pensavo più alla seconda opzione (copia dei vari eseguibili "dedicati" di sox inclusi direttamente nell'archivio dei files di C-3PO), così si installa tutto in un colpo solo e riduciamo il numero di possibili "failure point". Ma non c'è problema, nel caso fosse necessario possiamo senz'altro fare anche un repository dedicato per i vari binari di "sox-dsd".

Salvo verificare sia possibile ed ASSOLUTAMENTE in linea con le varie licenze, va bene, a condizione che NON ci siano modiifche rispetto a quanto manutenuto da Mansur (in nessuna componente, compresi i makefile o altro), così da potervi far riferimento per il codice sorgente, in caso di modifiche anche minime, bisogna renderle disponibili a richiesta ed io non mi ci metto a gestirlo. Se qualcuno lo vuole fare, basta creare un repo - es. in github - e compilare a partire da quello, come ho fatto io con squeezelite a suo tempo.

Tecnicamente, gli eseguibili NON saranno nel pacchetto del plugin (altrimenti si creano i noti problemi) ma scaricati in fase successiva, come avviene in windows per l'eseguibile di C-3PO, quindi in realtà nei pacchetti c'è solo il link ( e l'MD5), l'eseguibile in se può stare in qualsiasi sito raggiungibile.

Intanto concrentratevi nel produrre e testare i diversi eseguibili che vogliamo distribuire (ricordando che il discriminante, al massimo, è OS + arch,v. cartella bin del server), facendo molt attenzione ed annotandosi la seppur minima modifica di impostazione rispetto ai files distribuiti da mansr, poi decidiamo il metodo migliore.