Il Software provoca Jitter
Introduzione
Il jitter è un argomento complesso, ma per fortuna è ben definito in termini matematici che ci permettono di analizzare, misurare e ridurre gli effetti sgradevoli. Sia DAC che ADC soffrono di distorsione jitter. Questo vale solo per l'audio digitale, l'audio analogico non ha jitter (ma non è priva dall'avere buone interconnessioni, EMI, ecc.)
Per cominciare si sa che c'è un punto ben definito in cui la distorsione jitter cresce. Questo si trova in profondità all'interno del chip DAC dove il master clock regola ogni punto campione (sia per il canale sinistro che destro) alla sua "giusta posizione" del voltaggio di uscita analogica. Purtroppo, questa posizione "giusta" è sempre fluttuante nel tempo causando variazioni analogiche di tensione nel tempo (sia prima che dopo). Questa è la distorsione jitter. La sua corretta misurazione può essere determinata solo alle uscite analogiche.
Misurazioni del jitter effettuate sull'input del clock DAC, utilizzando ad esempio l'analizzatore Wavecrest, è fuorviante. Anche se questa misura è corretta e importante per fornire informazioni sul jitter del clock, non corrisponde alla distorsione jitter come definita. Ciò che viene misurato è il jitter del clock come entra nel chip DAC. Ma questo non è il posto dove si forma il segnale che da' luogo ai reali cambiamenti analogici di tensione, invece – come affermato in precedenza – questo avviene in profondità all'interno del chip DAC. Questo aspetto ha un peso importante sul livello di distorsione jitter realmente 'vissuta' da un ascoltatore.
I chip DAC sono complessi circuiti integrati in cui il segnale di clock apparentemente puro che entra subisce un danno (ad esempio il rumore di fondo). La qualità dei restanti segnali di ingresso DAC (altri clock, il controllo e i dati) sono fonti di inquinamento acustico che influenzano in modo significativo il jitter. Lo stesso chip consuma, esegue calcoli e ha altre complicazioni, tipo il buffer, che contribuiscono a loro volta al jitter. Quindi una misurazione valida della distorsione jitter deve essere effettuata solo sulle uscite analogiche del DAC.
È anche importante porsi la domanda: quanta distorsione jitter è udibile? I livelli di jitter in riproduzione devono essere inferiori a 8.5ps (Jpp RSS, partendo da nessun jitter in registrazione!) per essere impercettibili (se l'udito umano è capace di 22 bit di risoluzione). Un compito particolarmente complesso.
Alcuni venditori progettano computer audio partendo dal presupposto che in entrata il bitstream audio proveniente dal computer è altamente 'jitterato' e rumoroso. Allora, la soluzione che applicano coinvolge il reclocking dei dati. Tali progetti tentano di creare un "firewall" contro i dati in entrata jitterati ma ha un inconveniente: i livelli di jitter sono quelli del dispositivo in uso (cioè il suo jitter intrinseco) e qualsiasi audio di qualità superiore al flusso di bit trasmesso è in gran parte sprecato.
La catena audio
Il dominio del jitter termina all'uscita analogica dentro al chip DAC. Allo stesso modo, la distorsione jitter durante la registrazione si conclude all'interno del chip ADC. Cioè, durante la registrazione nessuna ulteriore distorsione jitter è aggiunta dopo che il segnale analogico viene digitalizzato. L'elaborazione audio applicata a questi dati digitali (ad esempio il dithering o il guadagno) influisce sulla qualità del suono, ma tale trattamento non aggiunge jitter (sempre che si rimanga nel dominio digitale).
I trattamenti che agiscono per ridurre il jitter in riproduzione si applicano pienamente anche alla registrazione e viceversa. Alimentazione pulita, assenza di vibrazioni, temperatura costante, ecc. – tutto conta. Il software (il Sistema Operativo e il il lettore/registratore) induce jitter. In questa discussione non parliamo di dati audio deliberatamente cambiati dal software (intenzionalmente o no) che influenzano la qualità del suono. Il problema qui è il motivo per cui esattamente gli stessi dati audio presentati al DAC (cioè Bit Perfect) e provenienti dalla stessa posizione, ma in streaming attraverso software e sistemi operativi diversi (ad esempio Windows) possono portare a differenze di suono.
Prima di approfondire gli effetti del software sul jitter, è importante esplorare il valore della catena audio. L'argomento di fondo cui sopra riguarda i dispositivi che agiscono per proteggere il DAC dalla distorsione jitter in arrivo. L'accoppiamento a trasformatore, il buffering e il reclocking vengono comunemente eseguiti con i dati audio provenienti da USB. Tali progetti danno risultati buoni, ma hanno un tetto massimo di prestazioni, cioè il loro jitter intrinseco. Qualsiasi segnale migliore (con jitter inferiore) inviato ad essi avrà benefici minori. Di conseguenza, "non sento differenze quando si apportano modifiche al mio PC", è il commento comune da parte dei proprietari di tali dispositivi.
Una tipica alternativa è la riproduzione di audio da un disco rigido usando una normale scheda audio. Streaming al DAC (tramite scheda audio collegata da PCI, PCIe, Firewire o USB) effettua il seguente percorso:
HDD (SATA/IDE/RAID)> Chipset> RAM> CPU (software)> RAM> Chipset> Scheda audio (clock)> DAC
La riproduzione su network offre:
Ethernet> Chipset> RAM> CPU (software + netware)> RAM> Chipset> Scheda audio (clock)> DAC
Entrambi i metodi di riproduzione da HDD e da Network tendono ad “ostacolare” lo streaming di dati audio: mentre la scheda audio recupera i dati audio, il software di riproduzione legge contemporaneamente i dati audio successivi utilizzando le stesse risorse (RAM e chipset). La riproduzione da Network comporta ulteriori overheads a livello di software SO (netware) e di perifieriche/componenti.
Il vantaggio di un RAM player è di evitare questo conflitto di risorse e overheads:
RAM> CPU (software)> RAM> Chipset> Scheda audio (clock)> DAC
Inoltre, offre anche una catena di riproduzione più breve con un minor numero di dispositivi e software associati. Questo disegno è ottimale e si presta ad una diretta interfaccia I2S con il DAC chip a 192k evitando Firewire/USB, S/PDIF o AES. È anche la piattaforma più rivelatrice di modifiche software.
Un PC headless è applicabile a tutte le opzioni e tende a rimuovere il video/display, la tastiera e il mouse dal PC in streaming.
Comprendere il Software
La CPU (Central Processing Unit) è la parte più complessa dell'equazione e la sua ottimizzazione ha profonde ripercussioni sul suono. Il "CPU (software)" nel contesto di cui sopra include il FSB e il controller di memoria che gestisce i RAM I/O. La produzione di calore è un altro indicatore di configurazioni insufficenti che richiedono un raffreddamento tramite ventola. Overclockers utilizzano costose soluzioni per il raffreddamento. Super-computer utilizzano elio liquido o azoto per il raffreddamento. Il Sacro Graal del computing è la super conduttività ad alta temperatura.
Il Software (tramite le istruzioni) controlla quello che fa la CPU, dettando quindi la quantità di energia, l'arbitrato delle risorse, la gestione degli errori e la segnalazione (comprese le complessità di riflessione del segnale) necessari. Moderne CPU tipo Intel Core Duo contengono oltre 100 componenti discreti, ad esempio, L1 (dati e istruzioni) Cache e L2 Cache condivisa. Ci sono componenti meno noti tipo i GPR (general purpose registers fino a 16 per core), i Registri di controllo, le Unità di esecuzione, la Loop Cache, altri componenti di front-end (instruction prefetcher, decoder, ecc.) e TLB (translation lookaside buffers).
A livello fisico ogni istruzione software viene decodificata in uno o più μops (micro-ops), che vengono compresi ed elaborati tramite le unità di esecuzione specializzate. Ogni ciclo di clock è in grado di completare 3-4 μops contemporaneamente (cioè un singolo core agisce come 3-4 core). Istruzioni aggressive di pipelining vengono eseguite assieme ad un esecuzione fuori ordine e a macro-fusion (combinando μops) per raggiungere livelli incredibili di prestazioni e di molteplicità. Il Software in esecuzione deve essere visto come un circuito elettrico dinamico in continua evoluzione.
L'atto di lanciare un programma (ad esempio, fare doppio clic su un'icona del desktop) significa che il sistema operativo (Linux, Windows, Mac, ecc.) carica il programma in RAM, crea una nuova attività di processo (thread) e l'aggiunge alla "lista di smistamento" (dispatcher list) della CPU. Questo smistamento assegna una quantità fissa di tempo di CPU a cicli ad ogni thread attivo del sistema. L'elaborazione degli interrupt ha la priorità più alta (chiamata DPC), seguita da thread raggruppati in classi di priorità. Il programma richiesto alla fine riceve dalla CPU "la messa in onda" ed è in grado di svolgere il compito previsto, ad esempio l'utente lancia un comando per la riproduzione di un file multimediale.
Data la complessa architettura, ha senso garantire che una soluzione ottimale per la riproduzione abbia:
- la minore quantità possibile di thread attivi (si riducono così le overheads del Dispatcher e si garantisce meno concorrenza per l'uso di CPU e RAM);
- la massima RAM disponibile (si evita il paging su disco fisso e la frammentazione e si massimizza la quantità di dati audio che può essere caricata in RAM);
- la minore quantità di intrusione da parte delle perifieriche attraverso una riduzione dei processi degli interrupt e della gestione del software associato. Inoltre, le perifieriche sono esse stesse inquinanti e devono essere rimosse se non necessarie.
Questo tipo di ottimizzazione è denominato "ridurre l'impronta di runtime del Sistema Operativo". Se non lo si controlla, questo crea un ambiente ostile che ha un impatto diretto sul jitter. Si può vedere questo considerando un programma di riproduzione audio in funzione che viene interrotto casualmente a causa di altri thread attivi e/o interrupt di periferiche. Ancora peggio, quando il dispatcher della CPU imposta il programma su diversi core della CPU causando “errori” della L1 cache e “incidenti" indesiderati. Tali attività indesiderate causano rumore supplementare nell'alimentazione, rumore di fondo e overheads di segnale con un impatto diretto sui dati audio in streaming alla scheda audio. Ciò influisce sulla stabilità dell'oscillatore (XO), e quindi jitter. Nel complesso la qualità del segnale in uscita verso il DAC si deteriora. Viceversa, un ambiente “amichevole” tende a creare un circuito ultra low-stress in cui l'XO offre le proprie prestazioni jitter free all'interno del chip DAC.
Player Audio
Avere un ambiente ottimale crea una piattaforma ideale per rivelare l'impatto di un player audio sul suono. Sì, le differenze sonore sono significative e sono facilmente osservabili. Ogni player è asservito al clock (XO) della scheda audio. Cioè, lo streaming di dati è un evento regolare e l'XO determina esattamente quando c'è bisogno di ricaricare il buffer audio. Quindi abbiamo una dipendenza critica di temporizzazione. Viene stabilito un rapporto di jitter periodico (vedi l'analisi di sensibilità sotto).
La riproduzione audio a livello di CPU è una sequenza di istruzioni del software in funzione. A livello fisico, queste istruzioni vengono eseguite a un ritmo enorme che si traduce in un circuito elettrico dinamico. Mentre è facile vedere un circuito progettato male e le sue conseguenze, non lo è altrettanto per il software. Un software mal progettato causa un eccessivo RAM I/O, sbalzi tra core diversi a livello di cache L1, rallentamenti eccessivi (e costosi) della pipeline, perdita della cache e una generale inefficienza (spesso un risultato forzato a causa di un'eccessiva flessibilità). Tali progetti scarsi aggiungono distorsione jitter attraverso le interferenze elettriche che destabilizzano il clock (XO) e riducono la qualità del segnale dovuto all'aggiunta di rumore di corrente e di fondo, a brutti picchi di corrente, a un eccessivo stress del segnale e a variazioni temporali. Ad esempio, consideriamo un player audio che provoca eccessivi rallentamenti nella pipeline. Questo significa che la pipeline della CPU viene esaurita per crearne una nuova. Il risultato è un picco di corrente che ha impatto sul clock (XO).
Dato che la CPU è una componente cruciale dell'equazione audio ed è controllata direttamente dal sistema operativo e dal lettore, la sua utilizzazione ottimale è essenziale per ottenere le migliori prestazioni. Il software, se visto come un circuito elettrico dinamico, ha notevoli implicazioni sull'utilizzo delle risorse e le sue conseguenze. Ridurre lo stress della CPU tramite il software è un'arte. Ci sono molte strade per raggiungere questo scopo e richiede una profonda comprensione della CPU. Ogni player scatena un circuito diverso che genera differenze nel suono dovute al jitter. Quindi le differenze nel suono si verificano anche quando i bit presentati al DAC sono esattamente gli stessi. Questo non è un nuovo fenomeno scientifico - è fisica ormai accettata al lavoro.
Jitter Periodico - analisi di sensibilità
Le modifiche sono facilmente osservabili ad ogni nuova versione di cPlay. Il perché variazioni così sottili abbiano un impatto sulla qualità del suono è spiegato qui. Applicando la Teoria del Jitter (Periodico) per una vasta gamma di Jpp utilizzando una scansione di frequenza nella gamma udibile e oltre si ottiene:
Le implicazioni pratiche sono notevoli in quanto la Distorsione Jitter provoca danni alla qualità del suono:
- La distorsione sulla sideband aumenta rapidamente con la frequenza di ingresso, vale a dire i suoni ad alta frequenza sono i più colpiti. Questo si nota dal rapido aumento della distorsione al crescere della frequenza. In questa banda di HF (che va ai tweeter) informazioni essenziali sulle armoniche del suono sono distorte. Ci sono effetti negativi come velature, transienti lenti e un decadimento tonale falsato.
- È essenziale comprendere la misura in cui Jpp deve essere ridotto.
- Vediamo che per un Jpp alto (150...350ps e oltre) un progettista audio non è ben ricompensato per gli sforzi di riduzione del jitter, cioè, nonostante un calo Jpp su vasta scala, i livelli di distorsione rimangono alti. DAC moderni (comprese alcune schede audio) hanno un ottimo livello di rumore anche oltre i 118dB. Ciò implica che la distorsione jitter derivante da input ad alta frequenza (sopra 5kHz) sarà decisamente superiore al rumore di fondo. Ad esempio, un tono di ingresso di 10 kHz e con 150ps Jpp produrrebbe distorsioni sulla sideband di -112.6dbFS. Ahi!
È interessante notare che questo spiega perché alcuni utenti inaspettatamente esprimono il proprio disappunto davanti ad un front-end con una performance di ~200ps Jpp. In poche parole, il rumore di fondo è inquinato da un'eccessiva distorsione della banda laterale.
Questo potrebbe anche spiegare perché alcuni produttori sono rimasti delusi dal Jitter e hanno abbandonato il suo ruolo come una delle principali fonti di distorsione acustica. Purtroppo, altri devono ancora capire come misurare tale distorsione (che può essere fatto in modo corretto soltanto sulle uscite analogiche).
- Le implicazioni per sistemi con oltre 150ps Jpp suggeriscono che i miglioramenti della qualità del suono non saranno facilmente ottenibili. Forse questo spiega perché alcuni obbiettano che la quantità di RAM, la qualità e le impostazioni possano avere un impatto sonoro sulla qualità.
- Con nostro grande sollievo, la distorsione scende rapidamente sotto i 150ps Jpp. Come si può vedere, per ogni “scatto” di 50ps, la distorsione si riduce ulteriormente. Cioè, vediamo un decadimento esponenziale della distorsione. Si consideri per esempio 50ps Jpp, qui tutti i miglioramenti portano dei benefici maggiori che non con gli stessi miglioramenti ad un più alto Jpp. Questo suggerisce che una configurazione di alta qualità come un cMP completo (la cui performance del jitter misurata è 51ps Jpp RSS usando foobar) sarebbe sensibilmente migliore a rivelare i...miglioramenti.
- Nel caso ideale, i risultati di jitter comportano una distorsione delle sideband per tutte le frequenze di ingresso al di sotto della soglia di rumore del DAC. Un rumore di fondo di -130dbFS, richiede un jitter inferiore a 10ps Jpp.
Questa analisi di sensibilità ha importanti implicazioni per filtri a fase minima o non-lineare. Il suo utilizzo evidenzia scarse prestazioni di jitter nel DAC - vedere il Dilemma della Fase Minima.
Raramente la teoria e la pratica si incontrano così bene. Gli sforzi di Julian Dunn che ha posto le basi per la comprensione del Jitter e le sue sfide sono stati davvero notevoli.
Conclusione
Mentre tutti gli altri componenti della catena ricevono il trattamento ottimale perché non dovrebbe la CPU? Non ottimizzare la CPU è decisamente stupido. Si raggiunge un buon miglioramento anche moderando il consumo eccessivo della CPU (con riduzione EMI) attraverso under-volting e under-clocking (che riduce anche RFI). La sua ottimizzazione, tuttavia, non finisce qui. Il software non è senza conseguenze - ignoratelo a vostro rischio e pericolo.
Le migliori prestazioni si ottengono quando le nozioni classiche di DAC come "Master" o "Slave" sono sostituite con il principio progettuale di creare una partnership in cui entrambi il DAC chip e il PC Transport sono asserviti al clock (XO). Il jitter è domato quando la nostra "stringa" è più corta e l'audio viene trasmesso in condizioni di stress minimo.
Il Software provoca Jitter
