DSD in LMS con SOX

[marcoc1712]

In Windows e Linux si! mac non saprei....

Sei sicuro?

Dal sito Signaliyst:
Native/direct playback of DSF/DSDIFF files (ASIO DSD, DoP v1.1 with both 0x05/0xFA and 0x06/0xF9 markers).

Comunque lo chiariremo nell'altro THD con Bibo e Jussy.

[UnixMan]

[06:29:02.541] process_aude:395 enable spdif: 1 dac: 1

mmh, questo non è che può creare problemi? IIRC s/pdif oltre 192k non va...

[06:29:19.452] _output_frames:146 track start sample rate: 44100 replay_gain: 0

da dove esce 44.1K?!

Content-Type: audio/dsf

[06:29:23.346] sendRESP:202 RESP
[06:29:23.462] _read_header:191 id: DSD  len: 28 consume: 28
[06:29:23.462] _read_header:158 DSF version: 1 format: 0
[06:29:23.463] _read_header:168 channels: 2
[06:29:23.463] _read_header:169 sample rate: 5644800
[06:29:23.464] _read_header:170 lsb first: 1
[06:29:23.465] _read_header:171 sample bytes: 2305843009213693951
[06:29:23.465] _read_header:172 block size: 4096
[06:29:23.466] _read_header:191 id: fmt  len: 52 consume: 52
[06:29:23.466] _read_header:178 found dsd len: 12
[06:29:23.467] dsd_decode:765 setting track_start
[06:29:23.468] dsd_decode:818 DSD128 stream, format: DOP, rate: 352800Hz

qui mi pare tutto giusto...

presumo che vada in dop...

sicuramente, così dice. D'altro canto, "-D" senza ulteriori parametri quello gli dice di fare.

comunque stamattina appena acceso é andato sia con dsd 64 che 128 poi non piú, sempre suono distorto...buh

Controlla il mixer di wondows! Se vai in DOP, stai "nascondendo" il DSD all'interno di un "finto" stream PCM. Per quanto riguarda il sistema (windows, i suoi driver, ecc), ciò che gli arriva è PCM. E viene trattato come tale.

Perciò, se lo stream viene manipolato in qualsiasi modo, ad es. da un controllo di volume (il sistema non è "bit-perfect"), lo stream DSD risulta corrotto e viene fuori un gran pasticcio.

stessa cosa con versione ufficiale di squeezelite-R2 con file dsf scaricato da oppodigital

certamente, stessa cosa.

cosa che mi succedeva anche prima con c-3po (file upsamplati) ma riavviando la traccia poi andava....

Uh? cioè avevi problemi simili anche in PCM?

[OT]

Avevo sentito che registrasse la Key nella eprom della mb, insieme al BIOS, per intenderci.

a meno che nell'hardware (e nel firmware) non sia appositamente previsto uno "spazio" dedicato a tal fine, sarebbe impossibile. Più probabile è che il BIOS "pubblichi" un ID unico, una sorta di numero di serie della MB, e che windows sfrutti quello per accorgersi se lo stai facendo girare su un hardware diverso.

In ogni caso, in una VM anche la MB ed il BIOS non hanno nulla a che fare con quelli del sistema "host": sono emulati, "virtuali" pure loro, parte integrante della VM stessa... per cui insieme alla VM ti porti dietro anche quelli.
[/OT]

Continua a vedere la tua scheda audio come max 384KHz e tu gli invii 5644800, ma esce in DSD128 (stream, format: DOP, rate: 352800Hz) non vorrei ofsse quello.

AFAIK la nuova DIYINHK che ho io è l'unica che arriva fino a 768K. La scheda di Filippo non supporta più di 384K.

