Fidelizer eccellente ottimizzatore audio per Vista e seven

wasky ha scritto:

Leggi questo purtroppo in Inglese

http://en.wikipedia.org/wiki/Deferred_Procedure_Call

un processo a basso livello non occupa cpu ma, la CPU lo deve cmq processare

grazie mi segno il link, appena ho tempo lo leggo.

wasky ha scritto:
Non vi imparanoiate come noi di next con le latenze basse al limite dello 0 ascoltate la musica ragazzi

grazie del consiglio io però ragiono già così, la mia è una domanda dettata, più che altro, dalla voglia di capire. poi della latenza non mi interessa molto, se non genere alle mie orecchie apprezzabili differenze.

wasky ha scritto:

un processo a basso livello non occupa cpu ma, la CPU lo deve cmq processare

Ehhhh?????

Saetta McQueen ha scritto:a parte il fatto che, francamente, non ho ancora ben capito che tipo di "interferenza" possa derivare dagli altri servizi in esecuzione quando si riproduce un semplice file audio (posso capire in registrazione), che dovrebbe essere meno di una passeggiata per un moderno processore, se è vero che gli altri processi creano "interferenza" , come più volte ho letto anche in questa stessa discussione, in corrispondenza dei rettangoli più alti di dpc latency non dovrebbe esserci anche una maggiore occupazione della cpu (creata apputo da uno dei processi in esecuzione) ?

E' esattamente ciò che penso io. Una CPU moderna non ha problemi ad eseguire un flusso audio, per di più che ormai è eseguito con accesso diretto alla memoria. Con i buffer, poi, il flusso audio sarà sempre COSTANTE, anche se la CPU dovesse appesantirsi causa lavoro esterno. Con più core poi è praticamente impossibile impensierire la CPU per una banale riproduzione musicale. Se si pensa che in un videogioco ci sono centinaia di flussi audio e sono tutti sincronizzati sia tra loro che con la grafica di ciò che avviene sul monitor, in base alle azioni del nostro alter ego (e qui sì che la cosa si fa impegnativa per la CPU che deve coordinare tutto, ma anche qui nessun alterazione della sincronia).

Tu non vedi cambiamenti nella latenza anche se la CPU aumenta il carico proprio perchè il buffer entra in funzione e continua ad essere eseguito in DMA anche se la CPU fa dell'altro. Come al solito gli audiofili pensano che il loro audio sia la cosa più complessa del mondo da fare per qualsiasi dispositivo, credono che ci vogliano meccaniche ed elettroniche costose, figuriamoci se un misero PC adibito a "tuttofare" potrebbe compiere questo compito senza impantanarsi! Gli audiofili veri non possono pensare che tutto ciò sia fattibile anche da un banale Pentium 4, sarebbe uno sminuire la riproduzione musicale perfetta!

Il concetto di latenza, come più volte ho detto, ha senso solo in REGISTRAZIONE con basi MIDI e/o suonate in tempo reale con strumenti collegati al PC in concomitanza con l'esecuzione di suoni e loop campionati, allora sì se la latenza è troppo alta il flulsso audio in input (non in output) verrebbe registrato con un ritardo rispetto ai suoni campionati. Ma per la RIPRODUZIONE ciò non avviene.

Menestrello ha scritto:

wasky ha scritto:

un processo a basso livello non occupa cpu ma, la CPU lo deve cmq processare

Ehhhh?????

Boh, non l'ho capito nemmeno io che centri. Io leggo semplicemente che l'istruzione a bassa priorità eseguita all'interno di un processo ad alta priorità è demandata a un'esecuzione posticipata. Ma comunque occuperà la CPU.

ho scordato "non" occupa molta CPU quindi non lo vedi come picco nel task manager

ammazza fate er pelo all'uovo, scusate

I task audio hanno di solito priorità BASSA, il SO da più importanza a grafica e video. Alcuni dei tweak riguardano modificare il registro e le affinità per massimizzare la priorità dell'audio.

USB (trasferimento di dati attivo) e LAN sono tra i peggiori servizi che interferiscono con l'audio. Prova ad ascoltare una traccia che conosci bene con e senza quel tipo di attività in corso (lo stack di rete andrebbe disabiliato del tutto, ma pochi possono farlo). Le differenze ci sono, ovviamente usando un player decente e non WMP.
Perché? jitter digitale.

Telstar ha scritto:
Perché? jitter digitale.

A me questa cosa del jetter digitale mi manda fuori di capoccia

ma che roba è? ma come fa ad interferire?
ma come mai in un flusso dati usb non audio sto jitter digitale non mi rovina i file che per esempio scrivo su una pennetta?
Qualcuno mi sa spiegare perché?

il nostro amico jitter,
come faremmo senza di lui

cosa non mi torna è come chiamate posticipate, buffer, priorità ecc.ecc. possano influire sul jitter,
(che è un problema ben diverso dall'avere un buffer vuoto, con temporanea interruzione della riproduzione)
chi mi sa fornire link o maggiori dettagli su come funziona il giochino?

l' USB con chi si sincronizza per spedire i dati ? immagino la CPU non intervenga su ogni byte da trasmettere,
quindi ci saranno dei buffer, il cui inizio trasmissione è magari comandato da CPU (ma inizio asincrono immediato, quindi passibile di jitter, o cmq agganciata ad un clock hardware, ed eseguita nel primo stato di clock valido?) mentre lo svuotamento del buffer potrebbe essere comandato esclusivamente dall'elettronica...
lato ricevitore USB, è tutto fatto al volo, o cmq sono presenti sempre dei meccanismi di sincronizzazione/buffering, per esigenze di protocollo?

Menestrello ha scritto:

Telstar ha scritto:
Perché? jitter digitale.

A me questa cosa del jetter digitale mi manda fuori di capoccia

ma che roba è? ma come fa ad interferire?
ma come mai in un flusso dati usb non audio sto jitter digitale non mi rovina i file che per esempio scrivo su una pennetta?
Qualcuno mi sa spiegare perché?

Per saltare un byte il jitter deve essere enorme (tipo 100ns ma forse anche più, inoltre esistono meccanismi di correzione nella copia di file), per SENTIRSI bastano pochi picosecondi.
D'altronde se non puoi confrontare due dispositivi con jitter molto diverso è difficile che lo riconosci. Ma come dicevo prima, hardware e software di un pc usato come meccanica causano O jitter digitale OPPURE rumore nell'alimentazione.

Aggiungo una cosa: se il tuo DAC ha già di suo mettiamo 100ps di jitter (che è un valore mediobuono per schede audio firewire e usb asyncrone), gran parte delle ottimizzazioni che ti migliorano mettiamo di 5ps NON LE SENTI.
Il che non vuol dire che non esistono, ma che non sono rilevanti in quel sistema.
NB: normalmente le schede audio pci e pci-e hanno un jitter molto più basso delle periferiche esterne, per via del protocollo e quindi anche sistemi non particolarmente costosi che usano per esempio una juli@ come dac traggono beneficio da ottimizzazioni hw/software.

madqwerty ha scritto:
chi mi sa fornire link o maggiori dettagli su come funziona il giochino?

Magari si conoscessero tutti i dettagli di come avvengono questi meccanismi! Avresti risolto in anticipo tutti i misteri dello streaming digitale, e penso ci vorranno almeno 10 anni per farlo

I computer poi sono diversissimi l'uno dall'altro, e potenzialmente ogni componente può influire sia dal lato hardware che da quello software (drivers e interazione con il SO). Hmm.... 3 anni fa non mi sarei mai immaginato di parlar come cics, purtroppo però le prove empiriche danno ragione all'esistenza di questi fenomeni degradanti.

l' USB con chi si sincronizza per spedire i dati ?

C'è l'usb sincrono e quello asincrono. I migliori receiver usb stanno sui 50ps di jitter, forse meno.

madqwerty ha scritto:il nostro amico jitter,
come faremmo senza di lui
...
lato ricevitore USB, è tutto fatto al volo, o cmq sono presenti sempre dei meccanismi di sincronizzazione/buffering, per esigenze di protocollo?

Quest'ultima parte non so dire; il manuale sul protocollo USB è piuttosto corposo e in questo momento non ho nessuna voglia di studiarmelo
Mancata sincronizzazione o errori di lettura implicano un 'salto' del dato, quindi un buco nella riproduzione.
Il Jitter è cosa ben diversa

editato il post delle 1:14

Telstar ha scritto:
Per saltare un byte il jitter deve essere enorme (tipo 100ns ma forse anche più, inoltre esistono meccanismi di correzione nella copia di file), per SENTIRSI bastano pochi picosecondi.
D'altronde se non puoi confrontare due dispositivi con jitter molto diverso è difficile che lo riconosci. Ma come dicevo prima, hardware e software di un pc usato come meccanica causano O jitter digitale OPPURE rumore nell'alimentazione.

Mah'...
Ho reti di trasmissione dati in Gigabit e mi preoccupo di un misero flusso audio.

Ma se, e dico se, attraverso la porta USB riesco a mandare un flusso di byte verso un dispositivo come un HD esterno, perché verso un dispositivo audio mi devo preoccupare se questo dato arriva corretto o meno?
Ci penserà il protocollo di comunicazione USB a trasmetterlo e riceverlo correttamente.
E se il protocollo USB per i flussi audio non è in grado di farlo, perché non usare un altro protocollo?

Io parto dal presupposto che il clock del DAC NON è fornito dall'usb, altrimenti stiamo freschi.

Menestrello ha scritto:
ma come mai in un flusso dati usb non audio sto jitter digitale non mi rovina i file che per esempio scrivo su una pennetta?

credo ti manchi qualche tessera del puzzle il problema del jitter riguarda ESCLUSIVAMENTE i processi di conversione D/A e A/D,
il dato digitale (riprodotto o acquisito) deve essere "collocato" nel tempo in modo il più preciso e stabile possibile,

un flusso dati come quello del tuo esempio ha una serie di meccanismi e di protezioni "intrinseche" che una conversione DA o AD non può fisicamente avere..

http://it.wikipedia.org/wiki/Jitter

wasky ha scritto:
Non vi imparanoiate come noi di next con le latenze basse al limite dello 0 ascoltate la musica ragazzi

Parole sante!!!

madqwerty ha scritto:

Menestrello ha scritto:
ma come mai in un flusso dati usb non audio sto jitter digitale non mi rovina i file che per esempio scrivo su una pennetta?

credo ti manchi qualche tessera del puzzle il problema del jitter riguarda ESCLUSIVAMENTE i processi di conversione D/A e A/D,
il dato digitale (riprodotto o acquisito) deve essere "collocato" nel tempo in modo il più preciso e stabile possibile,

un flusso dati come quello del tuo esempio ha una serie di meccanismi e di protezioni "intrinseche" che una conversione DA o AD non può fisicamente avere..

http://it.wikipedia.org/wiki/Jitter

Attento, è proprio questo il punto.
Come dici giustamente tu, il Jitter riguarda solo il processo di conversione D-A (lasciamo perdere l'acquisizione in digitale).
Ma CHI sottopone i dati al converitore? Il PC con il suo flusso USB? Con il suo clock inesatto?
Oppure la realtà è che ci sono due livelli, uno di comunicazione e uno di conversione; la comunicazione si preoccupa di ricevere correttamente tutti i dati del flusso USB, magari appoggiandosi ad un piccolo buffer, e la conversione si preoccupa di sottoporre al chip dac, con un clock preciso (vabbè..speriamo ), i dati ricevuti?
Per quanto mi riguarda, il Jitter è in questo secondo sottosistema e del primo me ne disinteresso.
Ma magari mi sbaglio

a livello di dubbi, direi che siamo perfettamente allineati

wasky ha scritto:ho scordato "non" occupa molta CPU quindi non lo vedi come picco nel task manager

scusami, prometto che appena avrò tempo proverò a leggere quell'articolo, ma in questo momento sto facendo un'altra prova: ho lanciato una compressione audio da .flac ad mp3. questa occupa un pò la CPU più costantemente, quindi vedo l'effetto nel task manager. ho aperto dpc latency durante la compressione, ma la latenza bene o male è quella. mi sarei aspettato, dalla lettura di certi post, che sarebbe schizzata chissà a quale livello.

cioè, se neanche una compressione audio in contemporanea alla riproduzione è in grado di variare significativamente la latenza, a parte il discorso se sia o meno rilevante in riproduzione (secondo me no), di cosa ci stiamo preoccupanto ?

Silver Black ha scritto:Come al solito gli audiofili pensano che il loro audio sia la cosa più complessa del mondo da fare per qualsiasi dispositivo, credono che ci vogliano meccaniche ed elettroniche costose, figuriamoci se un misero PC adibito a "tuttofare" potrebbe compiere questo compito senza impantanarsi! Gli audiofili veri non possono pensare che tutto ciò sia fattibile anche da un banale Pentium 4, sarebbe uno sminuire la riproduzione musicale perfetta!

madqwerty ha scritto:l' USB con chi si sincronizza per spedire i dati ? immagino la CPU non intervenga su ogni byte da trasmettere,
quindi ci saranno dei buffer, il cui inizio trasmissione è magari comandato da CPU (ma inizio asincrono immediato, quindi passibile di jitter, o cmq agganciata ad un clock hardware, ed eseguita nel primo stato di clock valido?) mentre lo svuotamento del buffer potrebbe essere comandato esclusivamente dall'elettronica...
lato ricevitore USB, è tutto fatto al volo, o cmq sono presenti sempre dei meccanismi di sincronizzazione/buffering, per esigenze di protocollo?

La stessa cosa per i trasferimenti di qualsiasi canale dati, anche l'hard disk. La CPU non può seguire il funzionamento byte per byte e preoccuparsi lei che tutto vada bene, per questo c'è il DMA (Direct Memory Access), roba vecchia ma ormai data per scontata, tramite il quale il dispositivo può comunicare direttamente con la memoria senza impegnare la CPU.

Nei videogiochi ad esempio la lettura delle texture da centinaia di MB vengono prelevate dal disco e poi dalla RAM direttamente senza impegnare la CPU! Lo stesso per gli effetti audio e le colonne sonore. La CPU è impegnata al 100% o quasi a fare altro. E non ci sono nè jitter nè latenze quando si gioca (il videogaming è uno tra i compiti più impegnativi se non il più impegnativo).

Saetta McQueen ha scritto:
scusami, prometto che appena avrò tempo proverò a leggere quell'articolo, ma in questo momento sto facendo un'altra prova: ho lanciato una compressione audio da .flac ad mp3. questa occupa un pò la CPU più costantemente, quindi vedo l'effetto nel task manager. ho aperto dpc latency durante la compressione, ma la latenza bene o male è quella. mi sarei aspettato, dalla lettura di certi post, che sarebbe schizzata chissà a quale livello.

cioè, se neanche una compressione audio in contemporanea alla riproduzione è in grado di variare significativamente la latenza, a parte il discorso se sia o meno rilevante in riproduzione (secondo me no), di cosa ci stiamo preoccupanto ?

Bel test, bravo! Ma io ve l'ho detto: con le CPU attuali la riproduzione di UNA SINGOLA (nello stesso istante) traccia audio è un compito elementare che non può metterla in difficoltà, nemmeno se dietro sta facendo un rendering in ray-tracing!

Telstar ha scritto:I computer poi sono diversissimi l'uno dall'altro, e potenzialmente ogni componente può influire sia dal lato hardware che da quello software (drivers e interazione con il SO). Hmm.... 3 anni fa non mi sarei mai immaginato di parlar come cics, purtroppo però le prove empiriche danno ragione all'esistenza di questi fenomeni degradanti.

Anche io nel 2008 ero un pò titubante a seguire cics e abbandonai il discorso poi, conobbi bibo1 e ho approfondito cMP sia su XP che su Seven e i risultati si sentono in set up rilevatori tanto che, ho voluto la sezione su NH dedicata alle estremizzazioni Audio PC

Poi nessuno vieta di usare un Atom o un Notebook con uscita su USB, il massimo rispetto ci mancherebbe ma, non è quella la strada del paradiso imho

E' uscita una nuova versione, si dice sia la più performante fino a questo momento, di fidelizer... stasera la testo e poi vi racconto.
http://www.windowsxlive.net/downloading-fidelizer

Leggo che è giunto alla versione 2.1.

Non l'ho mai utilizzato perchè l'ho scoperto praticamente ora.

Me lo consigliate? Funziona?

roby2k ha scritto:Leggo che è giunto alla versione 2.1.

Non l'ho mai utilizzato perchè l'ho scoperto praticamente ora.

Me lo consigliate? Funziona?

Nell'installarlo a me l'antivirus lo blocca come fosse un trojan ....e non c'è verso di fargli mollare la presa ...mah .....la cosa mi ha sempre lasciato perplesso ...

Arrivato allla versione 6.7.

E sotto il link alla relativa (ed entusiastica) recensione su tnt-audio:

http://www.tnt-audio.com/sorgenti/fidelizer.html


Ovviamente, per chi di interesse   . Personalmente, io sono sempre a:

tasto open --> inserisci il cd --> tasto play = fine   .

pallapippo ha scritto:Arrivato allla versione 6.7.

E sotto il link alla relativa (ed entusiastica) recensione su tnt-audio:

http://www.tnt-audio.com/sorgenti/fidelizer.html


Ovviamente, per chi di interesse   . Personalmente, io sono sempre a:

tasto open --> inserisci il cd --> tasto play = fine   .

Ciao Luca, infatti ti prendo sempre ad esempio di chi fa una scelta saggia e pratica, io invece sono sempre immerso in queste diavolerie... quasi quasi lo provo!

Una domanda, dopo aver scelto il settaggio cioè workstation, extremist ecc si apre una finestra, cosa bisogna fare? Scegliere il player tipo Foobar?