TEST: RamDisk e HQPlayer

Pagina 5 di 18
prima
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... ultimo
Visualizzazione dei risultati da 41 a 50 su 179
  1. #41
    nibble
    Registrato
    Dec 2014
    Messaggi
    68

    Predefinito

    Test effettuato con softperfect ramdisk (freeware) e con ottimi risultati nei test di lettura scrittura.
    configurazione: seven naa cubox hq 3.6.1
    ho creato un ramdisk da 100 mb e vi ho installato hq, su di un altro da 1024 ho copiato con drag and drop la musica da media jukebox.
    confermo la migliore fluidità della musica edun maggiore tempo di decadimento armonico.
    al riavvio risultano cancellate sia installazione di hq che la musica.
    nessun problema con il riconoscimento del naa

  2. #42
    tebibyte
    Registrato
    Dec 2010
    Località
    Cagliari
    Messaggi
    2,403
    configurazione

    Predefinito

    Qualche altro particolare.
    Intanto, per quanto mi riguarda e so di non essere il solo, non uso la gestione della libreria di HQ ma lavoro in drag&drop per cui il caricamento del brano o dell'album dall'HDD di storage al ramdisk e il successivo trasferimento ad HQ non occupa più di 5 secondi.
    Con 1 GB di RAMdisk sul server mi stanno comodamente HQplayer (circa 45 mb) e due o tre album, che è la dose giornaliera di solito ascoltabile. Ma la cancellazione immediata dal ramdiskdell'album da sostituire e la sua sostituzione occuperà comunque solamente i soliti 5 secondi con il drag&drop. Mi studierò il programma per vedere di conservare l'installazione di HQ sul ramdisk ma anche in questo caso, una volta messo sul desktop il file .exe della versione desiderata, in avvio l'installazione è cosa di trenta secondi circa, manco la pena di andarsi ad incasinare l'esistenza ulteriormente. Certo che gli informatizzati comodi, con sistemi più complessi con tanto di comandi in remoto, gestioni delle librerie più strafighe, ipad e compagnia cantante si dovranno sbattere un po' di più ma è il prezzo della comodità rispetto ai sistemi "for dummies" come il mio, privo di bagno e con la baracca della turca in giardino
    Comunque sia questa è una figata megagalattica, altrochè!!! Goduria allo stato puro!

  3. #43
    Moderatore L'avatar di bibo01
    Registrato
    Oct 2010
    Messaggi
    4,591
    configurazione

    Predefinito

    Originariamente inviato da Paride1
    Test effettuato con softperfect ramdisk (freeware) e con ottimi risultati nei test di lettura scrittura.
    configurazione: seven naa cubox hq 3.6.1
    ho creato un ramdisk da 100 mb e vi ho installato hq, su di un altro da 1024 ho copiato con drag and drop la musica da media jukebox.
    confermo la migliore fluidità della musica edun maggiore tempo di decadimento armonico.
    al riavvio risultano cancellate sia installazione di hq che la musica.
    nessun problema con il riconoscimento del naa
    Vedo che hai provato con Softperfect Ramdisk.
    Hai provato anche con Primo Ramdisk? Noti differenze?
    A mio parere, come si dice, not all ramdisks are created equal!

    Tornando alla proposta per Miska, non è una cosa immediata come sembra... Primo, l'applicazione dovrebbe essere sviluppata per le 3 piattaforme; secondo, una partnership con Primo sarebbe possibile ma Primo è solo per Windows;....

  4. #44
    tebibyte
    Registrato
    Aug 2011
    Età
    50
    Messaggi
    2,928
    configurazione

    Predefinito

    Originariamente inviato da bibo01
    Vedo che hai provato con Softperfect Ramdisk.
    Hai provato anche con Primo Ramdisk? Noti differenze?
    A mio parere, come si dice, not all ramdisks are created equal!

    Tornando alla proposta per Miska, non è una cosa immediata come sembra... Primo, l'applicazione dovrebbe essere sviluppata per le 3 piattaforme; secondo, una partnership con Primo sarebbe possibile ma Primo è solo per Windows;....
    Perché una collaborazione con primo? non si raggiungerebbe lo stesso risultato se il programma caricasse la playlist nella ram prima di andare in play? che poi sarebbe anche la strada piú comoda?!

  5. #45
    Moderatore L'avatar di bibo01
    Registrato
    Oct 2010
    Messaggi
    4,591
    configurazione

    Predefinito

    Originariamente inviato da antonellocaroli
    Perché una collaborazione con primo? non si raggiungerebbe lo stesso risultato se il programma caricasse la playlist nella ram prima di andare in play? che poi sarebbe anche la strada piú comoda?!
    Certo, l'idea è quella di mettere la playlist o parte di essa in RAM, ma la gestione della RAM non è uguale tra differenti ramdisks e credo possa differerire da piattaforma a piattaforma.

  6. #46
    mebibyte
    Registrato
    Aug 2012
    Località
    Milano - Varese
    Messaggi
    606
    configurazione

    Predefinito

    Tanto per "inquinare" un po' il thread con le Mele ... Giusto appunto un post fresco fresco da CA con uno script che crea due RAMdisk, dove in uno viene copiato l'eseguibile HQP mentre l'altro lo si usa per metterci la musica ... qui ...

    Anche se la gestione della memoria su OS X non e' riservata come nel caso Win, il risultato l'ho sempre apprezzato a partire da Maverick.

    Un cordiale saluto, Massimiliano

  7. #47
    kibibyte L'avatar di Maggio
    Registrato
    Nov 2013
    Messaggi
    376

    Predefinito

    Originariamente inviato da bibo01
    Tornando alla proposta per Miska, non è una cosa immediata come sembra... Primo, l'applicazione dovrebbe essere sviluppata per le 3 piattaforme; secondo, una partnership con Primo sarebbe possibile ma Primo è solo per Windows;....
    Basterebbe, inizialmente, che HQPlayer leggesse da RamDisk (creata su ogni sistema in modo indipendente e con differenti software).
    Questo non dovrebbe essere troppo complicato e sarebbe possibile su tutte le piattaforme

  8. #48
    kibibyte L'avatar di pocarrie
    Registrato
    Feb 2012
    Età
    56
    Messaggi
    262
    configurazione

    Predefinito

    Originariamente inviato da Paride1
    al riavvio risultano cancellate sia installazione di hq che la musica.
    Se si usa Primo Ramdisk, è possibile evitare tale inconveniente settando le impostazioni in fase di installazione come ai punti 8 e 9 di questa guida (che tra l'altro contiene anche dei consigli utili su come sfruttare il sotfware per mettere le variabili d'ambiente di Windows TEMP/TMP, e la cache dei browser, nel Ramdisk, così da velocizzare le prestazioni del sistema; ulteriori spiegazioni in italiano qui); altrimenti, il Ramdisk verrà cancellato ad ogni riavvio del sistema operativo.

    Questa possibilità però non c'è nella versione trial 30 gg, ed anzi a pagamento esiste solo dalla versione Pro in su (tabella comparativa).

    Qui potete vedere i prezzi delle varie versioni (tenendo presente che a volte si spendono centinaia di euro per cavi o accessori ultraesoterici dall'efficacia perlomeno dubbia...)

  9. #49
    kibibyte L'avatar di pocarrie
    Registrato
    Feb 2012
    Età
    56
    Messaggi
    262
    configurazione

    Predefinito

    Dimenticavo: nei vostri test comparativi, verificate le differenze

    a) fra HQP avviato da C:\ e avviato dal Ramdisk;
    b) fra i brani caricati in HQP dal normale percorso oppure dal ramdisk (previa copia temporanea),

    il tutto però
    c) verificando se ci sono differenze fra l'ascolto
    c1) con collegamento diretto pc>dac, oppure
    c2) interponendo un NAA (per chi lo usa).

    P.S.: se ho tempo oggi pomeriggio vi svelo qualche piccolo trucchetto per velocizzare la copia temporanea dei files in ramdisk prima di ascoltarli in HQP... stay tuned...

  10. #50
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Ciao a tutti,

    tutto quanto leggo qui è allineato con esperienze dirette fatte con JRiver ed altri sistemi: il preload in RAM dei brani da riprodurre ha effetti (normalmente) benefici, immagino che lo stesso principio valga per il software, anche se credo che qualsiasi moderno PC dopo pochi cicli abbia già in RAM l'immagine di suo, visto che parliamo di 30MB.

    Una delle cose che ho sperimentato personalmente è che lavorare sulla dimensione del buffer di riproduzione aumentandolo molto, non garantisce lo stesso risultato, anzi, a volte peggiora la situazione ed il motivo è semplicemente intuibile: il buffer per sua natura si svuota e viene ririempito dai due processi, resi asincroni ma contemporanei, di lettura e scrittura, il ram disk no, viene riempito all'inizio PRIMA dell'inizio della riproduzione e successivamente 'consumato (ma non vuotato) dal processo di lettura: il profilo di attività è molto più basso e lineare in fase di riproduzione. Per un motivo analogo in alcuni sistemi e configurazioni sono da alcuni (io tra questi) percepite differenze di riproduzione tra FLAC (o formati compressi in generale) e PCM.

    Quanto sopra, ovviamente, prevede di riservare a questo scopo una porzione di RAM corrisponendte almeno alla dimensione dei files musicali che si vogliono riprodurre gapless (tipicamente un album) quindi dai 700 Mb ai 2GB in risoluzioni 'umane'.

    Fino a qui le mie esperienze, ma pochi giorni fa, leggevo in un altro THD sull'hw per NAA alcuni interventi, tra cui quello di Audiodan qui citato:


    Originariamente inviato da audiodan
    ...Il motivo dell'influenza della RAM e soprattutto della sua attività elettrica è la sua contiguità con il processore e perciò è stato ipotizzato che l'influenza dei disturbi elettrici derivati dalla sua attività vadano ad interferire con quelli derivanti dal processore. Che il downvolting della RAM abbia benefici sulla SQ è un fatto facilmente sperimentabile, così come lo stesso effetto si ottiene con la riduzione non solo del numero fisico dei banchi ma anche mediante l'inattivazione via software di parte della memoria (aprite msconfig e nella pagina boot cliccate su advanced e li sbizzarritevi a cercare la "pezzatura" più idonea. Questo è stato vero fino ad ora anche grazie al fatto che HQ player non utilizza RAM per il suo funzionamento (30 MB! non capisco come ma a stare a quanto segnalato da Task Manager è così) ma "un fantasma si aggira per l'Europa"! Non c'entra Karl Marx, si chiama RAMdisk! Proprio in questi giorni, in mezzo alla marea di cose che faccio e pianifico, stavo iniziando a pensare di metterci mano e zac, pocarrie posta il thread proprio ieri! Non appena finisco di capire cosa fare dell'Amanero e appena ricevuto il nuovo HW questo sarà il prossimo step, che non vedo perchè non possa riguardare anche il NAA. Insomma un banco da 1 o da 2 GB (ridotto o meno che sia, 8.1 64 bit funziona perfettamente con soli 700 MB di RAM) e un altro banco da 2 GB per il RAM disk ( ma anche qui per ascoltare i FLAC basta e avanza 1 GB) dovrebbero essere sufficienti sia sul server che sul NAA...
    Al che rimango abbastanza confuso.

    Capisco che si possa trattare di una scelta tra il mare minore (più ram per contenere il RAM disk vs. RAM minma) e che le preferenze di Audiodan vadano in quel senso, con accorgimenti quali il downvolting (io aggiungereri almeno l'adozione di banchi schermati o blindati), probabilmente la strada corretta per HQP (e non solo) in configurazione stand alone, ma non capisco come questo possa influire in configurazioni server + NAA.

    Mi spiego:

    Il server 'legge' il file e lo trasforma in uno stream, eventualmente applica conversioni e DSP, quindi lo invia sotto forma di paccheti al NAA , che lo riceve, ricostruisce lo stream e lo bufferizza in un FIFO da cui attinge il processo di riproduzione.

    Ora, che le attività del server (upsampling, DSP,...) risultino ottimizzate se eseguite in RAM è probabile, ma non credo che questo abbia un'influenza 'significativa' sulle attività a valle, così come - se il server è posto ad adeguata distanza - direi si possano escludere a priori influenze indirette.

    Sono portato a credere che l'influenza dell'utilizzo di RAM disk sul server sia paragonabile a quella dettata dall'utilizzo di storage su supporti locali, USB, SATA o condivisioni di rete, a mio avviso praticamente nulla, ma ne abbiamo già discusso altrove, non fosse così, il fatto sarebbe da considerare attentamente in qualsiasi ambito distribuito e riaprirebbe non pochi discorsi.

    Qualcuno ha esperienze/motivazioni (a supporto o discredito) in merito?

    Oltre a questo, o il protoccolo di comunicazione tra Server ed NAA è realizzato in modo da consentire il completo trasferimento dell'album al FIFO di NAA PRIMA dell'inizio della riproduzione, o non si avrà mai una situazione 'tipo' ramdisk in riproduzione, ma solo una a buffer, con tutti i benefici e problemi indotti del caso.

    Posto che questa possibilità esista (ma non ne sono edotto) o meno, già attualmente ove il NAA non sia costretto a paginare il contenuto del FIFO, sono portato a credere che la riproduzione avvenga da RAM, quindi un RAM disk risulterebbe ininfluente se non dannoso, salvo l'opportunità di eseguire il daemon diettamente da ramdisk, ma - ripeto - secondo me già attualmente è caricato in memoria dopo pochi cicli, vista la sua minima dimensione.

    Anche in questo caso mi piacerebbe sentire motivazioni/esperienze in merito.

    EDIT: Sarebbe interessante capire quel'è l'attività di I/O su NAA (es. cubox) dovuta al caricamento del software e/o alla paginazione del FIFO con e senza RAM DISK, se fosse significativa... Huston abbiamo un problema!

    Ciao.

    Grazie.
    Ultima modifica di marcoc1712 : 10-02-2015 a 13:31 Motivo: Aggiunto EDIT

Pagina 5 di 18
prima
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022