Quindi - in modalità nativa - la sua scheda può arrivare fino a 32*384K=12.288K, cioè DSD256 (un po' di più: fino a 4x su base 48K) e non oltre. Ma in modalità DoP c'è un enorme overhead dovuto agli header PCM fittizi per cui, a parità di s/r effettivo del DSD, è necessario un s/r PCM (DoP) maggiore (doppio!).

Come ho mostrato in un post precedente, come data rate il DSD128 "equivale" a PCM 176.4k in modalità nativa ed a 352.8k in DoP.

Ergo in DoP l'interfaccia di Filippo oltre DSD128 non può andare.

Temo che al di fuori di ALSA, non ci sia possibilità per DSD nativo (...qualsiasi cosa voglia dire, dato che non vedo una grossa differenza tra DOP ed uno qualsiasi dei formati utilizzati con ALSA, da quello che ho capito DOP è solo un formato 'predefinito', sempre di incapsulare un bitstream in un formato multibit si tratta, ma forse non ho capito un acca).

vedi sopra: c'è un abisso!

Il DSD "nativo" non "incapsula" niente: si limita ad "impacchettare" i dati, cioè a suddividere lo stream in blocchi di 32bit (o di 16, o di 8 negli altri casi).

Al contrario nel caso del DoP i dati DSD vengono effettivamente incapsulati in (finti) frame PCM, con tutto l'overhead che ne consegue.

BTW, ripropongo la domanda fatta in un post precedente: SL è in grado di andare in modalità nativa su windows? SL (cioè, PortAudio) supporta ASIO? In caso contrario la risposta è certamente negativa.

Sei sicuro che non ne prenda il controllo un programma diverso (o il mixer) a seguito del rilascio da parte di squeezete (-C)? Avviene sempre dopo una pausa o anche all'interno della stessa playlist?

come dicevo sopra, il DoP è maledettamente "rischioso"... perché tutti i sottositemi che ci hanno a che fare, se non sono progettati per riconoscerlo come tale e regolarsi di conseguenza, "credono" si tratti di normale PCM e come tale lo trattano. Per cui, se non viene garantito un trattamento assolutamente "bit-perfect", il risultato è che i dati DSD vengono irrimediabilmente corrotti.

[antonellocaroli]

[QUOTE=UnixMan;971895]Ergo in DoP l'interfaccia di Filippo oltre DSD128 non può andare.[/CODE]

esatto!!! solo in native va con DSD256 con hqplayer....ma se non ricordo male solo con alcuni Driver, , con quelli jlsound mi sembra che non riuscivo....

é da un po che non uso widows (non mi é mancato per niente!!!!)

devo un po ricontrallora con HqPlayer...

[UnixMan]

devo prima capire se e quali sono i vantaggi del dsd 'nativo' rispetto al DOP.

enormi... si dimezza il data-rate sul bus USB!

*) a parità di max s/r supportato dall'hardware, raddoppia il max s/r DSD supportato;

*) a parità di s/r DSD si dimezza il data rate, con indubbi benefici in termine di "rumore" (interferenze) prodotte, ecc.

Ma HQPlayer oltre che in windows con ASIO DSD esce 'nativo' anche su mac (ammesso si possa) e linux?

su Mac non ne ho idea... su Linux sì, sicuramente.

Io non riesco proprio ad ottenere una versione di SOX modificata per Windows. Non si compila nemmeno con Visusal studio 2015.

da capire qual è il problema... dubito possa dipendere dal semplice codice aggiunto per il DSD.

Probabilmente sarà stato chiaro a tutti tranne che a me, ma QUALSIASI metodo di trasferimento di un bit stream via USB passa NECESSARIAMENTE tramite il suo "impacchettamento' in un formato pcm, anche con asio. (v. http://read.pudn.com/downloads119/so...0SDK%202.2.pdf).

Che a livello di comunicazione "interna" al PC, tra software e driver ASIO, la comunicazione avvenga comunque con una sorta di DoP cambia poco.

Ciò che conta è quel che accade in uscita, sul bus USB.

È lì che la differenza è enorme: tra "impacchettare" (cioè banalmente raggruppare e suddividere in blocchi) i dati DSD (come avviene in modalità "nativa") ed "incapsularli" all'interno di vere e proprie frame PCM fittizie (come accade nel DoP) c'è un abisso!

Non fosse altro perché l'overhead introdotto dal DoP obbliga ad utilizzare un data-rate doppio rispetto a quello necessario in modalità nativa.

N.B.: AFAIK allo stato attuale i formati "nativi" sono estensioni proprietarie, non sono previsti dagli standard USB.

Porta differenze all'ascolto?

