CMP2: EMU 1212m vs Asus Xonar D2... differenze non trascurabili!

[Miclaud]

Premetto che ho appena assemblato un cmp2 full compliant ad un mio amico, rimasto estasiato dalle performance del mio pc.
Lui aveva modo di riutilizzare una scheda audio, la Asus Xonar D2, così ho voluto provare.

L'hardware è quello consigliato, con piccole variazioni atte a riusare più componenti possibile dal suo pur buon pc:
Processore: Intel i3-540
Mobo: Gigabyte GA-H55M-USB3
Ram: Kingston DDR3 1333 KVR1333D3N9/2G
SSD (Sistema Operativo): Corsair Nova 32 GB
HHD (Musica): Francamente non ricordo... un hd da 500 GB
Case: Nox Media
Scheda audio: Asus Xonar D2
Alimentatore (per mobo e EMU): Thermaltake di cui non ricordo il modello preciso... ma un ottimo alimentatore.
Alimentatore (per alimentazioni sporche): Un alimentatore ATX da 300W rimediato (è una soluzione temporanea)

Ovviamente tutte le modifiche bios e al sistema operativo sono state implementate.



Detto ciò, durante l'assemblaggio non ho resistito alla tentazione di confrontarla con la mia scheda. Vi premetto però che ho capito solo ora di aver fatto un'errore: uso spesso come test un brano al pianoforte registrato mostruosamente bene a 96Khz. Visto che imposto l'upsampler SRC 145db a 96K (per via del limite superiore del mio DAC) non mi sono reso conto che lo stesso era praticamente disattivo visto che il file audio aveva già quella campionatura! Questo dettaglio sarà fondamentale per chiedervi un'altra cosa più in avanti...


