Certo, in Ravenna Easy Connect, che è il software deputato al collegamento tra hapi da un lato e "Asio hosts" dall'altro, ci sono sia ingressi che uscite.
Vedi sotto:
http://dt7v1i9vyp3mf.cloudfront.net/...&itok=YlxLYdeW
Printable View
Certo, in Ravenna Easy Connect, che è il software deputato al collegamento tra hapi da un lato e "Asio hosts" dall'altro, ci sono sia ingressi che uscite.
Vedi sotto:
http://dt7v1i9vyp3mf.cloudfront.net/...&itok=YlxLYdeW
Allora forse - ripeto, FORSE - con uno di quei programmi puoi intercettare l'output di HQPlayer ad es. su OUT-9 e OUT-10, rimapparlo su IN-1 e IN-2, e poi mandarlo in uscita su OUT-1,3,5,7 e OUT-2,4,6,8.
L'ostacolo potrebbe essere che ASIO Ravenna è single session.
in quel caso ovviamente avrebbe senso ma, nel vostro, è una follia.Quote:
Originariamente inviato da grunter
Vai di Jack, che è la soluzione migliore.
In alternativa puoi cercare qualche altro software che possa fare quello che ti serve (upmix virtual ASIO in -> ASIO out). Ad es. qualcosa del genere: VB-Audio VoiceMeeter Banana
P.S.: se c'è una cosa che Miska potrebbe/dovrebbe fare, è implementare direttamente l'uscita su AES67/Ravenna in HQPlayer. ;)
...potrebbe utilizzare lo stesso protocollo anche tra HQP ed NAA.
Roberto aveva sperimentato in passato con asiobridge (sempre di vbcable) solo che non tratta flussi dsd.
Inoltre bisogna vedere se Ravenna riesce a riconvogliare il flusso dsd in uscita da hqplayer verso jack e poi riprenderlo nuovamente in entrata... la vedo un pò dura ma mai dire mai.
Dispiace avere la soluzione quasi a portata di mano con hqplayer ma al tempo stesso sentirsi dire che è meglio fare upsampling separato di 8 canali ;sadlike
Ho detto a Miska che mi sembra un approccio stile forza bruta, di solito i programmatori si scervellano per ottimizzare il codice non per far vendere alla intel cpu ultracostose....
Riassumendo, sia Merging che Jussi non hanno intenzione al momento di cambiare le cose per i nostri scopi. Le alternative sono:
- scriversi un semplice player da linea di comando che fa upsampling: è fattibile perché ci sono esempi di codice di ASIO host, però occorrerebbe ricostruire cosa fa poly-sinc-mp + ASDM7... quest'ultima parte la vedo dura visto che non ci sono white paper di Jussi.
- convincere Jussi a permettere di usare i suoi filtri in modalità offline, cioè produrre il DSD dal PCM su file in modo offline e poi suonare il DSD; ma non credo che accetti (ho amici finlandesi e la loro flessibilità è nulla, ma hanno tante altre qualità) e comunque ogni volta occorrerebbe fare conversione offline. Tra l'altro ho provato a farlo offline con AuI ConverteR ma il risultato di questo filtro è inferiore a quello ottenuto da Jussi con poly-sinc-mp + ASDM7.
- scriversi un wrapper per ASIO Merging Ravenna che appare come un ASIO driver a due canali, che li intercetta e ne fa upmix, spedendoli agli 8 canali dell'ASIO Merging Ravenna: anche qui ci sono esempi di sorgente nelle SDK di ASIO, per tirare fuori qualcosa ci vorrebbe circa un mese a tempo pieno (che non ho purtroppo): in fondo è l'idea dell'ASIO bridge, solo che il problema che vedo è l'introduzione di un ulteriore livello di buffering, che non mi piace.
Francamente mi accontento per quello che ho adesso, hai sentito anche tu che la qualità è già molto elevato così. In attesa che gli 8 core diventino economici (secondo me entro un anno) o che Jussi ottimizzi il codice, la prendo con filosofia e mi godo la musica :)
P.S. Anch'io sento differenza tra 7.1 e 16 canali, boh, è un mistero... ma questa è un'altra storia.
P.S. 2 C'è un concorso per vincere un Hapi. Le possibilità sono poche, però perché non tentare? :)
http://www.soundonsound.com/competit...xcept-americas
se usate HQP su Linux, il problema è facilmente risolvibile: basta creare un "device" di uscita virtuale su ALSA che scrive su file, selezionate quello come dispositivo di uscita per HQP, mandate in play... e vi ritrovate il file convertito. ;)Quote:
Originariamente inviato da robertopisa
Per il resto, è il solito problema con le soluzioni proprietarie... flessibilità zero. Puoi fare solo quello che il produttore ha deciso di lasciarti fare.
P.S.: temo che il mio suggerimento di usare Jack non sia applicabile: dimenticavo il "piccolo dettaglio" che usate DSD... mentre (se non vado errato) temo che jack supporti solo PCM.
Stai dicendo che tramite Linux è possibile fare upsampling a dsd256 offline? Interessante.Quote:
Originariamente inviato da UnixMan
Resta il fatto/problema che usando il channel mixer da 2 a 8 canali non si riesce a riprodurre senza problemi nemmeno il dsd nativo.... per il solito problema che vengono fatte 8 decodifiche dsd separate..... arghhhhhhhh arghhhhh
Sinceramente certe scelte mi sembrano ottuse, Josef e Marcin di Jplay si sono sempre dimostrati aperti a tante soluzioni e hanno fatto sempre di tutto per interfacciare al meglio il proprio programma, Miska non è altrettanto aperto.
O essere tra i primi a supportare AVB.Quote:
Originariamente inviato da UnixMan
Nemmeno questa soluzione risolverebbe nulla come stavo dicendo sopra. Sembrerebbe fattibile su Linux, stando a quanto dice Unixman, fare upsampling dsd256 offline, ma a causa del fatto che il channel mixer è a monte dello stage di codifica/decodifica non riusciremmo comunque a far funzionare il tutto perchè si fanno 8 decodifiche separate via asio, operazione che evidentemente è comunque molto cpu/demanding....Quote:
Originariamente inviato da robertopisa
Però questo conferma che hqplayer non è ottimizzato affatto, mi immagino infatti che stando così le cose riprodurre un dsd256 nativo multicanale sia praticamente infattibile se non usando appunto cpu top di gamma
Hano due approcci completamente diversi.Quote:
Originariamente inviato da grunter
Miska vuole il controlo su tutto (ancora si pena ad avere le API per interfacciare minimamente il player) mentre JPLay da subito ha fatto della sola riproduzione la sua mission, presentandosi cone un driver di periferica e quindi dipendendo totalmente da altri per tutti gli altri compiti, ma sfruttandone le caratteristiche.
Al di là di aspetti qualitativi - sia sonori che realizzativi - su cui non entro, il primo approccio è molto oneroso e porta a un dispendio di risorse molto maggiore ogni qual volta si debba inserire la pur minima modifica, il secondo è 'opportunista', molto più leggero ed agile.
Essendo entrambi progetti proprietari, per mantenere la stessa flessibilità di JPLAY, Miska dovrà spendere molto più in manutenzione, se fossero prodotti direttemente concorrenti (e non lo sono) senza dubbio JPLAY risulterebbe vincente.
p.s. Dall'esperienza provata sul commander, Miska usa un SDK proprietario per sviluppare, che pone limiti non indifferenti per la distribuzione del software, credo che molto della strutura monolitica di HQP derivi anche da li.