chi ha provato sostiene di sì... e, d'altro canto (visto il raddoppio del data-rate), è a dir poco probabile.

Portaudio Windows ASIO with MSVC: PortAudio: Building Portaudio for Windows with ASIO support using MSVC

Quindi non basta avere il driver ASIO dsd compatibile, bisogna avere anche portaudio compilato per Asio

bingo.

In windows utilizzare ASIO è a dir poco... fondamentale! Non solo per il DSD (nativo o meno che sia), ma anche per il PCM.

È l'unico modo in cui puoi "by-passare" tutti i sottosistemi audio di windows, evitando che questi "pasticcino" con il tuo stream.

Non per caso su windows qualsiasi applicazione audio "seria" (tanto in campo "audiophile" quanto in campo "pro") usa esclusivamente ASIO... e non potrebbe essere altrimenti.

[marcoc1712]

in modalità nativa[/B] - la sua scheda può arrivare fino a 32*384K=12.288K, cioè DSD256 (un po' di più: fino a 4x su base 48K) e non oltre. Ma in modalità DoP c'è un enorme overhead dovuto agli header PCM fittizi per cui, a parità di s/r effettivo del DSD, è necessario un s/r PCM (DoP) maggiore (doppio!).

Come ho mostrato in un post precedente, come data rate il DSD128 "equivale" a PCM 176.4k in modalità nativa ed a 352.8k in DoP.

Ergo in DoP l'interfaccia di Filippo oltre DSD128 non può andare.


vedi sopra: c'è un abisso!

Il DSD "nativo" non "incapsula" niente: si limita ad "impacchettare" i dati, cioè a suddividere lo stream in blocchi di 32bit (o di 16, o di 8 negli altri casi).

Al contrario nel caso del DoP i dati DSD vengono effettivamente incapsulati in (finti) frame PCM, con tutto l'overhead che ne consegue.

BTW, ripropongo la domanda fatta in un post precedente: SL è in grado di andare in modalità nativa su windows? SL (cioè, PortAudio) supporta ASIO? In caso contrario la risposta è certamente negativa.


come dicevo sopra, il DoP è maledettamente "rischioso"... perché tutti i sottositemi che ci hanno a che fare, se non sono progettati per riconoscerlo come tale e regolarsi di conseguenza, "credono" si tratti di normale PCM e come tale lo trattano. Per cui, se non viene garantito un trattamento assolutamente "bit-perfect", il risultato è che i dati DSD vengono irrimediabilmente corrotti.

Mah, è probabile che sbagli io, ma a me risulta che:

a. l'header PCM sia solo a inizio stream, non ad ogni word.
b. in DOP il 'marker' sia di 8 bit, su un totale STANDARD di 24, quindi l'overhead è del 33%. (DoP open Standard | DSD-Guide.com).
c. nei formati 'alsa' il marker è sempre di 8 bit, ma il world lenght può arrivare a 32 bit, quindi l'overhead scende al 25%.
d. Solo ASIO 'impacchetta' il DSD raw senza marker, a inserisce una header ed una footer allo stream.

Comunquesi, in DOP per DSD128 servono almeno 352.8 proprio per problemi di bitrate, al di la del fatto che l'overhad sia il 50% o il 33%.

Il punto è che non esiste un metodo 'nativo' 'bit stream', si tratta sempre di dati 'impachettati' (o incapsulati, per me sono sinonimi, che differenza ci vedi?) all'interno di frammenti pcm, in alcuni casi (DOP) con l'aggiunta di un marker, in altri (ASIO) senza marker aggiuntivo, ma con header diversa.

quindi, in realtà, non è che ci sia quella grande differenza, di certo non un abisso.

Il punto è, piuttosto, che in tutti i casi il contenuto dei dati NON è PCM ma DSD, quindi deve essere interpretato dai sottosistemi utilizzatori, che per farlo devono saperlo. Il vantaggio di ASIO (e solo suo al momento) è che lavora a livello di driver di periferica, quindi 'filtra' tutti gli accessi, evitando situazioni potenzialmente pericolose, come descrivi. Mi pare francamente una scelta corretta, mentre lavorare a livello superiore espone a rischi inutili e comporta maggior lavoro (e minore standardizzazione) a livello applicativo (quello che abbiamo fatto in suqueezelite deve essere fatto su ogni player...).


Per portaudio ed asio v. mia risposta precedente.

[bibo01]

La trasmissione di DSD non-DoP ("nativo", ma è una definizione che mi piace poco perché crea confusione) sotto Mac non è normalmente possibile; lo è solo con i driver ASIO della ExaSound e con i software player che li supportano.

[marcoc1712]

enormi... si dimezza il data-rate sul bus USB!

*) a parità di max s/r supportato dall'hardware, raddoppia il max s/r DSD supportato;

