collegamenti digitali per musica liquida & Co

L’ultima frontiera dell’alta fedeltà in auto
Avatar utente
Etabeta
sysadmin
sysadmin
Messaggi: 2673
Iscritto il: 13 apr 2018, 17:32
Località: Torino

Re: Pioneer P99 capacità HDD

#41

Messaggio da Etabeta »

Dude ha scritto: Ripeto, secondo me per Android <5 era una disponibilità più teorica che altro. Tu hai evidenze di segno diverso?
Il primo che mi viene in mente è stato il Samsung Galaxy Note 3 (4.4.2, cioè prima che fosse proprio partorito andorid 5) è stato uno dei primi smartphone a supportare otg e usb audio.
Avatar utente
ozama
Supertweeter
Messaggi: 11599
Iscritto il: 17 gen 2017, 18:10
Località: Copparo (Ferrara)

Re: Pioneer P99 capacità HDD

#42

Messaggio da ozama »

Alla fine ho letto il link.
A me chiarisce alcune cose, che sapevo (ma non ho voluto insistere perchè NON AVEVO BEN CHIARO IL PERCHÈ). ^^
Ad esempio, quando usi la sottomodalità "asincrona", non sei soggetto al clock (tradotto "orologio") USB ma a quello della periferica che trasmette l'audio, che daltronde trasmette con la FS che gli pare. Perchè stiamo facendo STREAMING. Non stiamo semplicemente "trasportando dati". Quindi è per questo, che, COME AVEVO LETTO in maniera ESPLICITA, ma non dettagliata, se si trasferise audio IN STREAMING ASINCRONO, che è QUELLO CHE CI SERVE PER CONVERTIRLO IN SPDIF per alimentare direttamnte un DSP o un convertitore esterno, la USB NON PUÒ FARE ALTRO CHE QUELLO. O_O
Tralasciamo il termine "abusato" "modalità OTG", che non riguarda direttamente l'audio e riguarda, tra l'altro, solo il mondo Android. E concentriamoci sulla più generica "trasmissione audio via USB", che può essere veicolata ANCHE con la modalità OTG, che è solo una "interfaccia" Android, o Lighting, che è solo un'interfaccia Apple.
Riguardo alla USB, Non è una questione di quantità di dati e quindi di "banda passante". È una questione di CLOCK.
Per trasmettere "pacchetti audio" insieme altri dati, deve essere la USB a decidere cosa trasmettere e quando, secondo il PROPRIO protocollo, che viene adattato alle varie modalità. E questo è INCOMPATIBILE con il flusso SPDIF che è quello che deve essere trasportato dalla nostra USB per alimentare un convertitore o un DSP, con varie FS, che devono essere precise ed agganciate dall'interfaccia ricevente.
Per trasmettere audio IN STREAMING, la USB fornisce l'interfaccia elettrica, ma viene "posseduta" dal sistema che genera l'audio. Che poi è l'applicazione che SUONA files audio e li incanala attraverso la USB, con la modalità richiesta.
Se la modalità richiesta è la conversione in analogico tramite una scheda sonora esterna, la USB trasmetterà "pacchetti audio" assieme a quelli di controllo della scheda. NON STREAMING. E non ci sono problemi di sincro. L'audio È PRODOTTO dalla scheda esterna, ricostruendo i pacchetti secondo istruzioni e SECONDO IL PROPRIO CLOCK LOCALE. Anche se poi da questa preleveremo una eventuale uscita audio digitale (AES, ADAT, I2S, SPDIF..). :yes:
E ci può essere un hub e pure altre periferiche collegate. Al limite, ci sarà un po' di latenza tra i nostri comandi (play/stop/pausa/avanti/indietro..) e l'output audio. Problema sentito e combattuto peraltro nella produzione di audio dai musicisti.
È la stessa cosa che veicolare l'audio (e il video) da un server ad un player via rete, anche wireless.
Perchè è il PLAYER a cui arrivano i dati quello che GENERA AUDIO IN LOCALE, A PARTIRE DALLE ISTRUZIONI O DAI PACCHETTI che arrivano.
Nel nostro caso, la sorgente con uscita AUDIO (non "DATI") USB (che sia PC o Apple con USB, Android con USB OTG, Apple Lighting USB) esce, ripeto: ESCE con UNO STREAMING SPDIF, con la propriaFS, attraverso la PORTA USB. Non CON IL PROTOCOLLO USB.
Perchè il nostro DSP/elaboratore/convertitore esterno NON È UN "PLAYER CHE COMPONE I PACCHETTI" e nemmeno una scheda audio, che dovrebbe RICEVERE ISTRUZIONI DALLA SORGENTE, per GENERARE AUDIO AL PROPRIO INTERNO, DAI PACCHETTI. È solo una periferica di elaborazione di audio già generato da altri. Quindi deve ricevere un flusso AUDIO come un qualsiasi convertitore D/A domestico.
Se andate a vedere quelli più versatili, tante volte hanno anche un player interno. Quelli che ce l'hanno, normalmente, hanno uno o più connettori USB rettangolari (per hdd, chiavette, smartphone eventuali) e un connettore trapezioidale riservato come INGRESSO SOLO AUDIO USB. :hmm:
Difatti, dati e streaming, sono cose diverse e NON POSSONO CONVIVERE sulla stessa linea USB.
Quindi, se si intende usare uno smartphone in OTG con un hub ed un HDD contemporaneamente collegato, dovrà essere anche collegata all'hub UNA SCHEDA AUDIO ESTERNA (supportata dal sistema operativo dello smartphone, naturalmente), che genererà essa stessa l'audio, a partire dai files contenuti mel telefono o nell'HDD. Sarà poi QUESTA SCHEDA AUDIO ESTERNA ad inviare l'audio (spdif) al DSP.
Ma vale la pena? :hmm:
Spero di aver capito bene.. ^^
E spero di aver fatto capire cosa intendo.. ^^ ^^ ^^
Ciao! :)
Sorgente: Pioneer DEH X8500 DAB modificata con sovra campionatore 24/48 ed uscita SPDIF ottica sotto controllo volume da Etabeta.
- DSP Helix DSP3s
- Amplificatore 6 canali Audison AF M6d:
2 canali su woofers Audio Development W60
2 canali su full range 2 pollici Audible Physics 220 CP
2 canali in bridge su sub Sonus by Nostromo & rs250v, in cassa chiusa.
Avatar utente
Dude
Moderatore
Moderatore
Messaggi: 7838
Iscritto il: 3 gen 2013, 10:48
Località: Camogli

Re: Pioneer P99 capacità HDD

#43

Messaggio da Dude »

Etabeta ha scritto:
Dude ha scritto: Ripeto, secondo me per Android <5 era una disponibilità più teorica che altro. Tu hai evidenze di segno diverso?
Il primo che mi viene in mente è stato il Samsung Galaxy Note 3 (4.4.2, cioè prima che fosse proprio partorito andorid 5) è stato uno dei primi smartphone a supportare otg e usb audio.
Che conferma quanto avevo letto e che riportavo, ossia che l'OTG era *effettivamente* implementato solo sui modelli di fascia alta, nel periodo tra Android 4 e 5.
Io sono per lo ius culturae al contrario.
Al primo "se io avrei" vai fuori dai c@glioni
Avatar utente
mark3004
Moderatore
Moderatore
Messaggi: 7433
Iscritto il: 9 giu 2012, 23:02
Località: Georgia, USA

Re: Pioneer P99 capacità HDD

#44

Messaggio da mark3004 »

ozama ha scritto: ... Difatti, dati e streaming, sono cose diverse e NON POSSONO CONVIVERE sulla stessa linea USB....
Non approvo molto in genere quello che dici riassunto nella frase che quoto.

Se parliamo dei dati che ATTRAVERSANO il collegamento USB non c'è differenza tra streaming audio e dati. Sono la stessa cosa, sono bit!

Cerco di spiegare un pò il concetto generale.

La trasmissione via USB, che sia streaming musica o flusso dati (che poi sono sempre pacchetti dati di byte) avviene sempre in maniera asincrona. Pertanto che siano bit audio o bit dati non fa differenza!
La comunicazione asincrona, come hai correttamente detto, non si affida ad un clock esterno ma invia due extra bit di inizio e fine pacchetto a definire un paccheto di byte. Che poi questo pacchetto di byte sia audio o dati poco cambia, sono sempre bit, l'invio dati rimane identico, sta poi ai due dispositivi (interfacce) collegati a ai capi della usb interpretare i dati.
E come ho già ribadito la trasmissione sulla linea, che sia solo audio, solo dati, trova limite solo sulla velocità (e quindi quantità di flusso dei dati) da spostare dall'host al client e viceversa.
Link tecnici "must read":
GUIDA CROSSOVER: viewtopic.php?f=5&t=15831
GUIDA GAIN: viewtopic.php?f=33&t=13215
BURN IN DRIVERS: viewtopic.php?f=33&t=15058
COMINCIARE SENZA BUTTARE SOLDI: viewtopic.php?f=20&t=14746
Avatar utente
Etabeta
sysadmin
sysadmin
Messaggi: 2673
Iscritto il: 13 apr 2018, 17:32
Località: Torino

Re: Pioneer P99 capacità HDD

#45

Messaggio da Etabeta »

