DSD in LMS con SOX

[DacPassion]

@Marco secondo te la Alix con voyage e il tuo nuovo squeezelite può reggere anche il dsd?

Ps molto interessante la tua idea di rendere R2 minimalissimo!!!

[marcoc1712]

Da qualcosa letto in Giro in win é meglio SSE2 in caso di 32 bit e AVX in caso di 64 bit...ma magari erano puttanate

Ma parli di win64 come architettura, sistema operativo ospite o processore?

Ma il repo di Ralphy dov é?

https://github.com/ralph-irving/squeezelite

[marcoc1712]

@Marco secondo te la Alix con voyage e il tuo nuovo squeezelite può reggere anche il dsd?

Ps molto interessante la tua idea di rendere R2 minimalissimo!!!

Già convertito in arrivo da LMS, non vedo perchè no, specie se non deve fare nemmeno nessuna 'inversione' di endianess.

[UnixMan]

Però... di quale squeezelite-R2 stiamo parlando, quella nel mio repo o una qualche versione con altre patch applicate? Paolo?

come sai sto provando con alcune patch in più, ma per quanto mi riguarda va benissimo anche as-is (così come arriva dal tuo git).

Sarebbe da capire meglio cosa fanno le innumerevoli patch relative alla gestione di ALSA (in particolare mixer/volume/ecc, incluse quelle che sulla tua versione non vanno), e quindi se vale o meno la pena includerle per farle auspicabilmente entrare a far parte del codice "upstream".

A proposito: ho appoggiato i binari delle diverse versioni prodotte su AFDT e chiedevo ad altri di provarli - in particolare gli ultimi due e volendo quello precedente (il primo direi si possa anche ignorare tranquillamente) - perché mi è parso di sentire qualcosa, ma non ne sono sicuro... per cui mi piacerebbe avere una smentita (o una conferma) indipendente.

R2 non è mai stata prodotta per ARM (o almeno no da me), i makefile per compilarla sono nel progetto di Ralphy, se si ottiene un risultato testato e replicabile li posso integrare.

sarebbe una cosa simpatica.

R2, nelle mie intenzioni, rimane una versione minimalista e lo diventerò probabilmente ancora di più, credo eliminerò il supporto a TUTTI i codec diversi da pcm e dsf (o dff), non farà più in alcum modo conversioni di suo o upsampling, richiedendo vengano fatte sul server (sparirà anche la conversione dsd2pcm), essendoci la versione 'standard' per tutti gli altri usi,

ti riferisci ai binari (opzioni di compilazione) o a modifiche al codice?

mentre di certo lavorerò sull'uscita su stdout, così da poterla mettere efficacemente in pipe con altri strumenti.
[...]
così da rendere ancora più facile uscire verso 'media' diversi e (dividendo a da b) ammettere input diversi da LMS, come - per esempio - direttamente da file (v. versione di VTF),

buona idea.

No, non ne sa nulla e parlare in quel contesto di DSD o altre 'audiofilate' è come andarsi a cercare insulti...

in questo caso non si tratta necessariamente di una "pippa da audiofili", ma di supportare (meglio) un formato diverso... quindi è una questione prettamente "tecnica".

Piuttosto, mettendola giù come esigenza tecnica, il forum deli sviluppatori o anche Hydrogenaudio potrebbe essere il luogo giusto, senza mai farsi scappare che il motivo è la sound quality, mi raccomando, altrimenti inniziano subito con i blind test, ABX,...

La priorità adesso è adeguare C-3PO, così da chiudere il cerchio, però nel frattempo si può invertigare se qualcosa è già stato fatto con PA e ASIO in merito al DSD e magari recuperare l'esempio.

come dicevo, direi che convenga chiedere lumi a loro. Se vuoi lo faccio io (e ti metto in CC; se gli scrivi tu p.f. fai altrettanto).

[marcoc1712]

come dicevo, direi che convenga chiedere lumi a loro. Se vuoi lo faccio io (e ti metto in CC; se gli scrivi tu p.f. fai altrettanto).

Vai pure!

[marcoc1712]

come sai sto provando con alcune patch in più, ma per quanto mi riguarda va benissimo anche as-is (così come arriva dal tuo git).

Ok, ho segnalato a Kimmo e Ralphy le patch che ho incluso, la versione 1.8.5 uscirà (non appena avrò anche C-3PO) così com'è nel mio github adesso, eventuali ulteriori modifiche origineranno una versione diversa.

[SimoneFil]

di essenziale direi nulla.

A Squeezelite manca ancora il supporto DSD non-DoP su win ed eventualmente OS/X. Ma (posto che sia possibile farlo) IMHO si può fare anche in un secondo momento. Nel frattempo c'è comunque DoP, nonché la possibilità di sistemi "misti" (LMS su win o Mac, SL su Linux).

N.B.: sox-dsd su win va testato. Io non ho macchine win per farlo. Ho solo fatto un paio di velocissimi test con wine/win64 (con sox da solo).

Sono della tua opinione rispetto al farlo in un secondo momento, mi sembra più prioritario l'integrazione in c-3po per rendere il tutto effettivamente usabile (in modo comodo), per poi rifinire i particolari.

al momento non credo lo usi nessuno ma, se hai l'hardware e ti va di provare... why not? :-)

Altra cosa che potrebbe essere interessante provare sarebbe Squeezelite su FreeBSD!

Si può fare? Cosa usa per l'audio, OSS?

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

Per quanto riguarda squeezelite su FreeBSD, Si può fare? Sì. Ha effettivamente senso? No IMHO
Per due motivi:
1- OSS non ha un buon supporto per i DAC usb, alcuni vanno, altri no; nemmeno paragonabile al supporto che ha ALSA.
2- Ipotizzando l'utilizzo ideale e più sensato del lavoro che stiamo facendo, cioè pc potente come server + pc a basso consumo e meno potente come client (anche perchè per tenere un all-in-one c'è Daphile che ti dà già la pappa pronta), FreeBSD è molto più usato su un ipotetico computer server più che sul client; a partire da coloro che usano FreeNAS come o.s. per il NAS casalingo (o ad esempio io lo utilizzo sul mio server remoto su cui ho installato anche LMS).
Probabilmente lo farò comunque pure per FreeBSD, ma direi che è completamente in fondo alla to-do list. Ovviamente IMHO

[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".