*) a parità di s/r DSD si dimezza il data rate, con indubbi benefici in termine di "rumore" (interferenze) prodotte, ecc.


su Mac non ne ho idea... su Linux sì, sicuramente.


da capire qual è il problema... dubito possa dipendere dal semplice codice aggiunto per il DSD.


Che a livello di comunicazione "interna" al PC, tra software e driver ASIO, la comunicazione avvenga comunque con una sorta di DoP cambia poco.

Ciò che conta è quel che accade in uscita, sul bus USB.

È lì che la differenza è enorme: tra "impacchettare" (cioè banalmente raggruppare e suddividere in blocchi) i dati DSD (come avviene in modalità "nativa") ed "incapsularli" all'interno di vere e proprie frame PCM fittizie (come accade nel DoP) c'è un abisso!

Non fosse altro perché l'overhead introdotto dal DoP obbliga ad utilizzare un data-rate doppio rispetto a quello necessario in modalità nativa.

N.B.: AFAIK allo stato attuale i formati "nativi" sono estensioni proprietarie, non sono previsti dagli standard USB.


chi ha provato sostiene di sì... e, d'altro canto (visto il raddoppio del data-rate), è a dir poco probabile.


bingo.

In windows utilizzare ASIO è a dir poco... fondamentale! Non solo per il DSD (nativo o meno che sia), ma anche per il PCM.

È l'unico modo in cui puoi "by-passare" tutti i sottosistemi audio di windows, evitando che questi "pasticcino" con il tuo stream.

Non per caso su windows qualsiasi applicazione audio "seria" (tanto in campo "audiophile" quanto in campo "pro") usa esclusivamente ASIO... e non potrebbe essere altrimenti.

Tante cose...


Quelle sicuere:

l'errore di compilazione in SOX è provocato da una specifica istruzione NON presente nelle librerie dei compilatori di MS, almeno nonfino alla 2010 (ma nella 2015, dice Mansr, a seguto di specifica segnalazione) ma, d'altrocanto, le versioni di libreria indicate per lacompilazione in win di SOX non si compilano con toolbox superiori al 2010.

su Linux sì, sicuramente ...come (v. sotto)?

Overhead/incapsulamento/pachettizzazione:

ASIO: Header PCM / DSD ASIO + n*[8bit]Data.
DOP: n* [8bit marker + 16bit data]
ALSA: n* [8bit marker + (1 | 2 | 3) bytes (LE | BE)] data]

quindi:

Overhead Asio = size Header (40)/size stream -> trascurabile.
Overhead DOP = 8/24 = 33%
Overhead ALSA = 8/16 | 8/24 | 8/32) -> 50 - 25%

cui va aggiunto il 'normale' overhead di trasmissione.

Non ho capito cosa intendi per 'frame pcm' ma soprattutto dove sarebbe il compito oneroso, semplicemente aggiungi un marker di 8bit (un byte) ogni 16 di dati, la stessa cosa che fai (ca,bia solo la posizione) quando trasformi un o stream 24 bit in 32 (li aggiungi 0 non significativi).

A meno che non abbia capito male io e che i formati ALSA non abbiano marker (nel qual caso dovrebbero almeno avere un header, come asio), non ci vedo una differenza sostanziale rispetto a DOP, in caso contrario, non ci vedo nessuna sostanziale differenza rispetto ad ASIO.