Volendo riassumere, tanto per incominciare per affrontarte una cosa alla volta, i concetti chiave riguardo l'aspetto specifico del clock audio, un "pilastro" basilare su cui si poggia la qualità ottenibile in uscita dalla nostra interfaccia o dac:

Le modalità di trasmissione di un flusso dati audio via usb da un player/sorgente (host) verso un periferica esterna sono essenzialmente due (in realtà ci sono anche altre modalità ma non dilunghiamo):

1) modalità "ADAPTIVE/ADATTATIVA" tipicamente utilizzata in dispositivi audio (siano essi dac o interfacce spdif o i2s) più semplici ed economici in cui il clock dettato al dac (o al flusso spdif in uscita o il master clock dell'i2s in uscita) non è imposto dalla periferica ma ricavato per adattamento (modalità adaptive appunto) appunto rispetto alla cadenza dei pacchetti audio ricevuti (di mezzo ci sono altri aspetti, non mi dilungo) che, tramite un pll tipicamente integrato nel chip della periferica, genera appunto il clock audio.
E' economico in quanto la soluzione circuitale è molto molto semplice, in commercio ci sono diversi chip che integrano tutto al loro interno, in pratica hanno i pin per connettersi direttamente alla porta usb da un lato e l'uscita spdif (o analogica se si integano anche un dac) dall'altro. E' necessario una solo sorgente di clock, non necessariamente molto precisa, che serve come riferimento sia per lo scambio di dati lato usb che come base per la genrazione del clock audio tramite il PLL (detto in soldoni il PLL è un modulo, all'interno del chip che tramite il quale viene "inseguita" e agganciata una frequenza tramite aggiustamenti successivi in questo caso la frequenza di campionamento audio della sorgente, ricevata dalla cadenza dei pacchetti dati audio ricevuti via usb).
Tale clock non potrà essere molto preciso in quanto è imprecisa alla fonte la cadenza temporale data dall'usb (non è che però sia una "schifezza" si parla di qualche centinaia di picosecondi di jitter, il valutarlo ad orecchio è poi un altro paio di maniche).
L'esempio è il popolarissimo chip PCM2902 che già ho citato, lavora, in output (lo specifico perchè è una interfaccia audio bidirezionale) in malità adaptive, e non suona affatto male! (lo uso spesso come sorgente spdif "volante")

2) modalità "ASINCRONA" tipicamente adottata nei dispositivi più costosi (in quanto per generare uno o più segnali di clock in modo preciso occorrono componenti aggiuntivi rispetto alla soluzione "adaptive") in cui invece è la periferica audio che stabilisce, rispetto all'host/player, la cadenza con cui ricevere i dati, potendo quindi stabilire un clock audio appunto asincrono (ovvero scorrelato) rispetto a quello che nell'host detta i tempi alla porta usb.
La complessità di realizzazione di questo tipo di interfaccia è data dal fatto che non solo bisogna generare localmente i/il clock (dovrà essere più di un clock nel caso in cui non faccio uso di pll e voglio poter gestire più frequenze di campionamento ad esempio 24.576Mhz per i 48/96/192KHz o 22.579Mhz per i 44.1/88.2KHz) ma anche avere una logica di bordo in grado di dialogare in continuazione con l'host/player per la ricezione dei dati secondo una determinata cadenza tale da garantire che il buffer in ingresso non si svuoti mai.
Il grado di precisione/stabilità del clock, ovvero il basso livello di jitter, è data esclusivamente dalla qualità del generatore di clock locale, tipicamente quarzato (con compensazone della tempertura ecc.. ma qui si va per le lunghe),
questo tipo di soluzione a mio avviso ha più senso se desideriamo interfacciarci via I2S (che ha una lina di clock separata) che via SPDIF in quanto in quest'ultimo caso, comunque, buona parte della precisione verrebbe "bruciata" dalla successiva decodifica spdif (e qui si aprirebbe un altro capitolo..).
Ultima modifica di Etabeta il 24 ago 2018, 14:54, modificato 1 volta in totale.
Avatar utente
mark3004
Moderatore
Moderatore
Messaggi: 7433
Iscritto il: 9 giu 2012, 23:02
Località: Georgia, USA

Re: Pioneer P99 capacità HDD

#46

Messaggio da mark3004 »

Ed aggiungo, giusto per completezza tecnica, che ad esempio la firewire (IEEE1394) può lavorare sia in modo sincrono che asincrono. Ma perchè stanno scomparendo anche le firewire a favore delle usb? semplicemente perchè le firewire sincrona avevano sì una trasmissione dati ampia, fino a 32000MB/sec. per alcune (all'eopoca delle firewire la USB3 ancora non c'era), ma la trasmissione sincrona non prevede il controllo dei bit (si affida solo a clock esterno), quindi i dati ricevuto sono quelli e basta, che siano giusti o sbagliati. La usb invece è una trasmissione più affidabile, non si affida ad un clock esterno ed ha un bit di parità per il controllo dati. E con l'avvento della versione 3 si è ovviato anche al "problema" della quantità dati da trasmettere.
Link tecnici "must read":
GUIDA CROSSOVER: viewtopic.php?f=5&t=15831
GUIDA GAIN: viewtopic.php?f=33&t=13215
BURN IN DRIVERS: viewtopic.php?f=33&t=15058
COMINCIARE SENZA BUTTARE SOLDI: viewtopic.php?f=20&t=14746
Avatar utente
mark3004
Moderatore
Moderatore
Messaggi: 7433
Iscritto il: 9 giu 2012, 23:02
Località: Georgia, USA

Re: Pioneer P99 capacità HDD

#47

Messaggio da mark3004 »

Etabeta ha scritto: ..............
2) modalità "ASINCRONA" tipicamente adottata nei dispositivi più costosi (in quanto per generare uno o più segnali di clock in modo preciso occorrono componenti aggiuntivi rispetto alla soluzione "adaptive") in cui invece è la periferica audio che stabilisce, rispetto all'host/player, la cadenza con cui ricevere i dati, potendo quindi stabilire un clock audio appunto asincrono (ovvero scorrelato) rispetto a quello che nell'host detta i tempi alla porta usb.
La complessità di realizzazione di questo tipo di interfaccia è data dal fatto che non solo bisogna generare localmente i/il clock (dovrà essere più di un clock nel caso in cui non faccio uso di pll e voglio poter gestire più frequenze di campionamento ad esempio 24.576Mhz per i 48/96/192KHz o 22.579Mhz per i 44.1/88.2KHz) ma anche avere una logica di bordo in grado di dialogare in continuazione con l'host/player per la ricezione dei dati secondo una determinata cadenza tale da garantire che il buffer in ingresso non si svuoti mai.
Il grado di precisione/stabilità del clock, ovvero il basso livello di jitter, è data esclusivamente dalla qualità del generatore di clock locale, tipicamente quarzato (con compensazone della tempertura ecc.. ma qui si va per le lunghe),
questo tipo di soluzione a mio avviso ha più senso se desideriamo interfacciarci via I2S (che ha una lina di clock separata) che via SPDIF in quanto in quest'ultimo caso, comunque, buona parte della precisione verrebbe "bruciata" dalla successiva decodifica spdif (e qui si aprirebbe un altro capitolo..).
Esatto, ed in generale i convertitori USB->SPDIF (o altro che sia) sono loro che si "adattano" alla velocità di traqsferimento dati dell'host, difatti nelle schede delle caratteristiche tecniche di tali dispositivi si trova sempre la risoluzione minima e massima supportata. E sono stati progettati dai costruttori proprio sulla base delle specifiche date da Android System sulla trasmissione dati (quelle nell'articolo linkato).
Link tecnici "must read":
GUIDA CROSSOVER: viewtopic.php?f=5&t=15831
GUIDA GAIN: viewtopic.php?f=33&t=13215
BURN IN DRIVERS: viewtopic.php?f=33&t=15058
COMINCIARE SENZA BUTTARE SOLDI: viewtopic.php?f=20&t=14746
Avatar utente
Etabeta
sysadmin
sysadmin
Messaggi: 2673
Iscritto il: 13 apr 2018, 17:32
Località: Torino

