DSD in LMS con SOX

[UnixMan]

rispondo a un po' di cose che erano restate indietro...

b. abbiamo (sembra) svelato l'arcano del DSD nativo, poi qualcuno mi spiega cosa sono quei formati... ma dsd non è bitstream? Ed in pa?
[...]
NOTA BENE: BIG ENDIAN???

Se davvero l'uscita verso USB deve essere in formato big endian, significa che squeezelite si deve passare byte per byte ed invertire l'ordine dei bit... assolutamente inefficiente, che non valgala pena inviare big endian già da sox.

non ne ho idea ma, "a naso", non credo che SL faccia nulla del genere. Il problema è che, a differenza del DoP, per il DSD "nativo" non esiste alcuno standard "ufficiale": è una cosa che è stata aggiunta in modo indipendente da vari produttori di interfacce USB, ed ognuno ha fatto a modo suo. Posso sbagliarmi, ma presumo che in realtà si tratti semplicemente di una sorta di "flag" che indica ad ALSA il modo in cui deve gestire la comunicazione con i diversi hardware. Immagino che dando una occhiata ai sorgenti di SL non dovrebbe essere difficile capire come stanno le cose...

c. riscarica e ricompila, ho applicato le ulteriori patch, vediamo se risolvono il problema di allineamento.
[...]
Hai ricompilato squeezelite o sei sempre alla versione precedente? solo per sapere se le altre patch sono necessarie o solo eventualmente utili.

Ancora alla precedente. Stasera provo quella nuova. Cosa fanno di bello queste nuove patch?

Bel risultato.

yes!

Per finire, ti chiedo di provare squeezelite ultima versione (che forse toglie anche il click)

sarebbe fantastico!!

...anche se temo che possa essere un problema legato al DAC: IIRC lo fa anche con HQPlayer. In quel caso non tra una traccia e l'altra, ma quando passi da stop a play o cambi da PCM a DSD o viceversa sì. Se anche solo si riuscisse ad arrivare alla medesima situazione (evitando almeno il click quando passa da una traccia all'altra) sarebbe già una gran cosa.

e di provare anche anche che funzioni ancora correttamente con DOP e PCM (questo lo faccio anch'io).

in PCM (con la vers. precedente) già fatto, no problem. Stasera provo in DoP con questa, poi passo a quella nuova e provo tutti e tre i casi.

[marcoc1712]

rispondo a un po' di cose che erano restate indietro...


non ne ho idea ma, "a naso", non credo che SL faccia nulla del genere. Il problema è che, a differenza del DoP, per il DSD "nativo" non esiste alcuno standard "ufficiale": è una cosa che è stata aggiunta in modo indipendente da vari produttori di interfacce USB, ed ognuno ha fatto a modo suo. Posso sbagliarmi, ma presumo che in realtà si tratti semplicemente di una sorta di "flag" che indica ad ALSA il modo in cui deve gestire la comunicazione con i diversi hardware. Immagino che dando una occhiata ai sorgenti di SL non dovrebbe essere difficile capire come stanno le cose...


Ancora alla precedente. Stasera provo quella nuova. Cosa fanno di bello queste nuove patch?


yes!


sarebbe fantastico!!

...anche se temo che possa essere un problema legato al DAC: IIRC lo fa anche con HQPlayer. In quel caso non tra una traccia e l'altra, ma quando passi da stop a play o cambi da PCM a DSD o viceversa sì. Se anche solo si riuscisse ad arrivare alla medesima situazione (evitando almeno il click quando passa da una traccia all'altra) sarebbe già una gran cosa.


in PCM (con la vers. precedente) già fatto, no problem. Stasera provo in DoP con questa, poi passo a quella nuova e provo tutti e tre i casi.

SE riceve n LE ed esce in BE... lo deve fare per forza, il codice c'è proprio nella patch aggiunta, capire cosa fanno quelle operazioni con valori binari... per me non è immediato.

Se poi è solo un nome usato impropriamente ed in realtà non inverte l'ordine dei bit, allora ovvio non lo fa, ma mi sembrerebbe una scelta bizzarra usare un nome preciso con significato diverso.

Le altre patch, sempre senza aver verificato nel dettaglio:

1. 'lima' lo stream per evitare chunk incompleti alla fine (possibile causa dei click)
2. fissa a 24bit il dop
3. evita che parta il resampling wav in caso di dop.

[antonellocaroli]

