|
Musica liquida su USB: come e perché
|
|
Bloccato
|
|
In effetti, sarebbe meglio chiedersi prima perché: perché trasportare l’audio su USB? Non basterebbe utilizzare le uscite audio analogiche della scheda audio del proprio computer, oppure, avendo a disposizione un DAC nell’impianto hi-fi, l’uscita S/PDIF, elettrica o ottica, di cui molti PC sono dotati? Certo, tecnicamente la cosa funzionerebbe. Ma non si otterrebbe la qualità audio che i file musicali, specialmente quelli ad alta risoluzione, ci mettono potenzialmente a disposizione. Sui limiti qualitativi delle uscita audio analogiche di un PC credo ci sia poco da dire: a parte la scarsa qualità dei DAC e degli stadi analogici utilizzati nelle schede audio, infatti, si aggiungono i forti disturbi ed interferenze elettromagnetiche che i circuiti digitali del computer producono. Il segnale analogico in uscita da un PC è talmente sporco che difficilmente può essere considerato hi-fi. Si, ma quello dell’uscita digitale? Il segnale digitale dovrebbe essere immune ai disturbi, specialmente quello ottico, per cui usando l’uscita digitale avremmo risolto tutti i problemi legati alla sporcizia elettromagnetica prodotta dai circuiti digitali del PC.
Purtroppo, le cose non sono così semplici. A parte il fatto che anche un segnale digitale è sensibile ai disturbi elettromagnetici, altri fattori cospirano alla riduzione della qualità audio. Primo tra tutti è il jitter, cioè la variabilità della frequenza di presentazione dei campioni audio. La maggior parte delle schede audio dei computer, tranne alcune molto costose, sono affette da un jitter maggiore di quello di una normale meccanica CD. Inoltre, parecchie schede audio sono dotate della sola interfaccia ottica, che è ancora più sensibile al jitter di quella elettrica.
Dunque, tranne alcune costose eccezioni, l’uscita digitale della scheda audio di un PC o di un MacIntosh non è adatta a trasferire audio digitale con elevata qualità. E’ necessario dunque trovare un’altra via. PC e MacIntosh sono dotati di due interfacce a larga banda: l’USB e la IEEE1394, meglio nota come Firewire. Entrambe offrono una banda largamente maggiore di quella necessaria per il trasferimento anche del file più “ingombrante” (per esempio, l’USB 2.0 ha una banda massima teorica di 480Mbps, a fronte di poco più di 12Mbps necessari per il trasferimento di audio a 192kHz/32bit) e sono disponibili sia su PC desktop che su computer portatili. Delle due interfacce, in effetti la Firewire è la più adatta a trasferire flussi continui, ma paga lo scotto di una minore diffusione (specialmente su PC di minore costo e prestazioni) e di una maggiore difficoltà di gestione a livello software, oltre ad essere leggermente più costosa.
USB, interfaccia elettiva per l’audio?
Dunque, l’USB si rivela la migliore scelta per motivi sia tecnici che pratici. Tra l’altro, lo standard USB contiene un emendamento riservato alla trasmissione di audio. Ma come al solito, le cose non sono semplici come sembrano. Difatti, l’emendamento audio del protocollo USB, nato quando ancora esso era nella fase 1.1, prevede che la massima frequenza di campionamento trasferibile con un driver standard per PC (cioè quello che il sistema operativo carica automaticamente quando si collega ad una porta USB un dispositivo che si qualifichi come “periferica audio”) sia pari a 48kHz, con una risoluzione massima di 16 bit. Ultimamente, grazie all’uso di porte USB 2.0, di driver ASIO e altri accorgimenti, è stato possibile estendere l’uso dell’USB fino a 96kHz/24bit. Certo, non siamo ancora ai 192kHz, ma teoricamente abbiamo già superato le prestazioni di una meccanica CD.
Bene: prendiamo dunque un file musicale in formato 96/24 e, tramite una interfaccia USB in grado di gestirlo, riproduciamolo. Possiamo farlo perché l’interfaccia è parte di un DAC, oppure perché è a sua volta dotata di una uscita S/PDIF che colleghiamo ad un DAC capace di convertire segnali fino a 96kHz. La situazione è decisamente migliorata rispetto all’uscita digitale del PC, perché ora il segnale è meno soggetto ai disturbi generati internamente al computer e perché il jitter è più ridotto. Ma il miglioramento che ci aspettavamo non si è verificato. Perché?
Per rispondere a questa domanda, bisogna analizzare il percorso dei campioni audio dal file all’interfaccia. I campioni vengono prelevati in sequenza da una applicazione chiamata “player”. Esistono numerosi player, il più famoso in ambiente Windows è senz’altro Windows Media Player, in ambiente Mac è quasi onnipresente iTunes, ma sono diffusi anche Winamp, Monkey Media, FooBar. Alcuni di questi sono gratuiti, altri sono a pagamento. In una normale configurazione, il player sfrutta l’infrastruttura del sistema operativo per comunicare con la periferica audio. Il sistema operativo, cioè, si pone come tramite tra il player e la periferica. Questo permette al player di non doversi preoccupare delle caratteristiche funzionali della periferica: esso si limita a fornire al sistema operativo i campioni che poi vengono da questo passati alla periferica tramite il driver. Il sistema operativo delega il ruolo di mediazione ad un agente specializzato, cioè ad una applicazione residente fatta apposta per gestire segnali audio. Nel caso di Windows XP è il kernel mixer, cioè l’applicazione che mette a disposizione i vari controlli di volume, toni, bilanciamento, effetti sonori e così via. Nel MacIntosh c’è un’entità simile, il cosiddetto core audio.
Dunque, il player estrae i campioni dal file e li passa al kernel mixer o al core audio. Questo a sua volta li passa al driver della periferica che a ruota li consegna all’hardware. A questo punto, i campioni sono finalmente trasferiti al DAC, direttamente o tramite la connessione S/PDIF.
Se si va ad effettuare un confronto dei campioni trasmessi al chip di conversione o al canale S/PDIF, però, si scopre una cosa non molto piacevole: i campioni che arrivano all’utilizzatore sono diversi da quelli contenuti nel file. Che è accaduto?
Elaborazioni indesiderate
E’ accaduto che qualcuno li ha modificati strada facendo. Chi è il responsabile di queste modifiche non desiderate? Certo non è il player, il quale tutt’al più può attenuarli (o può anche fare altro, ma in genere le sue funzioni di elaborazione sono escludibili). Ma le differenze sono evidenti anche quando il comando di volume è al massimo o addirittura disattivato. Né si tratta del driver, perché esso è solo un tramite tra chi gli consegna i campioni e l’hardware della periferica audio (nel nostro caso, la periferica USB). Rimane il kernel mixer o il core audio. In effetti, queste due entità, questi “agenti” intermediari, spesso effettuano sui campioni modifiche di cui l’utente è all’oscuro. Non solo: alcune di queste modifiche non sono evitabili neanche se si fosse al corrente della loro esistenza. Per fare un esempio, il core audio del MacOS è stato scritto per funzionare in virgola mobile. I numeri su cui lavora, cioè, sono rappresentati secondo il formato in virgola mobile, ovvero floating point. Di per sé la cosa non creerebbe alcun problema, se non fosse per il fatto che i campioni memorizzati nei file sono in genere rappresentati come numeri interi, così come lo sono i campioni che l’interfaccia deve ricevere per inviarli al DAC. E’ facile comprendere che anche se il core audio non dovesse effettuare alcuna particolare elaborazione dei campioni, il solo fatto che essi transitino attraverso di esso comporta che debbano sottostare ad una doppia conversione intero-floating e floating-intero. Purtroppo, queste conversioni comportano approssimazioni ed arrotondamenti, operazioni che introducono rumore e distorsione nel flusso digitale. Il kernel mixer è ancora più subdolo: difatti, effettua spesso operazioni ben più gravi (quali riduzioni della lunghezza della parola, con eliminazione dei bit meno significativi) che degradano sensibilmente il suono. Tra l’altro, tutto questo lavorio sui campioni audio comporta un sensibile carico della CPU, che a sua volta può determinare momentanee sospensioni dell’invio dei campioni alla periferica, con conseguenti interruzioni della musica, “click”e “pop”. Beh, ma ci sono i driver ASIO… Si, i driver ASIO aiutano, sui PC, a risolvere parte di questi problemi, creando un specie di “ponte” tra player e driver della periferica, evitando quindi interferenze da parte del kernel mixer. Non evitano però il carico sulla CPU, perché si sostituiscono a tutti gli effetti al kernel mixer ma utilizzano comunque parecchie risorse del computer.
E’ dunque necessario ripensare completamente la modalità di trasferimento tra player e periferica, passando da un concetto di astrazione in cui né il player, né il driver sanno realmente chi è il loro interlocutore (modalità “direct sound”), ad una situazione in cui le due entità colloquiano direttamente tra loro senza intermediari (“kernel streaming”). La soluzione è tanto semplice concettualmente quanto complessa dal punto di vista della programmazione. E’ infatti necessario creare una “convenzione” ed una “piattaforma di scambio” attraverso le quali player e interfaccia si scambiano i dati. Un esempio di piattaforma di scambio sono i driver ASIO già citati, mentre la convenzione viene posta in essere con adeguate estensioni del player: ad esempio, la DLL offerta sul sito di FooBar o il plug-in realizzato da un privato per Winamp. E’ chiaro che i player che non hanno la fortuna di avere a disposizione la “convenzione” non potranno di per loro funzionare in kernel streaming, anche se esiste una versione di ASIO, chiamata ASIO4ALL (“ASIO per tutti”) che realizza anche l’interfaccia tra il player ed il canale kernel streaming. Ma che cos’è, in effetti, la comunicazione kernel streaming? E’ un meccanismo per cui player e periferica si “vedono” tramite un buffer di memoria: il player copia i dati nel buffer e la periferica li preleva. Peccato che per ottenere questo, ASIO faccia lavorare la CPU come una dannata. L’ideale sarebbe poter fare a meno di ASIO e artifici simili. L’unica soluzione è che sia il driver della periferica a gestire la transazione dei dati con il player. E’ necessario quindi realizzare un driver “ad hoc” per il funzionamento in kernel streaming.
Ci stiamo avvicinando al risultato che volevamo ottenere: siamo partiti da un dispositivo di interfaccia che lavorava in direct sound con driver standard fino a 48/16 e siamo già arrivati ad uno che lavora in kernel streaming con driver proprietario fino a 96/24, passando per uno che usava i driver ASIO. Non solo: per darci quei mediocri risultati, il primo dispositivo sfruttava gran parte della potenza di calcolo della CPU, con pericolo di interruzioni del flusso musicale dovute all’attivazione di altri processi, mentre ora abbiamo il solo driver al lavoro, con un carico decisamente inferiore a prima. Questo ci permette di utilizzare PC di potenza non esuberante, per esempio un netbook da poche centinaia di Euro.
Obiettivo: 192kHz
Ma non siamo mai soddisfatti: vogliamo poter ascoltare al meglio i file musicali campionati a 192kHz che , sempre più numerosi, sono disponibili su vari siti, tra cui quello della testata che state leggendo. Da progettista, la prima cosa che farei sarebbe quella di chiedere un supporto hardware ai miei fornitori, cioè un chip specifico di interfaccia USB audio simile ai vari PCM2904, TAS1020 e simili che sono utilizzati sulla stragrande maggioranza dei DAC dotati di ingresso USB attualmente in circolazione, DAC in genere in grado di elaborare dati a 192kHz e anche, spesso, di grande qualità audio e costo elevato. Qui cominciano i guai: non esiste attualmente nessuno di questi integrati in grado di lavorare a 192kHz. Che fare?
Ovvio: è necessario realizzare un’interfaccia proprietaria in grado di gestire il flusso audio a 192/24. In effetti, il lavoro è già stato fatto per metà, perché abbiamo già realizzato un driver proprietario, siamo quindi virtualmente svincolati da qualunque specifico hardware. Fortunatamente, il mercato dei semiconduttori mette a disposizione alcuni chip di interfaccia USB 2.0 generici che, opportunamente utilizzati, si prestano alla funzione specifica. E’ sufficiente, a questo punto, realizzare una logica di collegamento tra l’interfaccia ed il trasmettitore S/PDIF o il DAC ed gioco è fatto. Sembra una cosa semplice ma non lo è, almeno a giudicare dal fatto che ben poche aziende hanno finora seguito questo percorso.
Bene. Siamo arrivati alla piattaforma hardware/driver ideale: un’interfaccia proprietaria con un driver proprietario che permettono il trasferimento di dati a 192kHz/24bit senza alterazioni e con basso carico della CPU. Siamo a posto? Forse no…
Ancora il jitter!
Già: il DAC o il trasmettitore S/PDIF devono ricevere un master clock per funzionare. Da dove prenderlo? Le alternative sono fondamentalmente due: sfruttare il clock già presente sull’interfaccia o usare un oscillatore di riferimento. La prima soluzione richiede l’uso di un PLL, un circuito in grado di ricavare il clock che ci serve a partire da un altro clock, in genere quello del chip di interfaccia. Peccato che il PLL soffra di due limiti che influenzano negativamente le prestazioni dell’interfaccia: la scarsa precisione (a meno di non usare prodotti di elevato costo) e l’instabilità della frequenza generata, legata alla banda del filtro del PLL: una banda stretta produce meno jitter ma rende più sensibile il PLL alle fluttuazioni della frequenza di riferimento, per cui il circuito può, al limite, “sganciarsi” dal riferimento. Una banda più ampia, d’altra parte, rende più sicura la generazione del clock ma lo “sporca” con maggiore jitter. Torniamo sul discorso della precisione: il PLL può essere assolutamente esatto se la frequenza da generare è un multiplo di quella di riferimento. Purtroppo, dato che a noi servono due distinti master clock (uno per le frequenze di 44.1kHz e multiple, un altro per le frequenze di 48kHz e multiple), solo uno di questi due sarà esatto: l’altro mostrerà una certa differenza rispetto al valore nominale desiderato. Per esempio, a fronte dei 48kHz potremmo avere 48,025kHz.
Dunque, un’interfaccia che usi un PLL esibirà jitter elevato e scarsa precisione delle frequenze di riferimento. Attenzione: la precisione delle frequenze può sembrare un requisito di importanza minore rispetto al jitter (dopotutto, anche se il La centrale non è proprio a 440Hz, la musica è bella lo stesso), ma provate ad agganciare un flusso digitale con un DAC Weiss o dCS se l’errore della frequenza è maggiore di 30ppm (parti per milione), poi ne riparliamo.
In un’ottica purista, dunque, l’unica soluzione è quella di utilizzare due oscillatori al quarzo di precisione e a basso rumore di fase (responsabile del jitter).
Ormai ci siamo: abbiamo un dispositivo che trasferisce audio a 192/24 in kernel streaming (o comunque saltando il core audio se si usa un Mac) senza alterazioni, con elevata precisione e basso jitter, imponendo un carico leggero alla CPU: siamo allo stato dell’arte. Bene, siamo pronti: prendiamo la nostra interfaccia, la colleghiamo con un buon cavo S/PDIF al nostro DAC (oppure essa è già all’interno del DAC) e poi la colleghiamo al PC con un bel cavo-prolunga USB. Anzi: per maggiore comodità il cavo lo prendiamo bello lungo, così possiamo poggiare il PC sul tavolino da fumo del nostro salotto mentre ascoltiamo l’impianto. Ma perché improvvisamente la musica si interrompe continuamente? Eppure, per quanto appena detto, la CPU non sta praticamente lavorando e la porta è USB 2.0… Già, ma c’è un fatto non trascurabile: la banda dell’USB si degrada in funzione della lunghezza e della qualità del cavo usato. Meglio quindi accorciare alla minima lunghezza indispensabile il cavo, oppure eliminarlo del tutto, dotando l’interfaccia di un connettore maschio di tipo A invece che del tipico connettore femmina tipo B comune alle periferiche USB. In questo modo, l’interfaccia potrà essere addirittura inserita direttamente nella porta USB del PC, eliminando qualsiasi problema legato al cavo.
Siamo arrivati praticamente alla fine del percorso di sviluppo tecnico di una interfaccia USB-S/PDIF (o USB-I2S, nel caso di un’interfaccia interna ad un DAC). Che altro si può fare? Curare i dettagli, come l’alimentazione degli oscillatori (vedere l’incorniciato sull’alimentazione dell’USB) o la qualità dei connettori. Propongo ai lettori di effettuare una ricerca sulla rete per scoprire quante interfacce attualmente sono realizzate soddisfacendo tutti i requisiti che sono emersi durante la presente disamina. Marco Manunta, M2Tech
Misurare il jitter
Gli appassionati tecnicamente più esperti sanno che è possibile misurare il jitter di un convertitore usando la scheda audio del proprio PC collegata all’uscita del DAC e appositi software scaricabili gratuitamente da Internet. Numerose misure effettuate da più persone portano a numeri affascinanti: jitter di 120/170ps (picosecondi: un picosecondo è un secondo diviso 1.000.000.000.000!). Ha senso questo tipo di misura? Si e no: si, se si sa cosa significa, no se viene assimilata senza alcuna consapevolezza del suo significato. Già: come è possibile che il jitter misurato con il metodo sopra citato porta a risultati eclatanti, mentre una misura del jitter effettuata direttamente sulla linea S/PDIF con uno strumento professionale difficilmente restituisce risultati inferiori a 1.000ps?
Il fatto è che quando si misura il jitter analizzando l’uscita analogica di un DAC, non si sta misurando il jitter della connessione S/PDIF, ma quello dell’intera catena costituita da trasmettitore S/PDIF, cavo, ricevitore S/PDIF e DAC. Bene, ma come è possibile che l’intera catena esibisca una prestazione migliore di quella di una sua singola parte? La risposta è: reiezione al jitter. I ricevitori S/PDIF hanno un circuito di ricostruzione del master clock a partire dal flusso S/PDIF che è capace di attenuare il jitter di 20/30dB. Vuol dire che il master clock ricostruito dal ricevitore (e usato per temporizzate il DAC) è affetto da un jitter teoricamente 10/30 volte più ridotto di quello della linea. Ecco spiegato perché a fronte di un jitter di linea di 1.000ps è possibile avere jitter all’uscita analogica di 120/200ps. L’importante è non confondere le due misure. Prove effettuate con alcuni dispositivi in un laboratorio specializzato hanno mostrato che i dispositivi professionali più validi esibiscono un jitter di linea attorno a 1.000ps, mentre apparecchi consumer salgono ben oltre i 1.500ps.
Una raccomandazione: il metodo che misura il jitter all’uscita del DAC si basa sulla presenza di spurie in un segnale di riferimento. Il problema è: chi ha generato le spurie? E’ il jitter? E’ l’alimentazione del DAC? E’ il chip di conversione stesso? Nell’impossibilità di rispondere a queste domande, la misura del jitter all’uscita del DAC ha scarso significato, a meno di non usare un DAC come riferimento per valutare svariate interfacce, arrivando comunque a risultati relativi (il dispositivo A è migliore di quello B).
L’alimentazione della porta USB e la stabilità del clock
Come molti sanno, la porta USB dei PC e dei Mac offre un’alimentazione a 5V per i dispositivi ad essa collegati. Molto si è dibattuto sulla qualità di questa alimentazione e sull’opportunità di usarla per alimentare i delicati circuiti di generazione del clock, piuttosto che dotare il dispositivo periferico di un’alimentazione esterna. A parte questioni di costo, ha senso considerare quanto affermato da più di un valente progettista: non è l’alimentazione dell’USB in sé a determinare l’elevata o la bassa qualità dell’alimentazione degli oscillatori e quindi la precisione e la stabilità dei clock. E’ piuttosto il modo in cui essa viene usata. Se si alimenta tutto il circuito dell’interfaccia usando direttamente i 5V della porta, probabilmente l’alimentazione sarà sporca e quindi gli oscillatori esibiranno un elevato jitter. Ma se l’alimentazione viene filtrata e post-regolata, è possibile ottenere un’alimentazione pulita ed efficace anche dalla porta USB. D’altra parte, realizzare una connessione verso un alimentatore esterno e poi usare un economico alimentatorino switching da muro, può portare a risultati ben peggiori di quelli raggiunti con l’alimentazione della porta USB correttamente utilizzata. Marco Manunta, M2Tech
Prezzo: 99 Euro IVA incluso
L’acquisto di hiFace è solo tramite Audiophile Sound:
- www.audiofileshop.com (pagamento Paypal)
- Ufficio (bonifico, assegno, conto corrente postale): 0571-658591 (9.00-13.00)
|
audioforum
Veterano
webmaster@audiophilesound.it
20 Dic 2009, 1:59 PM
Messaggio n°1 di 1
(letto 26285 volte)
Link
|
INDICE
RICERCA
CHI C'E'
LOG