DSD in LMS con SOX

[SimoneFil]

Ritornando al discorso DSD "nativo" ... come faccio a capire cosa mettere dopo l'opzione -D in squeezelite per avere un'uscita non in DoP ma in "nativo" ? E soprattutto quale sono tutte le opzioni disponibili?

[antonellocaroli]

Ritornando al discorso DSD "nativo" ... come faccio a capire cosa mettere dopo l'opzione

le opzioni dovrebbero essere queste:

[/if (!strcmp(fstr, "dop")) dsd_outfmt = DOP; 
if (!strcmp(fstr, "u8")) dsd_outfmt = DSD_U8; 
if (!strcmp(fstr, "u16le")) dsd_outfmt = DSD_U16_LE; 
if (!strcmp(fstr, "u32le")) dsd_outfmt = DSD_U32_LE; 
if (!strcmp(fstr, "u16be")) dsd_outfmt = DSD_U16_BE; 
if (!strcmp(fstr, "u32be")) dsd_outfmt = DSD_U32_BE;
if (!strcmp(fstr, "dop24")) dsd_outfmt = DOP_S24_LE;
if (!strcmp(fstr, "dop24_3")) dsd_outfmt = DOP_S24_3LE;

Tipo -D:u32le o -D:u32be ecc

per capire quella giusta a quanto pare bisogna provare

[marcoc1712]

le opzioni dovrebbero essere queste:

[/if (!strcmp(fstr, "dop")) dsd_outfmt = DOP; 
if (!strcmp(fstr, "u8")) dsd_outfmt = DSD_U8; 
if (!strcmp(fstr, "u16le")) dsd_outfmt = DSD_U16_LE; 
if (!strcmp(fstr, "u32le")) dsd_outfmt = DSD_U32_LE; 
if (!strcmp(fstr, "u16be")) dsd_outfmt = DSD_U16_BE; 
if (!strcmp(fstr, "u32be")) dsd_outfmt = DSD_U32_BE;
if (!strcmp(fstr, "dop24")) dsd_outfmt = DOP_S24_LE;
if (!strcmp(fstr, "dop24_3")) dsd_outfmt = DOP_S24_3LE;

Tipo -D:u32le o -D:u32be ecc

per capire quella giusta a quanto pare bisogna provare

Dipende (dal driver della / dalla) tua scheda audio, normalmente DSD_U32_BE o DSD_U32_LE, non ricordo quale per xmos o amanero, se guardi nel log di squeezelite come la apre con pcm, hai una prima indicazione.

[SimoneFil]

Evidentemente con Linux il mio Teac UD-501 non ne vuole sapere. Con tutte quante le opzioni mi dà sempre:

unable to open audio device requested format: DSD_******

[UnixMan]

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

non ricordo... forse mi riferivo al lato server (sox), per il quale non ci sono problemi. Oppure semplicemente non avevo considerato il problema ed ho detto una stupidaggine.

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.

ne dubito. Sono due cose diverse: aggiornare la parte "user-space" di ALSA (librerie, ecc) è sufficiente per compilare R2 senza errori, ma poi perché possa funzionare (in DSD nativo) serve anche un kernel che includa una versione di ALSA che supporti quella modalità. È anche possibile aggiornare i moduli del kernel di ALSA (i "driver") senza necessariamente aggiornare il kernel (build "off-tree" dei moduli e loro sostituzione), ma alla fine è molto più semplice installare un kernel aggiornato.

Considera che, per paradossale che possa sembrare, tra le possibili "alterazioni" che si possono apportare ad una distribuzione, l'aggiornamento del kernel è tutto sommato una delle meno "invasive".

Specie dal ns. punto di vista. Infatti (salvo casi particolari) un binario prodotto in un sistema dove c'è un kernel diverso da quello "ufficiale" non ha nulla di diverso da uno prodotto su un sistema "standard". Al contrario, sostituire (aggiornare) una qualsiasi libreria (anche la più "marginale") con una versione diversa da quella inclusa nella distribuzione porta pressoché automaticamente ad incompatibilità dei binari prodotti con la "distribuzione madre" originale.

Comunque sia, il punto è che se sostituisci una qualsiasi parte del sistema (ad es. aggiorni le lib di ALSA) introducendo un elemento "alieno" (cioè utilizzando fonti diverse dai repositories ufficiali di quella distribuzione), hai ipso facto creato un sistema diverso, "custom", che non è più quello di partenza.

Se per riuscire a compilare R2 devi fare una cosa del genere (ivi incluso l'utilizzo di una copia locale degli headers di una o più librerie) non stai più supportando la distribuzione 'X', ma piuttosto (solo) un tuo sistema custom (ed al più altri che siano stati modificati allo stesso modo).

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

banalmente:

Jessie è supportata esclusivamente lato server (LMS+C-3PO+sox-dsd).

Per quanto riguarda il lato "player", le nuove versioni di R2 dipendono da ALSA >= 1.0.29. Pertanto le (principali) distro "papabili" sono:

*) Debian: >= 9.0 ("Stretch" o successive)

*) Ubuntu: >= 16.04

*) Mint: >= 18