In ogni caso, non vedo nemmeno una sostanziale differenza (tranne l'overhead in trsmissione) tra ASIO e DOP. Si tratta di implementazioni più o meno efficienti, ma comunque hai un carico più o meno grande lato ricevitore per 'riassemblare' il dsd, piccolo in assoluto, sicuramente inferiore a dover invertire l'endianess, per esempio (motivo per cui hanno introdotto la specifica di formato).

PA ASIO:

PA usa i diriver disponibili sul sistema e non è detto che WASAPI sia peggio di ASIO, c'è l'ennesima guerra di religione in merito, di certo, troppo spesso ho sentito lodi sperticate e annunci di cambiamenti notte giorno usando il driver asio... che poi si è rivelato essere asio4all che non è asio in nessun modo tranne che nel come si presenta!!!

Ma così come usare ASIO4ALL non vuol dire usare Asio, usare portaudio non compilato per asio non vuol dire non poter usare un diriver asio, dipende da come sono fatte le API e - soprattutto - da come sono implementate.

La necessità di compilare PA con a fianco ASIO è solo per utilizzare funzionalità specifiche di quello specifico driver asio (API aggiuntive), per le cose 'normali' un driver asio si presenta come un normale driver e così viene utilizzato, PA, im quei casi, non sa nemmeno che si tratta di ASIO (come non lo sa nessun applicativo che usa quel device).


Differenze all'ascolto:

Tu dici che chi ha provato sostiene di si, ma non certamente tutti, esiste una schiera enorme di persone che la negano ed è sempre la solita storia ove nel campo della percezione individuale è impossibile discernere se si tratta di reali differenze o autosuggestione.

Io non ho provato, quindi non metto becco, ma concordo che è probabile che un suo effetto lo abbia, almeno più del colore del case del dac.

[marcoc1712]

La trasmissione di DSD non-DoP ("nativo", ma è una definizione che mi piace poco perché crea confusione) sotto Mac non è normalmente possibile; lo è solo con i driver ASIO della ExaSound e con i software player che li supportano.

Buono a sapersi che un modo c'è anche in MAC, ma in Linux?

Concordo che 'nativo' crea confusione, qualcuno propone 'raw' ma mi pare almeno altrettanto sbagliato.

[bibo01]

Buono a sapersi che un modo c'è anche in MAC, ma in Linux?

Concordo che 'nativo' crea confusione, qualcuno propone 'raw' ma mi pare almeno altrettanto sbagliato.

In Linux, la trasmissione di DSD è non-DoP solo per i ricevitori USB supportati.

Inoltre, dato che

DSD Kbps
128 11,290
256 22,579
512 45,158

PCM Kbps
352 16,896
705 33,792

Se per fare DSD128, che ha bisogno di una banda di 11,290 Kbps, devo utilizzare PCM352.800 in DoP, che ha bisogno di una banda di 16,896 Kbps, c'è uno spreco/overhead del 49%!

[marcoc1712]

In Linux, la trasmissione di DSD è non-DoP solo per i ricevitori USB supportati.

Inoltre, dato che

DSD Kbps
128 11,290
256 22,579
512 45,158

PCM Kbps
352 16,896
705 33,792

Se per fare DSD128, che ha bisogno di una banda di 11,290 Kbps, devo utilizzare PCM352.800 in DoP, che ha bisogno di una banda di 16,896 Kbps, c'è uno spreco/overhead del 49%!

OK, è il discorso del margine/ricarico:

8 bit sono marker, 16 sono dati. Mettila come vuoi, l'efficienza è del 66.6% il peso del dop è del 50% in più rispetto al 'raw', al netto del normale overhead (quindi 49% ci sta), in ogni caso non è il doppio, questo puntualizzavo.

Però non ho capito COME funziona quando è non-DOP.

Con la stessa tecnica dei formati 'fake' (non so come chiamarli, li ho battezzati così adesso) pcm applicata a squeezelite o mediante una trasmissione 'raw' (senza marker, stile asio, quindi senza overhead)?

EDIT: SI, cercando in giro ho trovato un thd che Bibo consce bene bene e dal quale si capisce che HQP usa lo stesso metodo di Squeezelite in alternativa al DOP, anche se mi pare che sia HQP che MPD siano alle prese con problemi vari.

Il repository di riferimento è quello che ho postato più sopra.