AWE in cPlay

[GasVanTar]

Non sono riuscito a capire cosa fa esattamente questa funzione e a dire il vero non sono certo di averla attivata o meno.
Avendo XP Home non ho potuto eseguire la procedura per impostare i privilegi LOCK, però nonstante questo settando AWE su si in cPlay mi sembra che funzioni lo stesso. Dico mi sembra perchè non sono sicuro di cosa faccia, quello che noto è che utilizzando questa funzione, dal task manager di windows vedo il valore totale di memoria utilizzata che cresce in base alle dimensioni del file che scelgo di riprodurre mentre il processo cicsPlay.exe utilizza mediamente pochi MB, a volte meno di due.
Viceversa se non utilizzo AWE, anche il singolo processo utilizza tanti MB quanti sono quelli del file audio che ho scelto. Questa è l'unica differenza che ho notato, ma in pratica l'utilità di AWE si limita a questo? O invece non ne ho capito niente?
In sostanza che vantaggi ci sono utilizzando AWE in cPlay? E se non fossi riuscito ad attivarla correttamente per via dei privilegi LOCK mi suggerireste il modo per farlo?

P.S. Utilizzando l'utilità di diagnostica prima di iniziare la riproduzione tra le altre cose mi vengono indicate queste ultime:
AWE sucessful

RAM allocation (...MB) successful

DSP track loader thread started

DSP Started.

Play starts after RAM load (available ...MB, system 894MB).
Volume ( 0.0db, phase 0)
SRC (1, 96000)

[bibo01]

Se la diagnostica dice che AWE ha avuto successo allora sei a posto.
Task manager non ti da' le informazioni giuste.
Cmq, AWE evita appunto che sia Windows ad affidare la memoria e mantiene la RAM in un unico blocco.

[GasVanTar]

grazie Bibo mi hai rassicurato.

[GasVanTar]

Ciao Audiodan, una tua considerazione espressa su un post nel forum di VHF mi ha particolarmente incuriosito: "l'AWE (Address Extensions Windowing che permette il caricamento in RAM del file decompresso e con upsampling già calcolato)".
Spiegheresti cortesemente cosa intendi per upsampling già calcolato?

[audiodan]

In pratica, al momento della selezione, il processore non solo processa il file per decomprimerlo, se in flac ovviamente, ma effettua anche l'upsampling per cui, sulla RAM tu trovi un file wave a 24/xx, a seconda delle scelte fatte. Se fai caso alla fine del titolo spesso compare un numero tra parentesi.Questo è il numero degli split in cui viene suddiviso il file per il caricamento in RAM. Più è spinto l'upsampling maggiore sarà il peso del file e, conseguentemente, il numero di split in cui verrà suddiviso.
A questo punto voglio ricordare una perplessità che mi sorse in seguito alla comparsa del primo dei supertweaks, ovvero la riduzione via software della memoria utilizzata.
Come sapete aggiungendo alla stringa di boot.ini la dizione MAXMEM=xx si pò dare istruzioni al SO di non utilizzare uno spazio maggiore di quanto impostato. Dalle esperienze da me fatte fu chiaro che più era basso il valore e migliore era il risultato sonoro, tanto che ho lasciato ormai da tempo immemore il valore MAXMEM=256.
Però, poichè io trovo vantaggioso ascoltare con upsampling a 24/192, il numero di split aumenta a 7 e più per brani lunghi, con conseguenti plurimi azionamenti dell'HDD esterno che si mette in moto per trasferire i dati al processore, ovverodicasi: durante la riproduzione si avrà attività sia dell'HDD che della CPU! ERESIA!! Da qui è nata la necessità di testare coin attenzione la qualità sonica delle diverse modalità che, alla fine, hanno visto vincitrice quella che teoricamente non dovrebbe esserlo, ovvero maxmem=256, senza che la rapidissima attività dell'HDD edel processore influenzassero in qualche modo la qualità dell'ascolto, almeno nella mia esperienza.
Questa è stata la base perchè capissi quanto la RAM, la sua pezzatura, il suo undervoltaggio e il suo timing sia veramente la parte più influente del sistema nell'ottenimento di un buon risultato finale. In ogni caso è molto semplice provare ad ascoltare il risultato di un facile editing del file boot.ini variando solo il numero della memoria utilizzabile, partendo da 1000 a scendere. E' questo un altro modo di fare fine tuning molto avanzato ed efficace. E' anche utile per verificare se dico fregnacce o no

[bibo01]