Re: Pioneer P99 capacità HDD

#48

Messaggio da Etabeta »

E in effetti uno degli aspetti che rendono generalmente più "facili" le intefacce audio usb adattative rispetto a quelle asincrone (in ambito android) è che queste ultime generalmente necessitano di un opportuno driver che non può essere generico come nel caso dei dispositivi di intrerfaccia adattivi (c'è una minore complessità, per via del fatto che il sistema operativo, in quel caso, invia l'audio secondo una sua logica temporale interna, non deve sottostare a ciò che "detta" il dispositivo esterno, come invece accade per l'asicrono).
In ambito pc il problema non si pone, basta installare l'opportuno driver.
Avatar utente
mark3004
Moderatore
Moderatore
Messaggi: 7433
Iscritto il: 9 giu 2012, 23:02
Località: Georgia, USA

Re: Pioneer P99 capacità HDD

#49

Messaggio da mark3004 »

Etabeta ha scritto:E in effetti uno degli aspetti che rendono generalmente più "facili" le intefacce audio usb adattative rispetto a quelle asincrone (in ambito android) è che queste ultime generalmente necessitano di un opportuno driver che non può essere generico come nel caso dei dispositivi di intrerfaccia adattivi (c'è una minore complessità, per via del fatto che il sistema operativo, in quel caso, invia l'audio secondo una sua logica temporale interna, non deve sottostare a ciò che "detta" il dispositivo esterno, come invece accade per l'asicrono).
In ambito pc il problema non si pone, basta installare l'opportuno driver.
Si ma infatti vedi Android è un sistema driverless, gli sviluppatori definiscono i protocolli e mettono tutto alla lauce del sole, sta poi ai vari produttori di aziende acquisirne il protocollo e sviluppare il prodotto già bello e pronto.

Con windows invece rimane tutto "acerbo", c'è l'interfaccia generica (usb o al tro che sia) e dei driver generici, lasciando al produttore l'incombenza di sviluppare anche il driver specifico per pilotare il dispositivo, laddove non ne abbia uno generico la microsoft.
Link tecnici "must read":
GUIDA CROSSOVER: viewtopic.php?f=5&t=15831
GUIDA GAIN: viewtopic.php?f=33&t=13215
BURN IN DRIVERS: viewtopic.php?f=33&t=15058
COMINCIARE SENZA BUTTARE SOLDI: viewtopic.php?f=20&t=14746
Avatar utente
ozama
Supertweeter
Messaggi: 11599
Iscritto il: 17 gen 2017, 18:10
Località: Copparo (Ferrara)

Re: Pioneer P99 capacità HDD

#50

Messaggio da ozama »

Bene.
Allora provate a collegare un hub tra un PC/Android ed un DAC con ingresso USB (senza nemmeno scomodarsi ad interporre un adattatore USB-SPDIF, se non necessario), aggiungere un HDD allo stesso hub e mandare in play un file audio residente sull'HDD, dal player su Android, verso il DAC USB.
Da quel che ho capito io, se funziona, il suono sarà giocoforza trasmesso in modo sincrono e la qualità audio dipenderà dalla qualità del ricevitore USB o SPDIF: se eseguono un recklocking "con le palle", suoneranno meglio che se non eseguono il recklocking.
È questo il punto.
Ammettiamo che sia fattibile e "funzioni".
Le prove che fanno sulle riviste audio reputate "serie", sono sempre comunque da prendere con le molle, perchè tutto va contestualizzato. Ma se questi esperimenti li hanno già fatti altri, perchè non valutarli?
Ora, io uso un'interfaccia da 60 Euro, che si connetterà in modo "sincrono" e che avrà un PLL di qualità "60 Euro". Ammesso che naturalmente funzioni, perchè devo rischiare di peggiorare le prestazioni del sistema interponendo un hub ed un HDD sulla stessa USB? Per cosa? Per avere più spazio?
Io penso che sia opportuno acquistare una sorgente che non mi impone questa scelta. Che già è un compromesso. -.-
Poi, ognuno ha le proprie priorità. :D
Ciao! :)
Sorgente: Pioneer DEH X8500 DAB modificata con sovra campionatore 24/48 ed uscita SPDIF ottica sotto controllo volume da Etabeta.
- DSP Helix DSP3s
- Amplificatore 6 canali Audison AF M6d:
2 canali su woofers Audio Development W60
2 canali su full range 2 pollici Audible Physics 220 CP
2 canali in bridge su sub Sonus by Nostromo & rs250v, in cassa chiusa.
Avatar utente
mark3004
Moderatore
Moderatore
Messaggi: 7433
Iscritto il: 9 giu 2012, 23:02
Località: Georgia, USA

Re: Musica Liquida ed i suoi misteri

#51

Messaggio da mark3004 »

ozama ha scritto:Bene.
Allora provate a collegare un hub tra un PC/Android ed un DAC con ingresso USB (senza nemmeno scomodarsi ad interporre un adattatore USB-SPDIF, se non necessario), aggiungere un HDD allo stesso hub e mandare in play un file audio residente sull'HDD, dal player su Android, verso il DAC USB.
Da quel che ho capito io, se funziona, il suono sarà giocoforza trasmesso in modo sincrono e la qualità audio dipenderà dalla qualità del ricevitore USB o SPDIF: se eseguono un recklocking "con le palle", suoneranno meglio che se non eseguono il recklocking.
È questo il punto.
Ammettiamo che sia fattibile e "funzioni".
Le prove che fanno sulle riviste audio reputate "serie", sono sempre comunque da prendere con le molle, perchè tutto va contestualizzato. Ma se questi esperimenti li hanno già fatti altri, perchè non valutarli?
Ora, io uso un'interfaccia da 60 Euro, che si connetterà in modo "sincrono" e che avrà un PLL di qualità "60 Euro". Ammesso che naturalmente funzioni, perchè devo rischiare di peggiorare le prestazioni del sistema interponendo un hub ed un HDD sulla stessa USB? Per cosa? Per avere più spazio?
Io penso che sia opportuno acquistare una sorgente che non mi impone questa scelta. Che già è un compromesso. -.-
Poi, ognuno ha le proprie priorità. :D
Ciao! :)
Che vuol dire per te "peggiorare le prestazioni" se parliamo di trasmissione USB scusa? Se la linea, a livello di flusso dati e dispositivi ad essa collegati la supportano, dove c'è il peggiormento? Ancora e ripeto, parliamo di digitale, di bit, non c'è un "degrado" del segnale. Se il flusso dati è supportato la trasmissione avviene, se non è supportato la trasmissione non avviene o si verificano dei lag in alcune fasi, tutto qui. Qui si discuteva sulle potenzialità/possibilità o meno di farlo. che poi io in primis sono della filosofia "semplice è meglio" a prescindere ci mancherebbe. (Altro motivo per cui non trovo pace con l'impianto, non riuscendo a trovare il giusto compromesso! ^^ ).
Link tecnici "must read":
GUIDA CROSSOVER: viewtopic.php?f=5&t=15831
GUIDA GAIN: viewtopic.php?f=33&t=13215
BURN IN DRIVERS: viewtopic.php?f=33&t=15058
COMINCIARE SENZA BUTTARE SOLDI: viewtopic.php?f=20&t=14746
Avatar utente
mark3004
Moderatore
Moderatore
Messaggi: 7433
Iscritto il: 9 giu 2012, 23:02
Località: Georgia, USA

Re: Musica Liquida ed i suoi misteri

#52

Messaggio da mark3004 »

X Alessio: secondo me più che musica liquida qui si discute sull'aspetto tecnico della cosa, magari un titolo "collegamenti digitali per musica liquida su android o simili" o qualcosa di simile sarebbe più appropriato. ;)
Link tecnici "must read":
GUIDA CROSSOVER: viewtopic.php?f=5&t=15831
GUIDA GAIN: viewtopic.php?f=33&t=13215
BURN IN DRIVERS: viewtopic.php?f=33&t=15058
COMINCIARE SENZA BUTTARE SOLDI: viewtopic.php?f=20&t=14746
Avatar utente
ozama
Supertweeter
Messaggi: 11599
Iscritto il: 17 gen 2017, 18:10
Località: Copparo (Ferrara)

Re: Musica Liquida ed i suoi misteri

#53

Messaggio da ozama »

Ancora non hai capito dove voglio arrivare. XD

Parliamo del JITTER.
Il Jitter è una distorsione temporale che, all'atto della ricostruzione del segnale analogico, provoca una deformazione della forma d'onda.
È indagato da più di 20 anni, ormai. E, dalle varie prove, il suo effetto risulta udibile.
Se usi il clock della USB, spezzi i campioni audio, che ariveranno al ricevutore USB CON IL CLOCK DELLA USB ANZICHÈ CON IL CLOCK Originario:
TRASMISSIONE SINCRONA.
Nel caso di trasmissione USB generica, è inevitabile.
Le prestazioni del convertirore sono così assoggettate al clock USB. SE NON HA BUFFER ED UN RECKLOCKING LOCALE, la distorsione temporale dipenderà dalla pulizia dei dati in transito, oltre che dal clock della USB, che già di suo, è tutt'altro che pulito.
Perchè i pacchetti verranno ricomposti con una sequenza temporale ancora più imprecisa.
Se parliamo di dati che possono essere elaborati, subire cheksum eccetera, non ci sono problemi. Soprattutto se il canale è molto più veloce di quel che serve. Ma se parliamo di audio campionato, questo ha due aspetti di cui tenere conto: l'ampiezza ed il tempo. In funzione di ampiezza e tempo, dal campione si genera la tensione. Se il tempo è sballato, quel valore di tensione non sarà collocato nel punto giusto. Se osservi la ricostruzione di un tono con un oscilloscopio, se il tempo di campionamento non è corretto, la forma d'onda è distorta.
Insomma: più occupi spazio e giri di clock con altri dati, più metti in difficoltà il timing dello streaming. Anche quando "parrebbe ampiamente sufficiente".
È opinione comune quindi, che la USB debba essere lasciata in pace, quando trasmette audio.
Se parliamo di trasmissione ASINCRONA, quindi con i driver "che prendono possesso" del canale, poi, replico: mi risulta che questa sia semplicemente IMPOSSIBILE in presenza di altri dati. E che sia la più "ambita" in ambito Hi-Fi, qualora le periferiche la supportino.
Ma non è il caso della trasmissione OTG. Per cui, a maggior ragione, almeno meglio non mettere nulla tra usb e adattatore. O_O
Ripeto: non c'entra nulla "che si tratta di bit". Perchè se è una trasmissione di tipo broadcast (come lo streaming), quindi senza possibilità correzione di errori, perchè È IN TEMPO REALE, se ti perdi un pezzo, non lo ricostruisci. E se ti perdi un giro di clock perchè la USB stava trasportando altri dati, quel pezzo che doveva passare in quel momento li, lo hai perso. Bit o non bit.
È udibile? Non lo è? Perchè sperimentarlo se si può evitare facilmente? :hmm:
Ciao! :)
Sorgente: Pioneer DEH X8500 DAB modificata con sovra campionatore 24/48 ed uscita SPDIF ottica sotto controllo volume da Etabeta.
- DSP Helix DSP3s
- Amplificatore 6 canali Audison AF M6d:
2 canali su woofers Audio Development W60
2 canali su full range 2 pollici Audible Physics 220 CP
2 canali in bridge su sub Sonus by Nostromo & rs250v, in cassa chiusa.
Avatar utente
Alessio Giomi
Moderatore
Moderatore
Messaggi: 12592
Iscritto il: 23 mag 2012, 21:14
Località: Toscana Val di Cornia
Contatta:

Re: Musica Liquida ed i suoi misteri

#54

Messaggio da Alessio Giomi »

mark3004 ha scritto:X Alessio: secondo me più che musica liquida qui si discute sull'aspetto tecnico della cosa, magari un titolo "collegamenti digitali per musica liquida su android o simili" o qualcosa di simile sarebbe più appropriato. ;)
Ma infatti nel primo post di questa nuova discussione ho chiesta di suggerirmi il titolo :)
PIONEER SPH DA120 optical out
HELIX DSP.3
Zapco Z150C2VX ______Sw RE10D4
Zapco Z220II_________ Wf AD W60
Zapco Studio 150______ Mr
------------------------------------------------- > Xtant xis 2.4 by morel
Zapco Studio 100______ Tw

MY CAR KIA
MY OLD CAR
Avatar utente
Etabeta
sysadmin
sysadmin
Messaggi: 2673
Iscritto il: 13 apr 2018, 17:32
Località: Torino

Re: collegamenti digitali per musica liquida & Co

#55

Messaggio da Etabeta »

Inserisco qua una piccola parentesi sul tema pre-enfasi / de-enfasi che è spuntato in un altro thread, pen non andare fuori topic dall'altra parte.
ozama ha scritto:Ricordo un disco della Denon, che raccoglieva alcuni brani di colonne sonore, suonati da orchestra sinfonica..
Con il CD10 Philips veniva attuata la deenfasi e si sentiva molto cupo.
Con il lettore di un'amico, non ricordo la marca, non veniva attivata diveniva brillante (come doveva essere). Per fortuna è l'unico CD che ho avuto, con quel problema.. O_O
Ciao! :)
In effetti la Denon (come le altre etichette giapponesi nella primissima fase di commercializzazione dei cd) utilizzava la pre-enfasi, sia per i riversamenti da master analogici, sia per la transcodifica in pcm/44.1 delle registrazioni pcm del suo archivio risalente già alla fine degli anni 70'.
Però c'era il suo perchè: i primissimi conventitori A/D 16bit soffrivano di scarsa linearità (e quindi rumore di quantizzazione) ai bassi livelli sulle alte frequenze, per cui già a livello di standadizzazione del cd si pensò a prevedere un sistema di pre-enfasi (in masterizzazione) e de-enfasi (in riproduzione). La curva di esaltazione è piuttosto marcata e arriva a circa +10dB al limite dei 20KHz, tale sistema riduce il rumode di quantizzazione e la non linearità al prezzo di dover sacrificare 10dB di dinamica ovviamente.

Un cd pre-enfatizzato ascoltato attraverso un lettore o un dac che non gestisce la de-enfasi è diciamo "ultra-brillante" in certi casi fastidioso, in altri può all'ascolto apparire più gradevole ma comunque non è riprodotto in modo fedele all'originale, un pò come una cassetta registrata in dolby e riprodotta senza.
Qui in Europa, entrando in comercio il cd circa un anno dopo il Giappone, sono stati pochi i titoli prodotti con utilizzo di pre-enfasi (però alcuni di essi non sono più stati ri-editati e rimasterizzati per cui esistono solo in cd pre-enfatizzato, ancorchè essendo titoli molto datati sono introvabili nel mercato fisico ma recuperabili per altre vie, vabbeh...).

I primi lettori (diciamo fino a verso la fine anni '80) implementavano il filtro di de-enfasi tramite comune filtro R/C posto solitamente subito a valle del dac (come per il Philips CD10, che aveva anche il punto debole di avere un dac singolo alternato per i due canali, producendo il piuttosto noto problema di sfasamento), quindi la curva non era molto precisa,
sui lettori e dac ordierni (per essere conformi allo standard, anche se in effetti sono ben pochi gli utilizzatori di cd re-enfatizzati, a parte i collezionisti..) il filtro è realizzato nel dominio digitale, con precisione che arriva ai centesimi di dB.
Tutti i lettori cd conformi allo standard (non tutti lo sono però..) dotati di uscita spdif provvedono anche a settare a "vero" il flag di pre-enfasi nel flusso spdif (che lo prevede espressamente) quando lo riscontrano nella lattura di un cd quindi un dac che si rispetti riscontrando il flag deve provvedere alla de-enfasi.

Io nella mia collezione fisica di cd ho qualche pezzo, ma anche nella collezione liquida frutto anche di scambi/prestiti con amici.
Il "problema" della corretta gestione della pre/de enfasi è da tener presente quando si va ad archiviare o riascoltare un file audio rippato da un cd pre-enfatizzato, infatti nel caso di estrazione "bit-perfact" il flusso audio è archiviato così comè quindi pre-enfatizzato se così era sul cd originario. Va tenuto presente che in pratica nessun formato file audio prevede nativamente un "flag" che identifichi la presenza o meno di pre-enfasi quindi si possono adottare 2 soluzioni:
1) Una volta estratto l'audio (ovviamente in formato lossless, ma che velo dico a fare no...?) lo si archivia così comè e poi, quando lo si ripodurrà si dovrà attivare il filtro di de-enfasi (io uso foobar che tramite un plugin assolve egregiamente al tutto, dando anche la possibilità di inserire un apposito campo nei metadati, un flag on/appunto, per l'attivazione automatica)
2) Se si prevede di riprodurre il file in un player che non prevede la de-enfasi (praticamente tutti i player al di fuori del contesto pc) è basilare provvedere a ricodificare il file audio con una utility che provveda, nel dominio digitale ovviamente, tramite algoritmo dsp, a de-enfatizzare l'audio, io utilizzo Sox come utility a se stante ma anche foobar (si sarà mica capito che mi piace foobar?) permette molto semplicemente l'applicazione del filtro anche contemporaneamente alla transcodifica tra formati diversi.

Notare che utility di estrazione audio da cd come EAC o CUEripper prevedono la verifica del flag e in caso di pre-enfasi rilevata in una o più tracce provvedono ad marcarle nel file "cue" generato.

Per curisità, tornando ai Pink Floid queste le edizioni con pre-enfasi (ovviamente sono le prime in assoluto ad essere uscite in cd, in Giappone):
The Dark Side Of The Moon - Toshiba/EMI cod. catalogo CP35-3017, prima emissione Giappone 1983
The Final Cut - CBS/Sony cod. 35DP 53, prima emissione Giappone 1983
The Wall (2CD) CBS/Sony cod. 50DP 361-62, prima emissione Giappone 1985

E... per finire, nella mia schedina di interfaccia Pioneer (che ho descritto in un thread qualche tempo fa) ovviamente ( XD ) gestisce la de-enfasi (per la lettura da cd e da ingresso ottico aux) portando in uscita spdif l'audio già de-enfatizzato (operando internamente la de-enfasi in quanto praticamente nessun dsp car la gestisce, anche se penso non capiterà mai che mi porti in auto i miei cd-cimeli che custodisco gelosamente), in effetti é da quel progetto che mi sono divertito ad indagare nei meandri dello standard. :D
Allegati
pre-enfasi.jpg
Avatar utente
ozama
Supertweeter
Messaggi: 11599
Iscritto il: 17 gen 2017, 18:10
Località: Copparo (Ferrara)

Re: collegamenti digitali per musica liquida & Co

#56

Messaggio da ozama »

Azz.. Meno male.. La mia prima edizione di The Wall è questa:
7D9A336C-1121-4531-8ECA-C8027C9F7CD5.jpeg
Quindi non dovrebbe avere la deenfasi.
A parte che salta, perchè è una di quelle con l'inchiostro che rovinava lo strato inciso.
Infatti mi sono fatto prestare quella di un amico (che non ricordo di che anno è) e mi sono masterizzato i CD.. Tenendo comunque anche gli originali rovinati, naturalmente. -.-
Li ho poi rippati con iTunes, in formato waw, e non ci sono problemi. :yes:
Ciao! :)
Sorgente: Pioneer DEH X8500 DAB modificata con sovra campionatore 24/48 ed uscita SPDIF ottica sotto controllo volume da Etabeta.
- DSP Helix DSP3s
- Amplificatore 6 canali Audison AF M6d:
2 canali su woofers Audio Development W60
2 canali su full range 2 pollici Audible Physics 220 CP
2 canali in bridge su sub Sonus by Nostromo & rs250v, in cassa chiusa.
Rispondi

Torna a “Musica Liquida & Alta Risoluzione”