Proseguendo, con tale brano ho notato una differenza clamorosa nei dpclat con le due diverse schede. La mia EMU, come accennai nel thread del mio Transport PC ( http://www.nexthardware.com/forum/cm...ro-e-nato.html ) ha valori di DPC intorno ai 60us con ASIO settato a 2ms e valori sui 15us con ASIO settato a ben 50 ms. Ad orecchio mi è sembrata migliore la seconda soluzione.
Sono però rimasto a bocca aperta provando la Xonar... 15ms fissi e stabilissimi con solo 1ms di buffer ASIO
E l'orecchio mi ha suggerito che con la Xonar il risultato sonico fosse in linea con quello "numerico".
Il driver usato è lo UniXonar 1793 1.30 (l'ultimissima versione) con opzione a bassa latenza.

Come vi spiegate una differenza così abissale? Quella sera ero praticamente quasi convinto di acquistarmene una per me quando però a casa del mio amico, al momento di provarlo, non abbiamo deciso di upsamplare dei files da 44.1Khz...

Tragedia! Come entra in azione l'upsampler, il suono è continuamente interrotto e saltellante, un vero incubo. Abbiamo provato ad impostare l'upsampler a 44.1 e tutto va bene con i file della stessa campionatura (quindi upsampler disattivato), ma il fenomeno si riverifica riascoltando i brani a 96k (quindi downsamplando).
Usando SRC a 120 db o Sox VHQ le cose migliorano un pò, ma i fenomeni compaiono saltuariamente.

Ovviamente ho provato molte impostazioni: sia buffer cplay (da small a large, con nessuna differenza) e sopratutto ASIO, salendo da 1ms a ben 80ms. Aumentando il buffer asio le cose migliorano ma non si ha mai l'impressione di avere una soluzione stabile (i salti si ripresentano "saltuariamente", perdonate il gioco di parole).
Con foobar, le cose vanno molto meglio che con cplay, anche quando da quest'ultimo uso lo stesso upsampler (il SOX). E questa mi pare una stranezza da non poco!

Ma quello che mi lascia più sconvolto è il fatto che la EMU, con QUALUNQUE impostazione (anche 2ms di buffer asio e SRC145db a 192Khz!) non ha minimamente salti! Pur ricordando che, in principio e con upsampler disattivo, i DPC lat erano nettamente migliori, e lo stesso valeva per il suono.

Vi bastano come stranezze? Ve ne aggiungo un'altra. Decido di disattivare l'avvio della CMP Shell e usare xp (per maggior praticità nel cambiare impostazioni) e i problemi sembrano sparire. Poi si è fatto tardi e non abbiamo potuto fare altre prove... per ora ho lasciato tutto con SOX VHQ a 176KHZ e va perfettamente.


Ho letto nel forum e ho trovato l'interessantissimo posto di Audiodan: ( http://www.nexthardware.com/forum/cm...rte-prima.html )

Da un lato mi ha dato spunti per fare altre prove (attiverò i core della cpu, modificherò il volting e proverò anche i driver ufficiali invece che gli UniXonar) ma dall'altro sono perplesso dal fatto che i suddetti problemi sembrino non affliggermi usando foobar, oppure usando cplay nella modalità xp, invece che cmp shell.


Vi allego un pò di dati che raccolsi quando feci la prova con upsampler disabilitato (in spoiler per non far casino):

Dati Asus Xonar D2 (ASIO settato a 1ms)

	Spoiler:

EMU 1212m (ASIO settato a 2ms)

	Spoiler:

[bibo01]

Tutto molto interessante.
Dimostra una volta di piu' quanto il driver interagisca a basso livello con l'hardware.
Inoltre, a mio avviso l'implementazione di SoX in cPlay e' migliore rispetto a Foobar, per cui per quanto riguarda la Asus con cMP², prova a disabilitare la sospensione di lsass in cMP.

[Miclaud]

Tutto molto interessante.
Dimostra una volta di piu' quanto il driver interagisca a basso livello con l'hardware.
Inoltre, a mio avviso l'implementazione di SoX in cPlay e' migliore rispetto a Foobar, per cui per quanto riguarda la Asus con cMP², prova a disabilitare la sospensione di lsass in cMP.

In effetti tra le tante cose ho omesso di dire che in ogni caso preferivamo sempre cplay a foobar, anche con quest'ultimo configurato con sox e playback da memoria.

Non ho avuto modo di fare uno screen delle impostazioni di cmp shell. Lsass è già disattivato mentre schost no (non abbiamo avuto il tempo di giocare su questi parametri). Il playback dalla memoria è ovviamente attivo.


Mi chiedevo... per curiosità, è possibile disattivare del tutto l'upsampling in cplay? Se imposto 44100 è un problema con i file ad alta risoluzione perché verrebbero downsamplati. Non c'è modo di dire a cplay di lasciare sempre il samplerate del file così com'è in origine? Non abbiamo notato differenze sconvolgenti, seppur mi è parso di sentire un lieve miglioramento...

[bibo01]

...Mi chiedevo... per curiosità, è possibile disattivare del tutto l'upsampling in cplay? Se imposto 44100 è un problema con i file ad alta risoluzione perché verrebbero downsamplati. Non c'è modo di dire a cplay di lasciare sempre il samplerate del file così com'è in origine? Non abbiamo notato differenze sconvolgenti, seppur mi è parso di sentire un lieve miglioramento...

No.
Non e' possibile. Ho parlato con il progettista.
Se non vuoi cambiare risoluzione, conviene lasciare sempre 88 o 96 kHz

[audiodan]

Vediamo di chiarirci un po' le idee:
1) I problemi di cMP2 con la Asus sono legati ai driver. Ti consiglio subito subito di disinstallare l'Unixonar con 1793 perchè non funziona!L'ho provato l'altra sera sul Sughetto ed è letteralmente inascoltabile.
Metti gli originali Asus, magari i 1792 che io sto usando con successo e con una latenza veramente risibile. Attenzione a disinstallare del tutto i driver precedenti, altrimenti succedono casini ( vedi sempre la prima parte del thread sulla Essence).
Il problema dei saltellamenti e dei dropout sono legati ad una incapacità della CPU a smaltire il lavoro contemporaneo di decompressione dei flac e di processamento del file ( magari con upsampling). Da qui la necessità di settare il BIOS della GB come ho descritto nel thread sulla Essence. Tieni sempre presente che i settaggi consigliati sono indicativi, il fine tuning va fatto con un po' di sudore della fronte, pazienza e capacità di non scoraggiarsi davanti a risultati apparentemente frustranti. I risultati finali pagano!!
2) Perchè privarsi di un meraviglioso strumento che migliora in maniera sostanziale e gratuitamente il Suono? Perchè privarsi di un upsampling a 24/192, quindi? I settaggi vanno cercati,IMHO ovviamente, per questa configurazione, che vi ripagherà della fatica. SoX a me piace più di SRC ed è anche molto meno impegnativo per la CPU, che lavora in media al 6% contro il 22% con SRC. Non è comunque vero che processare un file audio sia un carico da ridere per le CPU moderne: fanno fatica anche loro, e se hanno driver poco efficientio mal integrati vanno in crisi del tutto.
3) Usare la shell di cMP migliora ulteriormente l'utilizzo dei driver. Questo lo si può sperimentare perchè potrete avere dropout utilizzando cplay come player in ambiente explorer ma quando vi riporterete nella shell di cMP tutto andrà a posto. Per cui io consiglio caldamente di ascoltare fin quando si può con cMP2 ( shell + cplay), lasciando Foobar per gli mp3 e per tutti quelli non supportati, da usarsi ovviamente in ambiente explorer.
Ci facci sapere, ci facci, che cosa succede........

[Miclaud]

Metti gli originali Asus, magari i 1792 che io sto usando con successo e con una latenza veramente risibile. Attenzione a disinstallare del tutto i driver precedenti, altrimenti succedono casini ( vedi sempre la prima parte del thread sulla Essence).

Ciao Daniele! Avevo letto con molto interesse il tuo thread e ricordavo che c'erano molti spunti interessanti per risolvere questi problemi.
Una cosa: come mai mi consigli di provare il driver ufficiale 1792 e non il 1793? C'è stato qualche peggioramento a tuo parere?
Per il resto, mi sono già procurato tutti i tool necessari.

Ma quindi nel caso della Asus il processore viene penalizzato dai driver della ASUS? Perché con la EMU posso fare underclock e disattivare tutti i core senza problemi, pur avendo tempi di dpc mediamente più alti rispetto alla Asus. Questo significa che EMU ha un driver più efficente che grava meno sul processore? Però mi sembra paradossale che nel frattempo la dpclat sia più elevata...
Si fa per capire ovviamente

2) Perchè privarsi di un meraviglioso strumento che migliora in maniera sostanziale e gratuitamente il Suono? Perchè privarsi di un upsampling a 24/192, quindi?)

Non ho mai ben capito i vantaggi che porta l'upsampling software, ma mi documenterò al riguardo (se avete dei riferimenti sono molto ben accolti ).
Ci chiedevamo però se fosse strettamente necessario usare l'upsampler quando il North Star 32 del mio amico ha già di suo un ottimo upsampler integrato, ovviamente se non sono male informato.

3) Usare la shell di cMP migliora ulteriormente l'utilizzo dei driver. Questo lo si può sperimentare perchè potrete avere dropout utilizzando cplay come player in ambiente explorer ma quando vi riporterete nella shell di cMP tutto andrà a posto.

E' quello che ho sempre pensato, appunto sono rimasto molto male nel vedere che in ambient explorer i problemi sono drasticamente diminuiti! Cavoli... non ha senso!
A meno che da cmp shell ci sia qualche cosa che non va... magari provando a giocare con i vari lsass e svchost le cose cambiano, o magari reinstallando la shell.


Grazie infinite carissimi

[audiodan]

Ti dirò che non ho provato i 1793 ufficiali ma solo quelli Unixonar, che ho trovato disastrosi con cMP2. Con i 1792 Asus non ho nessun problema per cui ho preferito tenerli, senza andare a fare danni inutili.
Per l'upsampling guardati sia lo scritto originale di cics che l'eccellente lavoro di bibo nei rispettivi manuali. Ti confesso che la molla che ha scatenato la mia decisione di costruire un cMP2 è nata dalla lettura di queste poche pagine. Guarda quel microsecondo di musica dei grafici riportati e capirai perchè l'upsampling fatto con un sistema valido migliora il segnale musicale senza aggiungere niente, solo rimodellando un'onda sonora in modo naturale. L'ascolto conferma perfettamente quanto riportato.
Credo che abbia mal interpretato, invece, quanto ho riportato sulla shell: in genere con il cMP2 funziona tutto meglio, viste le ottimizzazioni volte alla riproduzione musicale, non il contrario. O almeno nel mio sistema accade questo.
Io non mi fisserei più di tanto sulla latenza, però controlla di non avere programmi attivati in background perchè questo la fa saltare, spesso di molto.
Per ciò che riguarda i driver e la loro integrazione con cMP è un fatto che ci siano problemi. Io ho l'impressione che i driver ASIO della Asus siano molto più impegnativi per la CPU che ASIO 4ALL, per esempio. Questo ha comportato la necessità di cambiare i settaggi previsti dai manuali. Però, ad esempio, noi abbiamo entrambi usato una MOBO differente da quella consigliata " ufficialmente" per cui è possibile che non sia possibile ottenere settaggi identici.
Quello che è possibile ottenere è un grande e meraviglioso suono, di questo sono sicuro, visto che lo sto ascoltando anche adesso

[audiodan]

Preso da una insopprimibile botta di vita domenicale ho installato i 1793 Asus: fungono degnamente senza problema alcuno.

[Miclaud]

Preso da una insopprimibile botta di vita domenicale ho installato i 1793 Asus: fungono degnamente senza problema alcuno.

Oggi, se tutto va bene, passerò dal mio amico a fare un pò di prove, ti/vi farò sapere come si sarà evoluta la situazione

[Miclaud]

Grande!!!


Abbiamo risolto! Già installando i driver ufficiali, versione 1793, le cose son migliorate: tempi di latenza ulteriormente abbassati (un 5-7us da panico) mentre usavamo l'src anche a 145 db.

Poi, tornando alla shell cmp, i problemi dei salti sono tornati. Ho pensato quindi che fosse inevitabile dover attivare gli altri core e alzare il clock ma prima ho voluto giocare un pò con i vari parametri... non era possibile che da windows tutto fosse perfetto e da cmp no!
Così ho pensato alla prima differenza tra i due... la gestione delle priorità del processo cplay.exe!
Ho così impostato l'ottimizzazione da Critical a RealTime. RISOLTO!!
Ora va che è una bomba, ma siccome non notiamo differenze, abbiamo preferito mantenere il SOX, che ci permette un buffer asio sugli 8-10ms (invece dei minimo 20ms imposti da SRC, per non avere salti).

Che ne pensate? Come mai la modalità Critical dava tutti questi problemi?