Per la cronaca, Foobar e JRiver quando caricano il FLAC in memoria, al contrario di cPlay, lo decomprimono "al volo", cioè la cpu lavora continuamente, anche se poco, durante la lettura del file. Per cui, mentre in cPlay la cpu manda una spike per un iniziale utilizzo intenso, in Foobar le manda continuamente durante tutta la lettura.

[GasVanTar]

Grazie ad entrambi per i rispettivi interventi. L'istruzione maxmem=xx nel boot.ini è uno dei tweaks a cui ho dovuto rinunciare poichè per l'uso che faccio del pc, che non è esclusivamente da sorgente audio, il solo GB di ram che ha mi serve tutto.
Una cosa però mi lascia perplesso, se cPlay carica in ram il file già "upsampled", perchè durante la riproduzione di un file a 44.1 kHz noto una percentuale maggiore dell'attività del processore rispetto alla riproduzione di un file a 96 kHz che corrisponde al rate selezionato nel player per l'upsampler?

[bibo01]

Posso provare a rispondere anche se bisognerebbe controllare il tuo caso specifico in dettaglio.
Se ho ben capito, tu fai l'upsample a 96kHz e ti sembra che durante la lettura di un file a 44.1 + upsampling online ci sia un utilizzo maggiore di cpu rispetto ad un file a 96kHz puro.
Per prima cosa bisognerebbe fare questa verifica sullo stesso file; cioè, ad es. fare l'upsampling offline del file 44.1 e confrontare l'utilizzo della cpu sul file upsamplato offline a 96 con quello a 44.1 con upsampling online. Ovviamente, con il medesimo resampler, ad es. SOX.
Poi, può darsi che il sistema abbia bisogno di più memoria per il file a 44.1 + upsampling online e che quindi questo sia suddiviso in più letture rispetto a quelle del file a 96 kHz puro.
Può anche essere d'aiuto verificare tramite Diagnostica quanta RAM viene allocata per il playback.

[GasVanTar]

Ciao Bibo, questo è il report di diagnostic riproducendo un file da 44.1 kHz, nel task manager il processo cicsPlay.exe utilizza circa il 20% di cpu:

AUDIO source [ G:\audio\WMP11 test\Pink Floyd - The Wall (44.1kHz).wav ]
Genre = Unknown
Artist = Pink Floyd - The Wall (44.1kHz).WAV
Album = WAV

FILE: G:\audio\WMP11 test\Pink Floyd - The Wall (44.1kHz).WAV
Wav file size = 88MB
Rate = 24/44100 (2 channels)
Samples = 15491276 ( 5:51)

AWE sucessful

RAM allocation (121MB) successful

DSP Started.

Play starts after RAM load (available 566MB, system 1014MB).
Volume ( 0.0db, phase 0)
SRC (1, 96000)


mentre quest'altro è il report di quando riproduco un file da 96kHz, in questo caso l'utilizzo di cpu è di circa il 3-4%:


AUDIO source [ G:\audio\WMP11 test\Pink Floyd - The Wall.wav ]
Genre = Unknown
Artist = Pink Floyd - The Wall.WAV
Album = WAV

FILE: G:\audio\WMP11 test\Pink Floyd - The Wall.WAV
Wav file size = 192MB
Rate = 24/96000 (2 channels)
Samples = 33722505 ( 5:51)

AWE sucessful

RAM allocation (260MB) successful

DSP Started.

Play starts after RAM load (available 368MB, system 1014MB).
Volume ( 0.0db, phase 0)
SRC (1, 96000)

[bibo01]

Per prima cosa - e mi rivolgo anche a Daniele - io dubito che l'upsampling di un file venga effettuato preventivamente, cioè durante il caricamento in memoria. A mio parere viene effettuato in memoria al volo. Per questo motivo l'uso di un resampler come SRC, che richiede parecchie risorse per il calcolo, mantiene alto l'uso della cpu per tutto il brano.
Ciò si evince anche dal rapporto di Gaspare dove, quando SRC è utilizzato, l'uso della cpu è al 20%.
Inoltre, questo è confermato dal fatto che qualsiasi resampler impiega tempo per il calcolo e sarebbe impossibile che un brano di 3min sia resemplato a 96kHz in pochi secondi, il tempo dell'iniziale caricamento in memoria.
Per conferma basta prendere un brano di 20sec e fare l'upsampling con SRC. Se l'utilizzo della cpu è al 20% o più anche per uno spezzone così corto, quindi neanche per la prima porzione, il resampling viene sempre calcolato al volo. ....Prova Daniele!