DSD in LMS con SOX

[antonellocaroli]

Ok, riprovato...adesso va senza problemi...in Dop max dsd128

con Hqplayer va in "nativo" fino dsd256 in dop fino a 128

[UnixMan]

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.

sì, ma stai parlando sempre di ciò che accade sull'interfaccia "interna", nel PC... dove la cosa è sostanzialmente irrilevante in ogni caso.

La differenza tra DoP e "nativo" (o comunque lo si voglia chiamare) riguarda invece soprattutto ciò che accade sul bus USB.

si tratta sempre di dati 'impachettati' (o incapsulati, per me sono sinonimi, che differenza ci vedi?)

non so se sia una definizione canonica ma, personalmente, parlo di "incapsulamento" quando i dati che costituiscono il "payload" vengono aggiunti all'interno di "frame" di un qualche protocollo che aggiunge altri "dati di servizio" (headers/footers, ecc), mentre uso il termine "impacchettamento" quando uno stream viene suddiviso in blocchi di dimensione prestabilita senza aggiungere altro.

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.

lo stesso accade anche con ALSA, quando operi in modalità "nativa".

Per portaudio ed asio v. mia risposta precedente.

direi che dipende dalle licenze di SL e PA, nonché da come sono utilizzate le librerie ASIO.

Se tanto PA quanto SL fossero distribuiti con licenza LGPL, il problema non si porrebbe in nessun caso.

Il problema si pone solo nel caso in cui (almeno) uno dei software coinvolti è distribuito con licenza GPL e, se non sono presenti le lib. proprietarie, non funziona niente.

Ma se invece, ad es., le librerie ASIO (proprietarie) fossero caricate dinamicamente a runtime (come "plugin") da PA, e quindi tutto (salvo il supporto ASIO, ovviamente) può funzionare anche se quelle librerie non sono presenti, il problema non si pone. Neanche nel caso lo stesso PA sia distribuito con licenza GPL.

Idem se PA fosse LGPL e (se compilato con quella opzione) non potesse funzionare senza la presenza delle lib. ASIO, purché SL (lo stesso eseguibile) possa funzionare anche con una versione di PA che non dipende dalle lib. proprietarie.

Da indagare... ed eventualmente risolvere in qualche modo.

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.
[B]

seccante. Non si può sostituire in qualche modo quella specifica istruzione, almeno nel caso di compilazione con compilatori MS?

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.

vedi sopra: ti stai riferendo sempre a ciò che accade all'interno del PC, tra il "software utente" e l'interfaccia di sistema (driver). Laddove questo tipo di overhead è sostanzialmente del tutto ininfluente.

È "in uscita", sul bus USB - laddove le modalità di comunicazione sono definite dall'hardware (interfaccia Xmos o quel che sia) e non cambiano in funzione del sistema - che evidentemente c'è una differenza significativa tra DoP e DSD "nativo".

A quanto sembra, a quel livello, in modalità "nativa" vengono trasferiti soltanto i dati (payload) dello stream DSD, verosimilmente preceduti da comandi che informano l'interfaccia su ciò che sta per ricevere (ed eventualmente seguiti da altri che segnalano la fine dello stream, e/o il passaggio ad una modalità diversa). Presumibilmente (dato che 176.4*32 fa esattamente 5.644,8 = DSD128) tutte le "comunicazioni di servizio" avvengono "off-band", all'interno dell'overhead del protocollo USB e non occupano minimamente la banda destinata al payload audio. Cioè non c'è alcun overhead aggiuntivo (oltre a quello intrinseco del protocollo USB).

PA ASIO:

PA usa i diriver disponibili sul sistema e non è detto che WASAPI sia peggio di ASIO,

non voglio immischiarmi in nessuna guerra di religione, tanto più che riguarda un "campo" che non mi interessa affatto.

Ma, nel caso specifico, il problema è che - se non vado errato - windows e WASAPI non supportano DSD.

Si può aggirare il problema "ingannando" il sistema utilizzando DoP... ma, oltre agli inconvenienti legati all'overhead su USB, resta il fatto che non "sapendo" che in realtà non si tratta di PCM, il sistema potrebbe "pasticciare" indebitamente con lo stream (controlli di volume, mixer - e quindi resampling, ecc).

Per quel poco che ne so io (e sempre se non ho capito male), per quanto ci riguarda il vantaggio principale dei driver ASIO (ovviamente se "veri", non un "wrapper" come ASIO4ALL) è quello di fornire una interfaccia "diretta" all'hardware (cioè in sostanza qualcosa di analogo ad un device di tipo "hw:x,y" di ALSA), che by-passa completamente tutto il sottosistema audio di windows.

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.