Allora Fedeliallalinea ha aggiornato la ebuild con la versione sul git di Marco...stasera Provo anche io la conversione da lms se va...

[UnixMan]

SE riceve n LE ed esce in BE... lo deve fare per forza, il codice c'è proprio nella patch aggiunta,

visto. Sì, ci sono proprio dei "bit-shift" che fanno quello. Ovviamente, per essere manipolati e trasferiti in modo efficiente, i singoli bit del DSD devono necessariamente essere "impacchettati" in qualche modo all'interno di parole di n bytes (né più né meno che quanto avviene per il DoP, salvo che non c'è l'inutile overhead dei finti header PCM). Fin qui nulla di strano. Ma perché mai poi usino rappresentazioni con "endianess" diverse (che obbligano ad effettuare operazioni inutili per riallineare i bit) non ne ho proprio idea...

[marcoc1712]

visto. Sì, ci sono proprio dei "bit-shift" che fanno quello. Ovviamente, per essere manipolati e trasferiti in modo efficiente, i singoli bit del DSD devono necessariamente essere "impacchettati" in qualche modo all'interno di parole di n bytes (né più né meno che quanto avviene per il DoP, salvo che non c'è l'inutile overhead dei finti header PCM). Fin qui nulla di strano. Ma perché mai poi usino rappresentazioni con "endianess" diverse (che obbligano ad effettuare operazioni inutili per riallineare i bit) non ne ho proprio idea...

Così l'audiofilo compra computer potenti...

Comunque, se con pcm c'è realmente poco che il player possa fare nel ciclo di lettura e scrittura verso il DAC, qui le cose cambiano, le cose da fare e fatte sono tante, seppure alla fine il risultato sarà (sostanzialmente) identico in termini di bit (ma non esattamente), il 'modo' con cui viene fatto qui o in altri player può essere sostanzialmente diverso. Non ho verificato il carico, ma secondo me andiamo ben aldilà della conversione flac/pcm. Magari però il gioco vale la candela, questo lo potete dire soltanto voi.

p.s.

Perchè i diversi formati ci sono solo in Linux/alsa e non in Win o osX?

[UnixMan]

Non ho verificato il carico, ma secondo me andiamo ben aldilà della conversione flac/pcm.

no, perché mai? Sono solo un paio di bit-shift. Ciascuno dei quali si traduce direttamente in una singola istruzione assembler (che lavora direttamente sui registri della CPU, senza accessi alla memoria) che a sua volta si traduce 1:1 in codice macchina. Insomma è una operazione semplicissima, leggerissima e velocissima. Che a dir tanto aggiunge un paio di cicli di clock per ogni "word" (cioè con una frequenza pari a DSDrate/32, pari a quella del PCM a 88.2K nel caso di DSD64, a 176.4K per il 128, ecc). Per quanto semplice, la decodifica flac è enormemente più complessa!

Perchè i diversi formati ci sono solo in Linux/alsa e non in Win o osX?

ah... boh, non ci ho fatto caso. La domanda sorge spontanea: su quei sistemi SL supporta il DSD nativo?

Posto che la risposta sia affermativa, è possibile che la cosa sia gestita diversamente (demandata ad altri sottosistemi). Ad es. su win il DSD non è supportato, se non attraverso ASIO (SL supporta ASIO?). È un mondo che conosco poco per non dire per niente, ma forse è possibile che sia proprio ASIO a definire una sorta di standard per il DSD e quindi che dal punto di vista di SL il formato di uscita sia unico. Dopo di che sarebbero i driver ASIO delle varie interfacce a gestire la cosa per lo specifico hardware che supportano.

[antonellocaroli]

Marco ma la compilazione di sox sul tuo github non va a buon fine

Makefile:2530: set di istruzioni per l'obiettivo "libsox_la-dsf.lo" non riuscito
make[1]: *** [libsox_la-dsf.lo] Errore 1
Makefile:656: set di istruzioni per l'obiettivo "all-recursive" non riuscito
make: *** [all-recursive] Errore 1

[UnixMan]

Marco ma la compilazione di sox sul tuo github non va a buon fine

che comandi hai dato per compilare?

Prima di usare la ebuild prova a mano, come avevo indicato in un post precedente.


BTW: compilata la nuova versione di squeezelite-R2 con le patch. Sta suonando.

Confermo che sembra funzionare tutto (DoP, DSD nativo e PCM).