*) Fedora: >= 22

*) RHEL e derivate (CentOS, Scientific Linux): >= 6.x

*) openSUSE: >= 42.1

*) Slackware: >= 14.2

*) Arch: current

*) Gentoo: current

Debian "Jessie" (8.x) e Ubuntu 14.04 LTS (e loro derivate) non sono supportate. Chi lo desideri (se è in grado di cavarsela da solo) può utilizzarle previo upgrade di kernel e librerie ALSA, compilando in proprio dai sorgenti.

Ubuntu per Raspberry Pi 2 : compilato tutto

ottimo!

Per quanto riguarda Raspbian [...] ne vale la pena?

probabilmente no. Tra Ubuntu server e Debian cambia ben poco.

Non ho trovato delle immagini stretch per Raspbian ma solo repo.

dato che è ancora in testing, è possibile che non siano state prodotte immagini pronte. Volendo puoi facilmente aggiornare a Stretch da Jessie. È sufficiente sostituire la versione (stable||jessie -> stretch) in /etc/apt/source.list* e poi dare "apt-get update" && "apt-get dist-upgrade".

Vale però quanto appena detto... non serve sbattersi più di tanto, e per giunta il binario prodotto per Ubuntu 16.04 dovrebbe girare senza problemi anche su Stretch.

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/

esatto.

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

Il fatto che qualcosa sia basato su Debian non implica necessariamente che sia basato sulla attuale "stable", né che sia necessariamente identica a questa. Molte derivate ne sostituiscono varie parti o si basano direttamente su "testing" o "unstable".

Ciò premesso, “Volumio” non va bene. La vers. attuale ha alsa-lib=2.0.28, la stessa di Jessie: https://distrowatch.com/table.php?distribution=volumio

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

PERCHÈ?!?!?!? Non deve esserci alcun bisogno di fare una cosa simile!!!

Hai installato i pacchetti delle dipendenze, inclusi i relativi headers? (pacchetti -dev, in particolare "libasound2-dev")

Se lo hai fatto, tutti gli header di cui hai bisogno ci devono essere già!

[SimoneFil]

PERCHÈ?!?!?!? Non deve esserci alcun bisogno di fare una cosa simile!!!

Hai installato i pacchetti delle dipendenze, inclusi i relativi headers? (pacchetti -dev, in particolare "libasound2-dev")

Se lo hai fatto, tutti gli header di cui hai bisogno ci devono essere già!

Allora, escluso windows, si possono abolire in generale le cartelle include?

[marcoc1712]

Allora, escluso windows, si possono abolire in generale le cartelle include?

Per osx servono, per RPI... dimmi tu, con quel makefile serve, l'hai puntata.

[UnixMan]

Evidentemente con Linux il mio Teac UD-501 non ne vuole sapere. Con tutte quante le opzioni mi dà sempre:

unable to open audio device requested format: DSD_******

È supportato? Altrimenti è ovvio che non funziona.

BTW, potrebbe anche non essere il DAC che non ne vuole sapere... ma una conseguenza dei tuoi tentativi di "imbrogliare". Solo che un computer non lo puoi imbrogliare...

Potresti avere un kernel privo del supporto DSD, oppure hai compilato R2 usando degli headers "alieni" che non sono compatibili con la versione di ALSA che c'è sul sistema e/o le librerie di ALSA che sono sul sistema non hanno il supporto DSD (se è Ubuntu 16.04 dovrebbero).

[UnixMan]

Per osx servono,

anche lì, in realtà non dovrebbero servire affatto. Servono solo perché chi ha compilato la versione OSX non ha installato sul suo sistema qualche libreria (con i relativi headers... proprio quelli aggiunti lì dentro).

[UnixMan]

È supportato? Altrimenti è ovvio che non funziona.

mi rispondo da solo: https://duckduckgo.com/?q=Teac+UD-50...+%2Bdsd+native

«
[16-May-16]
[...]
Moved TEAC-501 patch to archive. Patch was close but not sufficient.
Investigation not complete due to lack of (access to) a TEAC-501.
»

https://github.com/lintweaker/xmos-native-dsd

No, il tuo Teac non è supportato. C'è stato un tentativo, ma non funzionava ed è stato rimosso. Lo sviluppatore non dispone di documentazione sufficiente né di un esemplare per testare il codice.