qui passo, non ho alcuna idea dei dettagli su quei sistemi. Però ciò che dici mi sembra piuttosto strano: come fai ad utilizzare (direttamente!) un driver ASIO se "non ne conosci" l'interfaccia?

La necessità di compilare PA con a fianco ASIO è solo per utilizzare funzionalità specifiche di quello specifico driver asio (API aggiuntive),

che -se non vado errato- è esattamente ciò di cui avresti bisogno: il supporto al DSD è una funzionalità molto specifica, limitata esclusivamente ad alcuni driver di alcune interfacce!

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

n'est ce pas, monsieur de La Palice?

Ovvio. Lo stesso vale anche per windows: per poter avere "non-DoP" devi avere una scheda che supporti quella modalità e dei driver specifici che la supportino (non tutti lo fanno).

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%!

esatto.

Questo ovviamente perché le "velocità di trasmissione" sul bus USB non sono libere, ma fisse e predeterminate sulla base dei s/r standard PCM. Quindi basta anche un solo bit di overhead ("in banda", cioè all'interno dello stream dei dati audio) per essere costretti ad utilizzare la velocità superiore, che è sempre doppia rispetto alla precedente.

[marcoc1712]

Ok, riprovato...adesso va senza problemi...in Dop max dsd128

con Hqplayer va in "nativo" fino dsd256 in dop fino a 128

sempre windows, giusto? In linux (squeezelite e HSP)?

[marcoc1712]

direi che dipende dalle licenze di SL e PA, nonché da come sono utilizzate le librerie ASIO.

SL e PA non hanno problemi, è che non puoi distribuire liberamente le SDK di ASIO, quindi il singolo user se lo deve scaricare, come FFMPEG, LAME, MAD,...

seccante. Non si può sostituire in qualche modo quella specifica istruzione, almeno nel caso di compilazione con compilatori MS?

No, la particolare istruzione (sigint) non ha una corrisopndneza e - sembra incredibile - non è nemmeno implementabile esternamnete (nel senso che nojn si è certi che restituisca identico risultato).

cmq Mansr ha risposto di aver pubblicato la soluzione modificata che fa uso delle ultime librerie di tutto e si compila in MSVC2015. Dovrò riscaricarmi tutte le librerie e riprovare e certamente non sarà portabile in XP. Considerazione mia, così non passerà mai a standard, dove il target di compilazione è msvc2008 e 2010, poi bisogna vedere su mac.

Per quel poco che ne so io (e sempre se non ho capito male), per quanto ci riguarda il vantaggio principale dei driver ASIO (ovviamente se "veri", non un "wrapper" come ASIO4ALL) è quello di fornire una interfaccia "diretta" all'hardware (cioè in sostanza qualcosa di analogo ad un device di tipo "hw:x,y" di ALSA), che by-passa completamente tutto il sottosistema audio di windows.

qui passo, non ho alcuna idea dei dettagli su quei sistemi. Però ciò che dici mi sembra piuttosto strano: come fai ad utilizzare (direttamente!) un driver ASIO se "non ne conosci" l'interfaccia?

Ovviamente esiste un'interfaccia di riferimento 'minima' per un dispositivo audio, che tutti i driver di qualsiasi natura devono implementare, altrimenti non funzionano. Fintanto che un driver ASIO implementa quelle API e limitatamente alle funzionalità da esse supportate, viene usato da qualsiaisi applicativo, senza che debba necessariamente sapere che si tratta di un driver ASIO, poi - forse - nella dll distribuita c'è anche un minimo di supporto ad ASIO,non ne ho idea, ma - come già scritto - il problema sono le funzionalità aggiuntive, di cui bisogna informare gli applicativi utente.

Per far questo con PA bisogna ricompilare la dll avendo ASIO SDK installato, producendo così una versione diversa della dll. Forse puoi anche distribuirla, ma cosa fai comprendi tutte le possibili interfacce?

Io non mi ci metto di certo!!!

[UnixMan]

SL e PA non hanno problemi,

in che senso non hanno problemi? Se una delle due è GPL, non puoi redistribuire un binario che sia stato "linkato" con una libreria "non-free"...

è che non puoi distribuire liberamente le SDK di ASIO, quindi il singolo user se lo deve scaricare, come FFMPEG, LAME, MAD,...

questo di per sé non mi sembra poi un grosso problema. Ma poi si dovrebbero anche compilare da soli SL? Questa sì che invece sarebbe una soluzione poco pratica per la maggior parte dei possibili utenti...

No, la particolare istruzione (sigint) non ha una corrisopndneza e - sembra incredibile - non è nemmeno implementabile esternamnete (nel senso che nojn si è certi che restituisca identico risultato).

doppiamente seccante. Ma nelle versioni precedenti come facevano?

BTW: torniamo un attimo all'ipotesi gcc su windows: dicevi che manca "make". In che senso? che ti manca il tool o che manca un Makefile specifico?

Ovviamente esiste un'interfaccia di riferimento 'minima' per un dispositivo audio, che tutti i driver di qualsiasi natura devono implementare, altrimenti non funzionano. Fintanto che un driver ASIO implementa quelle API e limitatamente alle funzionalità da esse supportate, [...]

ribadisco la mia ignoranza in materia, ma... ASIO non ha una sua interfaccia (API) specifica, diversa da quella dei driver diciamo così "nativi" di windows?
Immaginavo di sì, perché ho visto che in genere le applicazioni che non supportano espressamente ASIO non possono proprio usare quei driver (almeno non direttamente): se non c'è (anche) un driver "nativo" (KS, WASAPI o quello che sia), l'interfaccia corrispondente non la vedono proprio. IIRC ad es. per poter usare ASIO con Foobar2000 bisogna installare un apposito plugin (e la gestione è completamente diversa e separata da quella dell'output verso i driver "nativi" di windows).

[...] forse - nella dll distribuita c'è anche un minimo di supporto ad ASIO,non ne ho idea, ma - come già scritto - il problema sono le funzionalità aggiuntive, di cui bisogna informare gli applicativi utente.

Per far questo con PA bisogna ricompilare la dll avendo ASIO SDK installato, producendo così una versione diversa della dll. Forse puoi anche distribuirla, ma cosa fai comprendi tutte le possibili interfacce?

non sarebbero poi molte, quelle che supportano DSD "non-DoP"... ma, se ho capito bene, non credo sia necessario fare niente del genere: sempre se ho capito bene, ASIO ha "standardizzato" la sua interfaccia (API) per il DSD nativo, per cui basta gestire quella (né più né meno come fatto per ALSA). Presumo che poi siano i driver delle singole interfacce che si fanno carico di gestire le specificità di ognuna...

[antonellocaroli]

sempre windows, giusto? In linux (squeezelite e HSP)?

Si, giusto. SL e networaudiod su win, LMS e HQP su linux

[UnixMan]

Marco,

ad occhio e croce (fatto salvo un problema con ffmpeg, che non ci interessa), non dovrebbe essere un problema compilare sox su windows con gcc (MingGW). Se non ho visto male, è proprio così che vengono prodotti gli eseguibili di sox per windows distribuiti dal sito ufficiale.

http://en.wikipedia.org/wiki/MinGW

32bit: MinGW | Minimalist GNU for Windows

64bit: http://www.mingw-w64.org/

https://duckduckgo.com/?q=building+%2Bsox+windows+mingw

La procedura per il build dovrebbe essere identica a quella per Unix/Linux:

./configure --disable-shared
make

[marcoc1712]

Marco,

ad occhio e croce (fatto salvo un problema con ffmpeg, che non ci interessa), non dovrebbe essere un problema compilare sox su windows con gcc (MingGW). Se non ho visto male, è proprio così che vengono prodotti gli eseguibili di sox per windows distribuiti dal sito ufficiale.

http://en.wikipedia.org/wiki/MinGW

32bit: MinGW | Minimalist GNU for Windows

64bit: http://www.mingw-w64.org/

https://duckduckgo.com/?q=building+%2Bsox+windows+mingw

La procedura per il build dovrebbe essere identica a quella per Unix/Linux:

./configure --disable-shared
make

Sempre il solito problema con XP, la versione che ho installato non basta, ma le nuove non si installano. Se riesci, prova su una macchina diversa dalla mia.

[UnixMan]

Sempre il solito problema con XP, la versione che ho installato non basta, ma le nuove non si installano. Se riesci, prova su una macchina diversa dalla mia.

al momento non ho nessuna macchina (fisica o virtuale) con win a portata di mano... Filippo, puoi provare tu?

[antonellocaroli]

Filippo, puoi provare tu?

Volentieri!!! ma non ho la piú pallida idea di Cosa dovrei fare...se mi guidate passo a passo...