in teoria non vedo perché non dovrebbe funzionare... salvo ovviamente che per il DSD "nativo": quello non può funzionare (dato che l'infrastruttura su cui si appoggia asio4all non supporta quella modalità). Con asio4all puoi usare solo DoP, né più né meno che con WASAPI. Dato che è sempre e comunque attraverso quello che poi devi passare.
Come detto in precedenza, dato che HQPlayer supporta nativamente WASAPI, non vedo il motivo né il vantaggio di metterci di mezzo un altro software (un "middleware") come asio4all, che non fa altro che presentare una interfaccia ASIO verso gli applicativi (come HQP) e poi "girare" dati e comandi (opportunamente "tradotti") verso la reale infrastruttura audio sottostante (WASAPI).
Tanto per capirci, immagina di avere un preamplificatore che ha solo ingressi sbilanciati ed una sorgente (diciamo un CDP) che ha solo uscite bilanciate: per poterli collegare hai bisogno di un adattatore che presenti un ingresso bilanciato verso il CDP ed una uscita sbilanciata verso il pre. Ma se la tua sorgente oltre all'uscita bilanciata ne ha anche una sbilanciata, tanto vale evitare l'adattatore e collegare direttamente i due apparecchi: dato che l'ingresso del pre è comunque sbilanciato, usare una uscita bilanciata non comporta nessun vantaggio (anzi, facilmente potrebbe comportare degli svantaggi).
Il discorso qui è perfettamente analogo: Asio4all non è niente altro che un "adattatore" che permette di "collegare" tra di loro due "apparecchi" che utilizzano standard diversi.
L'unica utilità di asio4all è permettere l'uso di software applicativi che supportano solo ASIO con hardware che non dispongono di quel tipo di driver (nativi). Dato che HQPlayer non ha questo problema (oltre ad ASIO supporta nativamente anche WASAPI) è sicuramente meglio utilizzare direttamente l'interfaccia nativa, senza metterci niente altro di mezzo...
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
Grazie UnixMan, so anche io quello che fa Asio4all, e in teoria dovrebbe essere controproducente preferirlo a wasapi, ma ti posso assicurare, che nel mio caso, con hqplayer e bug head, suona divinamente!!! wasapi a confronto suona più scuro, come se ci fosse un velo di mezzo.
Penso che il miglior modo per interfaciare il mio dac potrebbe essere quello di utilizare un cubox tramite cavo incrociato.
Saluti
bit32
Ultima modifica di bit32 : 22-03-2017 a 14:50
che, sarà un caso, è la classica descrizione di un sistema 'tirato' nella gestione di buffer e latenze rispetto ad uno più 'tranquillo', probabilissimo che sia così ed ormai sappiamo che è un effetto che a molti piace (io lo odio!). Ho pubblicato proprio qui tempo fa un semplice programmino che giocando sui due parametri provoca esattamente questo effetto, ovviamente sempre mantenendo l'assoluto bit perfect.
Ciao, Marco.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
— E. F. Schumacher (mis-attributed to A. Einstein)
________________________________________________________________________________
Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE
Anche secondo me il motivo è proprio quello...
Con wasapi non è possibile configurare un buffer, e quindi avere una latenza di almeno 200 ms, che a livello di ascolto (non registrazioni) secondo me è migliore di una soluzione tirata, con piccoli buffer dove la cpu fatica a comunicare con il dac, quindi questo potrebbe portare ad una resa a livello uditivo (per i miei gusti) qualitativamente inferiore.
Saluti
bit32
Ecco la risposta di Miska (che m'immaginavo) al tuo problema con ASIO4ALL:
ASIO4ALL and JPlay need fixing. Other ASIO drivers don't crash.
Don't use ASIO4ALL, but use WASAPI instead if proper ASIO driver is not available...
I buffer più "critici" - quelli utilizzati nella comunicazione tra PC e DAC via USB - sono gestiti dal sistema e/o dal driver vero e proprio dell'interfaccia. Perciò i casi sono due:
1) tali buffer sono configurabili (e.g. attraverso le impostazioni di WASAPI);
2) tali buffer non sono configurabili, ed in tal caso ASIO4ALL non può farci un bel niente.
Nel primo caso deve esserci modo di farlo direttamente, senza bisogno di usare asio4all.
Nel secondo caso asio4all al più può introdurre un ulteriore buffer intermedio, tra il player e WASAPI. Dell'utilità di un tale buffer intermedio dubito fortemente, ma comunque sarebbe del tutto equivalente ad aumentare le dimensioni del buffer di uscita del player stesso.
BTW: non ricordo: il buffer di uscita di HQPlayer è configurabile? Se lo è, sai dove puoi provare ad agire...
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
bibo sarebbe utile sapere se è a conoscenza di problemi con i driver ASIO delle EMU...
Mai avuto problemi nemmeno con HQplayer e Win 7 32bit. Poi sono passato a Win 10 64bit (ho provato anche con WServer 2012r2 e 2016) e HQPlayer (con e senza NAA, sia a 32 sia 64 bit), va in crash.
Con foobar2000 tutto ok.
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando
