cMP²: Come utilizzare cPlay
http://www.nexthardware.com/forum/me...mplogotiny.jpgCome utilizzare cPlay
Eseguire cPlay
Quando si esegue cPlay (doppio clic sull'icona del desktop) per la prima volta, deve essere eseguita l'installazione.
Riproduzione audio con priorità RealTime:
- Selezionare un file cue (playlist), wav o flac dal File Explorer
- Selezionare 'Apri con' (fare clic destro sul file da riprodurre)
- Individuare e selezionare 'cicsPlay.bat', dove è stato installato cPlay (default è 'c:\program files\cics Play'). Nota: se non è stata utilizzata la cartella di installazione predefinita, modificare cicsPlay.bat e correggere il percorso. Suggerimento: utilizzare il comando 'dir *.* / x' per identificare il nome della cartella DOS.
Si raccomanda l'utilizzo di file cue che consentono la riproduzione di playlist.
Impostazioni
Il pulsante in basso a sinistra nella schermata principale conduce a 'cPlay Settings'. Il pulsante ASIO Settings dipende dal driver ASIO – su Juli@ non ha alcun effetto, mentre su RME, Lynx, EMU e ASIO4ALL dà accesso al pannello di controllo del driveri ASIO. cPlay gestisce solo il segnale a 2 canali (questa è una scelta progettuale).
http://www.cicsmemoryplayer.com/uplo...aySettings.png
Affinché alcune modifiche abbiano effetto (ASIO, Buffer, AWE e Output Rate), è necessario un riavvio. Le modifiche ASIO (da cPlay o esterne) causano lo stop di cPlay (è necessario un riavvio). Si tratta di un'importante misura di sicurezza.
Quando si cambia frequenza (ad esempio, 96-44,1), alcune schede audio ASIO possono rimappare i canali - cPlay prova a rilevare questo cambiamento (a seconda del driver ASIO) ed eventualmente informare di reimpostare i canali sinistro e destro. Perché? Alcune schede audio con l'interfaccia ADAT utilizzano il multiplexing dei canali (cioè 96k dà 2x48k), per cui i canali cambiano con la frequenza.
L'impostazione cMP disabilita il pulsante di ricerca dei file (per evitare attese a tempo indeterminato in cMP²).
Buffer
Viene fornito "DSP buffer" in automatico (default), Small, Medium o Large.
Guida: con CPU di 2MB+ L2 cache, impostare su Auto. Small è l'ideale per frequenze di uscita molto elevate (oltre 96k) mentre Medium è meglio per 96k o inferiore. Su CPU che offrono meno di 2MB di L2 cache, Small è consigliato per tutte le frequenze di uscita. L'impostazione 'Large' del buffer è utilizzata da Auto quando la frequenza di uscita è 48k o meno. Per processori con dimensione della L2 cache più grande di 2MB vale la pena provare le impostazioni Medium e Large (per qualsiasi frequenza di uscita).
L'opzione del buffer "Tiny" ha il 'peso' minore sulla L2/L3 cache permettendo di usare per il ricampionamento anche CPU meno potenti. Il requisito di 2MB di cache L2/L3 rimane per produrre un output di alta qualità a 192k. Auto utilizza solo Small, Medium o Large, mentre l'opzione Tiny deve essere selezionata manualmente. Tiny è altamente raccomandato quando si utilizza un plugin VST.
Queste dimensioni del buffer funzionano al meglio con ASIO impostato su bassa latenza (meno di 512 campioni).
Perché le dimensioni del buffer sono importanti?
Il buffer influenza il consumo di risorse CPU e RAM. Questo a sua volta influenza l'alimentazione e il piano della massa. Un altro fattore chiave è quanto spesso il DSP è utilizzato per riempire i buffer. Si tratta di una transazione periodica e provoca quindi jitter periodico. Ciò si presenta in ogni player. Buffer più grandi richiedono più CPU (specialmente con SRC a 145dB). Quando si utilizza cMP, i buffer più grandi causano una risposta più lenta dell'interfaccia utente. Ad esempio, con buffer più grandi il mouse diventa "lento" o "pigro". Questo è parte integrante del progetto cMP² con Optimize impostato su "Critical". Provare a impostare Optimize (in cMP) su "Player" o "Realtime" e potrete sperimentare risultati diversi.
Spiegazione: quando si sposta il mouse, si richiede l'intervento della CPU, ma con un grande carico DSP c'è un ritardo in quanto in cMP il DSP gode di priorità in tempo reale. Quando Optimize non è impostato su "Critical", l'azione del mouse è servita immediatamente dagli altri core liberi della CPU (quando si utilizza una CPU dual core). Questo interferisce purtroppo con il nostro thread ASIO che è fondamentale: un design ottimale ha un core della CPU dedicato a questo compito che non solo elude, ma è superiore ad avere un SO con kernel realtime.
Pertanto, differenti dimensioni del buffer inducono (via software) a distorsione diverse di jitter (sia in ampiezza che in frequenza) che causano differenze udibili.
SRC a 145.68db SNR
cPlay è in grado di utilizzare l'upsampler SNR 145.68db che richiede impegno della CPU. Una parola di cautela: non tentare di utilizzare questo upsampler su processori poco potenti (non al di sotto di E4xxx processore Core 2 Duo). Un minimo di 2MB di L2 cache è necessario. Ad esempio, l'E2140 (1MB di cache L2) e Pentium 4 a 3 GHz (1MB L2 cache) possono raggiungere solo 44.1-> 96 - oltre questo si ottiene un blocco/lentezza del computer. Esiste il rovescio della medaglia: potenza maggiore della CPU equivale a più interferenze elettriche (e maggior consumo di corrente), riducendo così i benefici di upsampling superiore.
Il processore E6300 (2MB L2 cache, 1.86GHz) affronta comodamente un sovracampionamento a 192k con il carico della CPU a ~ 40% (CPU core singolo). Un cMP² con questa impostazione funziona senza ventola CPU e dà temperature della CPU di ~ 43°C. In cMP², non si verificano dropouts quando Optimize è impostato su Critical. Il nuovo Intel i3 530 (basato su tecnologia a 32 nm) è una scelta eccellente che offre bassi consumi e ottime prestazioni.
Impostazioni del resampler SoX
L'implementazione di SoX in cPlay gode di totale ottimizzazione come quella di SRC (Secret Rabbit Code). Questo include elaborazione del DSP a 128bit e altre ottimizzazioni. Solo i convertitori VHQ (Very High Quality, 175db rejection cioè Stop Band) e HQ (High Quality, 125dB rejection) sono supportati. SRC a 145dB SNR (145db rejection) e 121db SNR (120dB rejection) rimane uguale. SoX VHQ offre migliori prestazioni di SNR a 170db. In cPlay sono disponibili altre opzioni di ricampionamento SoX (come da manuale SoX):
- Phase (0-100)
Tutti i resamplers utilizzano filtri che a volte possono creare artefatti 'eco' (cioè 'ringing') con segnali transienti, come quelli che si verificano con lo `schiocco delle dita' o altri suoni altamente percussivi. Tali artefatti sono molto più evidenti per l'orecchio umano se si verificano prima del transiente (`pre-echo') che non se si verificano dopo (`post-echo'). Si noti che la frequenza di tali artefatti è legata alla grandezza dell'originale e alla nuova frequenza di campionamento, ma che se questa è di almeno 44,1 kHz, allora gli artefatti si trovano al di fuori della gamma udibile umana.
Una impostazione della risposta di fase può essere utilizzata per controllare la distribuzione di qualsiasi transiente eco tra `pre' e 'post': a fase minima (0), non vi è pre-echo ma una più lunga post-echo; con fase lineare (50), pre e post eco sono in quantità uguali (in termini di segnale, ma non in termini di udibilità); l'impostazione della fase intermedia (25) tenta di trovare il miglior compromesso selezionando una lunghezza di piccole dimensioni (e livello) di pre-eco e una lunghezza media di post-eco. Da notare che le risposte di fase tra `linear' (50) e 'maximum' (50..100) sono utili raramente.
- Bandwidth (90-99,7%)
Bandwidth è la percentuale della banda di frequenza audio che viene preservata. L'impostazione bandwidth del resampler determina quanta parte del contenuto di frequenze del segnale originale (la frequenza originale nel caso di up-sampling, o la nuova frequenza nel caso di down-sampling) viene preservata durante la conversione. Il termine 'banda passante' si riferisce a tutte le frequenze fino al punto di larghezza di banda (ad esempio per frequenza di campionamento 44,1 kHz, e un ricampionamento a larghezza di banda del 95%, la banda passante (pass-band) rappresenta le frequenze da 0Hz a circa 21kHz). Aumentare la larghezza di banda del ricampionamento comporta una conversione più lenta e può aumentare gli artefatti eco nei transienti (e viceversa).
L'opzione -s nello 'steep filter' (filtro di pendenza, larghezza di banda al 99,0%) cambia la larghezza di banda del ricampionamento dal 95% di default (a 3dB), al 99%. I valori della larghezza di banda superiore al 99% non sono consigliati per un uso normale in quanto possono causare un'eccessiva eco nei transienti.
- (Sopra la Largezza di Banda) Aliasing
E' possibile fare aliasing sopra la banda passante. Ad esempio, con frequenza di campionamento 44,1 kHz, e un ricampionamento a larghezza di banda del 95%, significa che il contenuto di frequenza sopra i 21kHz possa essere distorto, ma poiché avviene sopra la banda passante (cioè sopra la più alta frequenza di interesse/ udibilità), questo non può essere un problema. I vantaggi di consentire aliasing sono ridurre il tempo di elaborazione e ridurre (di circa la metà) gli artefatti eco nei transienti.
Utilizzare AWE
Viene utilizzato un metodo di assegnazione diretta della RAM (caricamento in RAM dei WAV). Questa tecnica avanzata richiede l'impostazione dei privilegi LOCK! AWE è l'acronimo di Address Extensions Windowing - l'assegnazione avviene direttamente (la RAM di sistema disponibile scende immediatamente). Windows può NON attribuire tutta la 'RAM disponibile' - in questo caso, cPlay ripiega sull'approccio standard.
Diagnostica è in grado di mostrare se AWE è riuscito ad assegnare la RAM. Process Explorer o Task Manager non mostrano la RAM di lavoro di cPlay, è possibile invece vedere la riduzione nella RAM disponibile.
Assicurarsi di avere i privilegi LOCK impostati sul vostro computer. Se Windows non offre tutta la "RAM disponibile" per AWE, cPlay ritorna all'assegnazione standard. Aggiungere ulteriore memoria RAM evita questo problema. AWE offre la possibilità di caricare fino a 4GB di RAM - non testato.
Come impostare i privilegi LOCK
Effettuare esattamente questi passaggi (applicabile a XP Pro SP2/3):
- Avvio> Esegui> digitare "mmc"> tasto OK
- File> Aggiungi/Rimuovi Snap-in> pulsante Aggiungi
- Selezionare "Group Policy Object Editor"> pulsante Aggiungi
- Pulsante Fine
- Pulsante Chiudi
- Pulsante OK
- Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > seleziona "User Rights Assignment"
- Doppio-click su "Lock pages in memory"
- Pulsante Aggiungi User o Group
- Pulsante Object Types...
- Abilita Groups > disabilita Built-in security principals & Users > pulsante OK
- Inserire "Administrators" sotto "Enter the object names to select" > pulsante OK
- Pulsante Applica > pulsante OK
- File> Salva
- File> Esci
I privilegi Lock sono ora abilitati. Se questo non avviene, cPlay darà esito negativo per AWE e ripristinerà l'assegnazione standard di RAM. Questo è riportato solo in Diagnostica, attraverso il messaggio "AWE allocation successful".
Azioni da tastiera
- '[' / ']' Per il precedente / successivo
- '-' / '=' Per saltare indietro / saltare avanti
- ';' Per la fase 0 / 180
- '.' per l'arresto
- 'P' per la riproduzione / pausa
- MAIUSC + HOME per aumentare il volume
- MAIUSC + FINE per abbassare il volume
- Enter per mandare in play il brano evidenziato
- Alt + F4 o Esc per uscire
Il programma 'cicsRemote.exe' è stato riscritto da Myhailov con le seguenti impostazioni:
http://www.nexthardware.com/forum/me...556-remote.jpg
E' possibile scaricare questa versione di 'cicsRemote.exe' qui e sostituirla alla versione base.
Diagnostics
Moltissimi dettagli vengono forniti quando si attiva Diagnostics. Inoltre, quando cPlay incontra un errore, la diagnostica viene visualizzata - è sempre una buona idea scorrere verso il basso per vedere i messaggi importanti.
Ecco il programma di diagnostica all'avvio di una scheda Juli@:
http://www.cicsmemoryplayer.com/uplo...sticsJulia.png
Sia il Player (cPlay) che il Driver (Juli@) supportano la versione ASIO 2.0. Il livello di latenza al 'preferred buffer' corrisponde alla latenza di uscita (48 campioni), l'output è pronto e l'ottimizzazione hardware è fatta. Juli@ passa a pieni voti!
Per RME HDSP9652:
http://www.nexthardware.com/forum/me...mehdsp9652.jpg
Deludente vedere solo il supporto per ASIO 1.0 e la latenza di uscita effettiva che differisce dalla latenza buffer preferita - è peggiore di Juli@. Idealmente, la latenza di uscita e il buffer dovrebbero essere uguali. L'output è pronto e l'ottimizzazione hardware è fatta
Per EMU 1212M:
http://www.cicsmemoryplayer.com/uplo...csEMU1212M.png
Questa scheda audio offre una scarsa latenza di 2ms (a qualsiasi frequenza di campionamento), la latenza buffer preferita non corrisponde alla latenza in uscita e nessuna ottimizzazione hardware supportata. Da notare che se si ha una scheda EMU installata, non disattivatela (in Gestione periferiche) in quanto questo provoca instabilità (il driver rimane operativo)!
Qui potete trovare una guida dettagliata su come settare questa scheda al meglio.
VST plugin
VST è lo standard di Steinberg per l'applicazione di effetti audio DSP ai flussi audio. Gli effetti possono essere di qualsiasi genere (da stereo a mono, EQ, stereo a 5.1., ecc.). Esiste una varietà enorme - bisogna stare attenti però perché alcuni sono di cattiva qualità (bug e /o processano per numeri interi con perdita di qualità). Utilizzato correttamente, si possono ottenere ottimi risultati. Un altro acronimo comune è VSTi che sono componenti DSP che agiscono come strumenti musicali.
cPlay supporta l'uso di un unico plugin VST (fino alla versione 2.4.2, 2-in/max 8-out) a 32 bit di precisione virgola mobile. Il plugin è processato dopo il ricampionamento e il volume (se utilizzato). Per ottenere i migliori risultati, utilizzare le impostazioni Tiny o Small del buffer. Le prestazioni ASIO sono mantenute per i plugin 2-in/2-out (uscita stereo). Per l'uscita multi-canale, le migliori prestazioni ASIO si ottengono quando la latenza è di 64 campioni o meno.
Regolazioni:
- Il pulsante Bypass diventa disponibile quando un plugin è attivo. Per l'uscita stereo, l'output attraversa il DSP. Per il multi-output, solo i primi 2 canali mappati ASIO sono utilizzati (per sinistra e destra). Per l'uscita mono, l'output DSP è richiesto e mediato sui canali mono ASIO selezionati.
- Abilitare l'opzione VST permette di utilizzare il plugin in modalità provvisoria che ne limita il controllo. Si accede all'Editor VST tramite un prompt, il bypass non è consentito, e l'autoplay non si avvia.
- Il setup del plugin viene fatto usando il pulsante VST:
http://www.nexthardware.com/forum/me...ettingsvst.png
Le impostazioni VST hanno effetto solo dopo un riavvio. Selezionare il plugin (file. DLL) tramite il pulsante "VST Plugin". "Delete" cancella tutte le impostazioni VST.
Per l'uscita stereo, sono usate le impostazione di default sinistra/destra ASIO. Per le uscite multiple, il setup d VST per ASIO consente di attivare l'uscita per ciascun canale ASIO. Ciò elimina inutili overheads ASIO quando non si usano tutte le uscite del plugin, ad esempio, se di un plugin a 8-outs solo 6 sono utilizzati.
- Dopo un riavvio, il plugin diventa operativo (vedi Diagnostica per i dettagli). La finestra principale di cPlay attiva il pulsante VST per accedere al plugin Editor. Se un plugin non offre un Editor, il pulsante VST rimane disattivato.
Plugin popolari:
- Allocator, formalmente chiamato Frequency Allocator, permette di eliminare il crossover dei diffusori (e relative problematiche). Invece, viene utilizzata l'elaborazione digitale: il segnale stereo viene convertito in coppie di frequenze tagliate (basso L+R, medi L+R, ecc.) il cui segnale analogico amplificato viene quindi inviato direttamente ad un diffusore.
- Room Correction è utile. Il numero dei produttori è ancora limitato e le soluzioni costose, anche se esistono versioni open source tipo Convolver.
- Il concatenamento di più effetti può essere realizzato utilizzando Effects Chainer (gratis, 2-in/2-out) o l'eccellente plugin Console (simili sono Bidule e AudioMulch). Ecco una catena multi-effetto con EQ> Allocator> Spectrum Analyser (per verificare le uscite di Allocator):
http://www.nexthardware.com/forum/me...vstconsole.gif
File Cue
Il modo migliore per ottenere una riproduzione è attraverso i file Cue. Si tratta di uno standard ideale per le playlist. cPlay supporta sia schede singole che multi contenenti file multimediali in formato wav o flac (a qualsiasi frequenza di campionamento).
Suggerimenti:
- Con un software per il CD ripping come EAC è possibile creare file cue;
- cPlay List Editor (download) è un'applicazione Java per generare liste di brani (per qualsiasi lettore musicale che supporta i file cue). L'applicazione si avvia in una cartella specificata e aggiunge file musicali alla lista. Le playlist sono interattive e create da questi elenchi. Le playlist possono essere salvate per essere caricate in un altro momento, oppure essere inviate direttamente a cPlay.
Ultimamente, l'applicazione è stata ricompilata con ulteriori miglioramenti e non ha più bisogno di Java. Scaricare l'ultima versione da qui.
http://www.nexthardware.com/forum/ga...ist_Editor.jpg
- Recursive Cue Creator è una applicazione Java che spazia tra le proprie librerie musicali esistenti e crea file Cue per l'utilizzo con cMP² (o altri player che supportano file cue). Per una cartella specificata comprese tutte le sottocartelle, crea un file cue per ogni file wav o flac trovato. Le voci del file Cue conterranno il percorso completo. È possibile specificare se salvare tutti i file in una singola cartella, o salvarle nella cartella dove si trovano i brani.
http://www.nexthardware.com/forum/me...cuecreator.jpg
Qui trovate una guida dettagliata su come confezionare i file .CUE per un sistema cMP².
Latenza ASIO
I driver ASIO consentono il controllo della latenza nei campioni (o il tempo o la dimensione in byte). La registrazione richiede latenze molto basse (dell'ordine dei 32 campioni). Lo stesso vale per la riproduzione, ma la sua logica è diversa. Nella registrazione, c'è un esplicito intervallo di tempo tra quando uno strumento è suonato e quando è registrato. Qui, si ricerca l'elaborazione in tempo reale, cioè il suono viene registrato mentre accade.
La dimensione è importante (durante la riproduzione)?
Configurazioni raffinate rivelano prontamente variazioni di qualità nel suono con il cambiamento della latenza. E' meglio usare la più bassa latenza stabile. Un buon programmatore potrebbe sostenere che la latenza è un non-problema per la riproduzione. "Basta impostarla al livello più alto in quanto si ottengono meno cambi di contesto, il che è più efficiente...". Questo non è corretto per la migliore qualità del suono.
A livello software, firmware e hardware, PCI preferisce carichi piccoli.
Il “jitter di latenza" come variazioni di latenza si pensava fosse la causa per cui la latenza influiva sulla qualità del suono. Questo punto di vista è stata demolito.
Dal punto di vista del Jitter, quando il buffer di una scheda audio è popolato (mentre l'altro buffer viene convertito in SPDIF o altro), c'è una raffica di attività elettrica. L'idea è di mantenere questa raffica il più breve possibile, riducendo così le interferenze sull'oscillatore della scheda audio, cioè ridurre Jpp. Si raggiunge questo impostando la latenza al livello più basso possibile. Naturalmente, utilizzare una bassa latenza, equivale a carichi di buffer più frequenti. Questa è la cosiddetta frequenza ASIO (o ASIO Hz). A 32 campioni di latenza per l'uscita a 96k, ASIO Hz è 3kHz. Questa è ora di natura periodica ed è indotta digitalmente. Ora abbiamo il Jitter periodico - la peggior specie che esiste per tutti i sistemi di riproduzione digitale. Pero', ASIO ci dà il controllo su questo.
Un'ASIO Hz elevata è preferibile e decisamente si vuole evitare di andare sotto a 1kHz. Perché? Il PLL della scheda audio o il PLL a valle della catena sarà in grado di ridurre ulteriormente il jitter periodico in quanto la frequenza ASIO è probabile che sia al di sopra della frequenza di taglio del PLL.
cMP²: Il Software provoca Jitter
http://www.nexthardware.com/forum/me...mplogotiny.jpgIl 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:
http://www.nexthardware.com/forum/ga...ucedJitter.png
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.
cMP²: Jitter: teoria, analisi e misurazioni
http://www.nexthardware.com/forum/me...mplogotiny.jpgJitter: teoria, analisi e misurazioni
Di tutti i parametri cruciali in un impianto audio, una naturale “fioritura” è forse il più importante - non è una fioritura artificiale che rapidamente diventa apparente e faticosa da ascoltare, ma una che è leggermente sottile e mai affaticante, che produce un suono realistico e con una 'presenza' reale. Il Jitter (e un upsampling errato) la distrugge.
Teoria del Jitter
È stato Julian Dunn che ha posto le basi per la comprensione del jitter in campo audio. Esempi del suo lavoro, che è molto interessante, si posssono facilmente trovare sul web. Nel contesto dell'audio digitale, il jitter si riferisce a errori di sincronizzazione del clock master utilizzato in DAC e ADC. Anche il minimo errore causa errori di ampiezza del segnale. L'effetto può essere modellato, simulato e misurato. È di tipo casuale, che è facile da capire, o deterministico, che lo è di meno.
Il jitter deterministico ha due forme: correlato ai dati e periodico. Come suggerisce il nome, il jitter correlato ai dati si verifica quando sono presenti certi modelli di dati. Il jitter periodico, d'altra parte, è ciclico - ha una frequenza definita. In un singolo periodo (1/F dove F=frequenza), i segnali del clock si allungano e si riducono anche se il tempo trascorso su un periodo di misura rimane stabile.
Jitter Casuale
Anche il jitter casuale, che incide sul SNR di un DAC, può essere modellato. Come ci si potrebbe aspettare, il jitter casuale deve essere basso per realizzare buone prestazioni di SNR. I miglioramenti sono difficili da realizzare in quanto sono necessarie riduzioni significative nel jitter prima che ci sia un cambiamento percepibile. Un altro parametro importante è la frequenza di campionamento (Fs). Più alto è il valore di Fs, maggiore è il SNR - raddoppiando il Fs si migliora il SNR di 3 dB. (Questo è stato dedotto dalla formula di Burr Brown per il calcolo del SNR di un DAC).
Jitter Periodico
Il jitter periodico ha, per definizione, una frequenza definita ed anche i suoi effetti di distorsione possono essere modellati. DAC (e ADC) creano distorsione (rumore di banda laterale) quando sono soggetti a jitter periodico. Per una data frequenza di ingresso, le bande laterali possono essere viste su entrambi i lati della fondamentale, distanziate dalla frequenza del jitter, come mostrato nella fig 1:
http://www.nexthardware.com/forum/me...odicjitter.png
Figura 1. Jitter periodico (Jpp) di 7ns a 3kHz per un tono puro d'ingresso a 10 kHz. Ci sono bande laterali a 7 e 13 kHz la cui distanza dalla fondamentale è data dalla frequenza di jitter (qui, 3 kHz). Julian Dunn ha osservato che “In questa figura ci sono anche "gonne" per lo spettro vicino alla componente a 10 kHz. Queste sono a causa di qualche rumore jitter a bassa frequenza nel sistema.”
Mentre il grafico mostra jitter sinusoidale periodico che interessa un segnale audio a 10 kHz, il jitter da onda quadra è ancora più dannoso in quanto dà luogo a bande laterali continue su tutta la banda audio. Queste si possono determinare utilizzando la formula di Dunn:
http://www.nexthardware.com/forum/me...-2-formula.png
Figura 2. I livelli di energia della banda laterale aumentano con frequenze più elevate e livelli di jitter audio superiore (J come in Jpp).
Nell'esempio, un Jpp a 7ns che agisce su di un tono di ingresso di 10 kHz offre bande laterali a -79.2db. La formula rispecchia come i livelli di energia di banda laterale aumentino all'aumentare delle frequenze e dei livelli di jitter. In termini semplici, significa che più alta è la frequenza di ingresso e maggiore è il jitter, maggiore è la forza (o energia) delle distorsioni sulla banda laterale.
Il jitter periodico è più dannoso di quello casuale in quanto le bande laterali non sono legate alle armoniche del tono riprodotto. Dal momento che le armoniche di ogni nota musicale si estendono anche verso le frequenze alte, il suono del decadimento di un segnale viene distorto dal jitter periodico: la sua 'fioritura' si perde. Il jitter è più dannoso alle alte frequenze, cioè quando si verificano grandi sbalzi di tensione (rotazione), ciò porta a errori di segnale di maggiore ampiezza.
Il Jitter è cumulativo
Tuttavia, per il jitter c'è di più oltre la modalità casuale e periodica. Altre forme, le quali influenzano la qualità audio (e hanno il potenziale di causare problemi di blocco di sincronizzazione), includono:
- jitter d'Interfaccia (errori di timing legati alla trasmissione – o perché cavi digitali suonano diversi);
- jitter correlato ai dati (di cui sopra);
- jitter intrinseco del chip ricevitore che decodifica i segnali in entrata.
Il punto critico è che il jitter è un fenomeno cumulativo: qualunque siano le sue fonti, si combinano in modo dannoso aumentando sempre i livelli di jitter totale. Globalmente, questo riguarda il clock di campionamento al DAC o ADC, che è dove si verifica la conversione del segnale e si attiva la distorsione. Il risultato è errori di ampiezza del segnale. Mentre DAC e ADC utilizzano segnali di clock diversi, è il jitter nel clock di campionamento (LRCK) che è più dannoso per le loro prestazioni. La Fig 2.b mostra il AK4358VQ della AKM (utilizzato sulla scheda audio Juli@).
http://www.nexthardware.com/forum/me...kmak4358vq.png
Figura 2b. Pin layout del DAC chip di AKM. Offre otto canali di output (quattro coppie di L-R). L'input dei dati digitali (a livello bit) è sui pin da 13 a 16, i pin del clock sono 17 (LRCK), 10 (MCLK) e 9 (BICK). AKM chiama MCLK il Master Clock. È sincronizzato a LRCK (il più importante, spesso definito il word clock o di campionamento). AKM usa MCLK per operare il filtro d'interpolazione e il modulatore delta/sigma. (Ignorare i pin marchiati DSD.)
http://www.nexthardware.com/forum/me...-akmclocks.png
Figura 2c. Un diagramma temporale per il DAC chip di AKM (PCM in modalità default) che mostra LRCK (il clock di campionamento) dove un ciclo è 1/Fs (la frequenza di campionamento) e BICK (il bit-level clock, simile a un segnale SPDIF). Quando i dati sono "upsamplati" a 24/96, BICK funziona a 6.144 mHz.
Il clock di campionamento determina quando un campione (la coppia L-R) viene eseguito. Un errore temporale significa che i segnali sono processati fuori tempo per cui la loro ampiezza è sbagliata. Quella è la distorsione jitter.
Il jitter casuale è raro - è quasi sempre periodico. Questo è il peggior tipo di jitter ma i Phase Locked Loop (PLL) sono eccellenti nel rimuoverlo. Non importa quale sia la configurazione del sistema (integrato, Transport/DAC, ecc.), ci saranno PLL al lavoro. Purtroppo, però, possono funzionare solo sopra una soglia (cut-off) di frequenza definita, spesso 1 kHz. Non è possibile rimuovere il jitter al di sotto di questa soglia.
Si potrebbe argomentare che i progettisti debbano cercare di spostare l'energia del jitter a frequenze più elevate per permettere ai PLL di lavorare in modo più efficace se non fosse che il jitter ad alta frequenza ha alias e immagini proprio che appaiono al di sotto del cut-off.
Analisi del Jittter
Siccome il jitter è quasi sempre periodico, si può modellare per un tono in ingresso (onda sinusoidale pura). Il jitter periodico può essere raffigurato come un piccolo oscillatore 'all'attacco' del clock di campionamento del DAC, che cambia costantemente la sua precisione provocando errori di fase o di bordo, spostando la fase del clock nel tempo di una piccola quantità. Questo errore di jitter è dato da:
J(t) = 0.5 Jpp sin(Jf 2π t)
dove:
J è l'errore di jitter in secondi applicata alla fase del clock di campionamento,
t è il tempo per la fase del clock,
Jpp è l'ampiezza del jitter picco-picco
Jf è la frequenza del jitter.
In parole semplici, la formula dice che il jitter del clock di campionamento (errore di fase) è ciclico e, alla peggio, è la metà di Jpp (sottraendo o aggiungendo alla lunghezza della fase del clock). In un ciclo completo, il clock di campionamento mantiene la precisione in quanto vi sono fasi in cui gli intervalli di segnale del clock sono più lunghi e altri in cui sono più brevi. (Questa è la natura della funzione Sin) Per cui possono essere calcolati i seguenti parametri:
- L'errore di temporizzazione del clock, dati Jpp e Jf, per ogni periodo di campionamento (1/Fs);
- L'ampiezza del segnale di un campione (per qualsiasi Fs) per un dato input dell'onda sinusoidale;
- La distorsione jitter (o l'errata ampiezza del segnale). Al tempo del campione t, l'ampiezza del segnale è quella che avrebbe dovuto essere meno l'errore temporale: v'(t) = v(t - J(t)) dove v' è l'ampiezza del segnale distorto.
Dunn fornisce la formula per modellare la distorsione jitter per dati Jpp e Jf quando applicati ad un segnale di ingresso sinusoidale. Un programma è stato usato per generare file wav utilizzando tale formula e fornendo toni a 16 o 24-bit a qualsiasi frequenza di campionamento, sia puri che afflitti da jitter periodico (sono stati applicati un dithering di base e un noise shaping del 3° ordine).
http://www.nexthardware.com/forum/me...lledjitter.png
Figura 3. Lo spettro di un tono 24/96 a 10 kHz generato dal programma con jitter modellato a 7 ns/3 kHz. Confronta questo con la figura 1 che rappresenta un vero tono a 10 kHz con lo stesso jitter. La previsione del modello è accurata, mostrando bande laterali separate di 6 kHz (a 7 e 13 kHz) a livelli simili. (L'asse della frequenza è logaritmica. Gli spettri in questo grafico sono stati catturati con l'analizzatore di spettro RMAA utilizzando una risoluzione FFT di 0,37 Hz).
Per cui, registrando le uscite analogiche di un DAC per un dato tono puro di input, si possono misurare le prestazioni di jitter totale: il livello e la posizione delle bande laterali forniscono misure precise di Jpp e Jf per la combinazione Transport/DAC (Jf si ottiene esaminando il risultato spettrale e Jpp viene calcolato in base al livello di banda laterale usando la formula 2).
Il metodo fornisce informazioni sulle prestazioni di jitter generale di una combinazione Transport/DAC, comprese le variabili difficili come l'efficacia del DAC nel respingere il jitter del segnale del Transport, la complessità del jitter d'interfaccia o l'effetto di utilizzare un Toslink in fibra di vetro, e ci riesce senza dover ricorrere a complesse tecniche di analisi del segnale di clock come eye-diagrams. Tre file di test sono stati generati con i risultati riportati di seguito.
http://www.nexthardware.com/forum/me...03-6-input.png
Figura 4. File wav 24/96 generati via software sono stati utilizzati per misurare il jitter a frequenze di 7 kHz (a sinistra), 3 kHz (centro) e 14 kHz (a destra) con jitter simulato a 7 ns (3kHz). La prova di 14 kHz è stato progettata per dimostrare i tre toni (11, 14 e 17 kHz) che vengono ricreati in uscita dal DAC. Se questa eccessiva distorsione jitter fosse stato introdotta dal ADC, sarebbe visibile in uscita del DAC.
Misurazioni di Jitter
I test sono stati condotti per misurare la componente del jitter di un trasporto cMP collegato ad un DAC dCS Scarlatti. Il Transport, dotato di una scheda audio RME HDSP 9652, manda dati 24/96 attraverso una Toslink al DAC e fornisce il master clock (cioè il DAC è in slave).
Il segnale di uscita analogica è stato registrato con una seconda macchina cMP munita di scheda audio ESI Juli@ collegando l'uscita analogica del DAC tramite cavi Sommer Cable a bassa capacità (25 pF) agli ingressi bilanciati (TRS) della Juli@. Entrambe le macchine hanno i cavi di alimentazione di alta qualità, filtri di linea e attacchi indipendenti alla rete. Cubase LE software di registrazione è stato impostato per registrare stereo a 24/96.
Uscita dal DAC Scarlatti con un test tone a 7 kHz è mostrato in fig 5.
http://www.nexthardware.com/forum/me...e-filter-2.jpg
Figura 5. Test tone a 7 kHz registrato alle uscite del DAC (filtro 2).
Il rumore di fondo complessivo è a circa -140 dB con armoniche della fondamentale a 14, 21, 28 e 35 kHz. Per il test tone a 7kHz, bande laterali di jitter sono visibili esattamente a 2kHz dalla fondamentale e corrispondono ad un livello di -122db. Questo dá un Jf a 2kHz e un Jpp di soli ~72ps!
Riottimizzando il Recorder come da specifiche cMP, tranne Minlogon che non è possibile con Cubase, avendo cura di sospendere anche Svchost e Lsass, e ripetendo il test, abbiamo:
http://www.nexthardware.com/forum/me...-7-output1.png
Figura 6. Rivela che le bande laterali di jitter a 2kHz non ci sono più! Componenti del jitter senza dubbio esistono, ma sono sepolte nel rumore di fondo.
Si dimostra, inoltre, che una riduzione del 'peso' del runtime del Sistema Operativo ha un effetto diretto sulla quantità di jitter misurata. Il rumore sulle bande laterali del jitter aumenta con l'aumentare della frequenza, per cui un tono a 14 kHz dovrebbe rivelare più jitter.
http://www.nexthardware.com/forum/me...8-output2a.png
Figura 7. Le componenti a 2 kHz sono bassissime a -135.5db, producendo un Jpp di soli 11 ps ma i livelli di jitter più alti sono visibili in primo piano.
http://www.nexthardware.com/forum/me...9-output2b.png
Figura 8. I livelli di jitter sono visibili guardando alla fig.8 in primo piano.
Un singolo componente della banda laterale jitter di oltre -130dB si tradurrebbe in più di 20 ps Jpp. Nessun componente del genere è visibile nel grafico sopra, ma i singoli componenti del jitter si possono individuare nelle figure 7 e 8 (tono di ingresso a 14kHz) come segue:
- A 2 kHz, un livello di -135.5db (Jpp = 11 ps)
- A 1.605 kHz, un livello di -132,0 dB (Jpp = 16 ps)
- A 5.904 kHz, un livello di -134,0 dB (Jpp = 13 ps)
- Il rumore tipo Jitter vicino alla fondamentale (da 600 a 800 Hz, solo canale RH) con picco di -131,5 dB (Jpp = 17 ps). I valori reali sono -131,5 dB (17 ps), -133,0 dB (14 ps), -134,7 dB (12 ps), -131,8 dB (16 ps) e -133,5 dB (14 ps x 6).
Complessivamente questo produce un Jpp di 51 ps!
Conclusione
Anche se un ascolto prolungato aveva fatto intuire che cMP produceva un basso jitter, non si immaginava mai che si sarebbero raggiunti valori così bassi di Jpp di appena 51 ps. Ad esempio, le recensioni su Stereophile di apparecchiature raramente scendono a livelli di jitter inferiori a 200 ps, e comunque sono ben al di sopra 100 ps.
I risultati spiegano perché il clock Scarlatti non è riuscito a impressionare: la complessità aggiunta dal dispositivo tramite un ulteriore alimentatore e circuiti di sincronizzazione del clock e il fatto che il circuito non era più isolato galvanicamente, assieme hanno iniettato del rumore che è arrivato al clock di campionamento del DAC – una misurazione del jitter con il clock in funzione mostra un aumento di 4 ps in Jpp. Ciò detto, il DAC Scarlatti sicuramente fa la sua figura in questo contesto.
Forse la deduzione più interessante ottenuta dal ciclo di misura è che i problemi di jitter non sono necessariamente risolti con una 'pulizia' del clock di campionamento. Quello sarebbe curare il sintomo, non la causa. Non c'è dubbio che il clock Scarlatti offra alta precisione e basso jitter, ma oscillatori a cristalli (XOs) già offrono una stabilità eccezionale e, cosa più importante, un basso jitter di 20 ps. Sono le componenti inquinanti come il rumore di alimentazione che li destabilizza e danno luogo a scarse prestazioni.
Un Transport basato su CD rotanti inevitabilmente destabilizza il clock. In tale contesto, il trattamento del clock come auspicato da dCS può avere un ruolo utile. Questo non vale per i Computer Audio Transport.
Mentre le problematiche relative alla qualità dell'alimentazione sono ben comprese e sono stati fatti significativi passi in avanti a riguardo, c'è altro da considerare. La Figura 2b (vedi sopra), ad esempio, mostra un tipico DAC chip. Un clock di campionamento apparentemente perfetto che entra nel chip dopo un trattamento completo è ancora soggetto a rumore da parte degli input del chip stesso. A livello microscopico, i DAC sono complessi circuiti integrati il cui clock di campionamento non è isolato galvanicamente. Rumore dai dati e da altri pin del clock creano facilmente un impatto sul clock di campionamento. Con i DAC che diventano sempre più complessi e con livelli sempre più elevati di sample buffering, questo tipo di contaminazione sembra destinata a crescere. In altre parole, ogni pin ha bisogno di essere “pulito”.
In un Computer Audio Transport, le impostazioni dei parametri di RAM, la qualità della RAM e il traffico su scheda madre, creano tutti una differenza percepibile. La purezza con cui i dati vengono trasmessi al DAC è essenziale. È qui che cMP eccelle – e ciò è misurabile.
3 allegato(i)
cMP²: Misurazioni del Resampling
http://www.nexthardware.com/forum/me...mplogotiny.jpgMisurazioni del Resampling
Tutti i file di output sono generati da cPlay 2.0b26 (o successivi).
Vengono utilizzati test tone da 1 kHz in ingresso sia a 16/44.1 che a 32/44.1:
http://www.nexthardware.com/forum/ga..._16_vs_b32.jpg
Upsampling 16/44.1 > 192 (SOX-vLb99.7 a sinistra e SRC 145dB a destra):
http://www.nexthardware.com/forum/ga...16bit_0_16.jpg
Uno sguardo ravvicinato all'opzione “bandwidth” utilizzando un test tone a 16 bit (rumore di fondo ~130dB):
http://www.nexthardware.com/forum/ga...t_0_16_bw_.jpg
SoX al 99,7% offre tutte le frequenze fino a 22 kHz (max è 22.05kHz). SRC offre ~96% e non si può cambiare.
Upsampling 32/44.1 > 192:
http://www.nexthardware.com/forum/ga...32bit_1kHz.jpg
Downsampling 32/192 > 44.1:
http://www.nexthardware.com/forum/ga...it_1kHz_44.jpg
SoX SNR è meglio di 170db mentre SRC è oltre 150dB (da notare un piccolo artefatto 150dB sopra ~20kHz).
Misure di fase fatte utilizzando un test tone di 2kHz (2 cicli per ms) a 24/44.1. Il transiente corrisponde ad un improvviso aumento di volume (50dB) da -90 dBFs a -40dbfs per 5ms:
http://www.nexthardware.com/forum/me...ient-input.png
SRC con output a 192:
Allegato 13979
Entrambi pre e post-ringing sono equamente distribuiti.
SoX output a 192 (fase minima):
Allegato 13980
Nessun pre-ringing, ma un maggiore post-ringing. L'overshoot e il livello di ringing sono maggiori di SRC (a causa di un rigetto db più alto, una maggiore larghezza di banda di SoX e un'assenza di aliasing). Si noti che:
- L'impostazione di SoX su fase non lineare (non-50) influisce sulla risposta di fase ad alta frequenza del segnale originale (cioè più s'incrementano le alte frequenze più queste subiscono un maggiore spostamento di fase). Posizioni intermedie (qualsiasi tra 0 e 50) offrono un migliore equilibrio per quanto riguarda questo trade-off.
- Il ringing osservato è al di là dell'udito umano quando "min(input, output)" è 44,1 o superiore.
- Gli effetti del ringing possono essere ulteriormente ridotti attivando "alias". Questo si traduce in un altro trade-off aggiungendo artefatti da alias sopra la banda passante (larghezza di banda); ad esempio, per input a 44,1, 96% di larghezza di banda e 192k in uscita, si verifica distorsione sopra i 21.17kHz. Questi livelli sono bassi (sotto 100dbRMS) e non nella gamma udibile.
Dilemma della Fase Minima
Utilizzare interpolatori (cioè filtri, resamplers, ecc.) di fase minima (o fase intermedia) da' la possibilità di eliminare (o ridurre) artefatti di pre-ringing nel dominio del tempo. Alcuni DAC offrono questa possibilità e sono considerati superiori a quelli a fase lineare. Deviare dalla fase lineare compromette gravemente la precisione dell'interpolazione. Da qui il nostro dilemma, perché l'introduzione di errore di interpolazione in alcuni casi suona meglio?
Errore di interpolazione
Transienti che ricevono resampling risultano in rumore di pre e post-ringing. Questo può essere visto nella Risposta all'Impulso del interpolatore. In base alla progettazione (ovvero dalla somma della funzione sinc su entrambi i lati del punto centrale), si può intuitivamente capire che non elaborando l'ala destra della funzione sinc, possiamo rimuovere il pre-ringing. Non avendo l'ala destra, il dato del transiente in avvicinamento nel dominio del tempo non viene elaborato, quindi non produce alcun pre-ringing.
http://www.nexthardware.com/forum/me...ure593-sox.jpg
Figura 1. Misurazioni di SoX VHQ da src.infinitewave.ca mostrano la risposta all'impulso per la fase lineare (a sinistra) e per la fase minima (a destra).
Il ringing si verifica al di fuori della gamma udibile, vale a dire per 44,1k di ingresso, la frequenza di ringing è al di sopra dei 22kHz. Un esempio di output ricampionato (44,1> SRC 192k) di un transiente (aumento improvviso di volume da -90 a -40 dBFS per 5ms) è il seguente:
Allegato 13979
Figura 2. Sovracampionati a SRC 192k di 44,1. Il transiente è un segnale di ingresso 2kHz con volume crescente da -90 a -40dbFS (per 5ms). Entrambi (cioè fase lineare) pre e post-ringing sono ora presenti (vedi inserti che mostrano ringing sulla forma d'onda di basso livello -90 dBFs 2kHz) con superamento minimi.
Si sostiene che il pre-ringing (in genere inferiore a 2,5 ms) che precede il transiente è udibile. Post-ringing non è udibile in quanto tali artefatti sono sopraffatti dallo stesso transiente, vale a dire il suono alto maschera quello più basso del post-ringing.
Il calcolo usato per eliminare tale pre-ringing non è un semplice taglio della fascia destra. Si introduce errore di fase. Frasi come spostamento, distorsione e rumore di fase sono usate per descrivere gli interpolatori a fase non-lineare. Infatti, quello che abbiamo è un grave errore di interpolazione. Le ampiezze di segnale nel dominio del tempo sono sottoposte a cambiamento di fase a seconda della frequenza di ingresso. Questo si vede nel grafico della risposta di fase:
Allegato 13981
Figura 3. Misurazioni di SoX VHQ da src.infinitewave.ca mostrano fase lineare (a sinistra) e minima (a destra).
Mentre l'output risultante può produrre lo stesso spettro di frequenza, cioè il contenuto di frequenze nella banda passante rimane inalterato, la fase è gravemente compromessa. Il caso sopra mostra frequenze di ingresso già a partire dal 4 kHz che sono cambiate (deviazione dalla linea retta), compromettendo le informazioni musicali essenziali (armoniche), come il degrado tonale. A differenza dello spostamento di fase uniforme di 180 gradi (inversione di polarità), che è udibile e desiderabile per correggere gli errori di polarità (sia in registrazione e/o di componenti a valle), l'interpolazione non lineare provoca uno spostamento di fase (l'errore aumenta con la frequenza di ingresso). Ciò significa che l'intero flusso audio subisce l'errore di interpolazione! Nel caso di interpolazione lineare, solo pre-ringing è aggiunto ai transienti del flusso audio. Post-ringing si verifica in entrambi i casi ai transienti.
Suona meglio (a volte). Un falso paradiso?
Tale manipolazione matematica viene talvolta sperimentata positivamente, anche quando l'intero flusso audio è inquinato da uno sfasamento non uniforme. Questo criterio adottato per una migliore qualità audio suggerisce un falso paradiso.
Esaminando più da vicino la Figura 2, questa evidenzia che il pre-ringing è al di sopra di 22kHz e si verifica a livelli relativamente elevati (36dB in meno del picco del transiente). Ciò è estremamente importante dato che i transienti di natura sono spesso al massimo (0dBFS) o in prossimità dei livelli massimi. Tale rumore ad alto livello e ad alta frequenza crea una "tempesta perfetta" per la distorsione jitter. Le sue implicazioni si comprendono meglio attraverso la seguente analisi del Jitter Periodico:
http://www.nexthardware.com/forum/ga...ucedJitter.png
Figura 4. Jitter Periodico modellato per una vasta gamma di Jpp utilizzando una scansione di frequenza della gamma udibile e oltre.
Si noti che per frequenze di ingresso sopra 22kHz, i livelli di distorsione della banda laterale sono inaccettabilmente alti anche con DAC con prestazioni di jitter più basse di 150ps Jpp. Le frequenze di jitter periodico che agiscono su tali ingressi produrranno distorsioni all'ascolto quando Jf è più alta di 2kHz. La distorsione jitter della banda laterale la cui frequenza si verifica in un offset (dato da Jf) della frequenza di ingresso avverrà nella gamma udibile. La presenza di ringing si traduce in un rumore di fondo inquinato da distorsione laterale.
Nel dominio del tempo, rimuovendo il pre-ringing, tale distorsione udibile del jitter che precede il transiente non si verificherà. Quindi, con l'introduzione dell'errore di interpolazione togliamo la distorsione jitter associata al pre-ring. La distorsione jitter da post-ringing rimarrà ma i suoi effetti indesiderati sono mascherati dallo stesso transiente.
Conclusione
DAC sensibili a tale distorsione jitter potrebbero suonare meglio quando si introducono errori di interpolazione di fase minima (o intermedia). Cioè, viene sostituito un male per un altro. Si consideri un DAC con un PLL mal progettato o, peggio, senza PLL (o di un cattivo ricevitore USB/SPDIF chip): le frequenze jitter sopra 2kHz sono passate liberamente e interferiscono con il master clock causando un livello alto ed udibile di distorsione jitter della banda laterale.
L'errore di interpolazione è inaccettabile. Nel caso la sua introduzione migliori il suono, ciò suggerisce che il DAC in uso non è efficace nella riduzione della distorsioni da jitter periodico. Un compromesso insoddisfacente.
Tali carenze del DAC possono essere facilmente testate utilizzando un resampler con aggiustamenti della fase, tipo SoX. Sia cPlay che Foobar (con la componente DSP di SoX) forniscono questa possibilità.
10 allegato(i)
cMP²: Sandy Bridge: hardware e bios
Per altri componenti ed ottimizzazioni consultare il resto della Guida.
Harhware:
CPU: Intel I3-2100T oppure I3-2120T
Motherboard: Gigabyte GA-H67MA-UD2H-B3 oppure GA-Z68MX-UD2H-B3
Settaggio BIOS:
cMP²: Versione nLite di XP per installazione
Quelle che propongo e' una versione snellita di Windows XP (SP2 o SP3) attraverso il software nLite.
E' English Only. Ringrazio per il contributo l'utente internazionale Jolida. In pratica, si ricompila il disco originale d'installazione di Xindows XP e se ne fa un altro piu' snello - da 450MB a ~100MB.
Questo e' il primo passo verso un SO totalmente dedicato all'audio.
1) Scaricare la versione di Multiprocessor LAST SESSION.INI
Mettetela in una qualsiasi cartella.
2) Scaricatevi il software nlite IlSoftware.it - nLite 1.4.9.1
3) Create una cartella nuova nel desktop e rinominatela con nLITE
4) Installate il software nLITE.
5) Prendete il cd-rom originale di Windows XP e copiate il contenuto nel vostro PC.
6) Aprite il programma nLite e seguite le istruzioni sullo schermo mantenendo la lingua in Inglese (e' piu' semplice).
Come sorgente di XP, scegliete la cartella del vostro XP che avete precedentemente salvato;
poi, caricate la configurazione desiderata, cioe' il LAST SESSION prescelto;
andate avanti fino alla fine - Yes e Next - e create una nuova immagine su hard disk del disco d'installazione di XP.
Tale disco ha tutto il necessario per l'installazione del vostro cMP - firewire, network, usb... - ed e' di circa 100MB appena. ;oookk:smt080
Per installare i privilegi lock leggere i seguenti commenti:
http://www.nexthardware.com/forum/cm...tml#post837651
http://www.nexthardware.com/forum/cm...tml#post838107
Commenti