Merging Hapi

Pagina 9 di 21
prima
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ... ultimo
Visualizzazione dei risultati da 81 a 90 su 207
  1. #81
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da grunter
    L'unico problema potrebbe essere far vedere Jack a Asio Ravenna,
    ?

    immagino sia casomai il contrario: "Ravenna" nel tuo caso è una uscita, quindi è jack che deve vederlo e non viceversa.
    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.»

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

    Predefinito

    Sono quasi certo che l'upmix/channel mapping sia fatto dopo la conversione. Comunque, ho chiesto conferma a Miska. Vi faccio sapere.

    A mio avviso un possibile problema, quindi un rallentamento delle prestazioni, può essere dovuto al traffico Ethernet rappresentato da 8ch DSD256.
    Ciascun segnale stero DSD256 è 2,7 MB/s. Quindi 8 canali sono 10,8 MB/s.

    Inoltre, avete provato con i modulatori in versione "256+fs" (studiati per queste frequenze) ed anche con i filtri in versione -2s? HQPlayer ce la fa oppure no? Qual'è il risultato all'ascolto?

  3. #83

    Predefinito

    Concordo, sfondi una porta aperta purtroppo. Avevo scritto una mail a Jussi in cui riportavo il carico della CPU per la beta 3.8.0, vedi sotto. Con la 3.8.1, il consumo di CPU è ancora più alto...


    ...
    The CPU load in my i7 CPU is 2% when playing DSD, independently from the fact that it is DSD64, DSD128 or DSD256. Instead, when pipeline setup is enable (just copying channel 1 to 3, 5, 7, and channel 2 to 4, 6, 8, no other processing), the CPU load becomes 21% for DSD64, 43% for DSD128, and over 65% for DSD256: the last one cannot be played as it skips. Please note that no processing is applied, just copying channels.
    ...


    Originariamente inviato da UnixMan
    Che fare "upmix" (che poi in questo caso è banalmente un "channel mapping" o "routing" che dir si voglia) consumi risorse, specie di CPU, mi pare a dir poco strano: si tratta semplicemente di "mappare" (copiare) uno stesso stream di dati su "n" canali di uscita anziché su uno solo, operazione che al più dovrebbe comportare il consumo di una modestissima quantità di memoria per i buffer aggiuntivi ed un numero trascurabile di cicli di CPU per copiare e trasferire i dati.

    Ci deve essere qualcosa che non va come dovrebbe: non è che per caso HQP effettua l'upmix prima dell'upsampling (anziché dopo, come dovrebbe essere) e quindi poi si ritrova a dover fare upsampling su 8 canali anziché su due soltanto, moltiplicando enormemente (ed inutilmente) il consumo di risorse?

    P.S.: non è possibile far effettuare la mappatura/duplicazione dei canali ("upmix") direttamente al "Hapi"? In questo modo oltre tutto si risparmierebbe un mucchio di traffico inutile sulla rete.

  4. #84
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da bibo01
    un possibile problema, quindi un rallentamento delle prestazioni, può essere dovuto al traffico Ethernet rappresentato da 8ch DSD256. Ciascun segnale stero DSD256 è 2,7 MB/s. Quindi 8 canali sono 10,8 MB/s.
    mmh, potrebbe anche essere. Per un trasferimento dati "standard" TCP/IP su ethernet un flusso del genere non sarebbe certo un problema (trasferisco spesso flussi di dati a 100Mb/s o anche di più senza che ci sia alcuna ripercussione significativa sul sistema... anche su macchine molto meno "giovani" e performanti delle vostre) ma, date le sue peculiari richieste in termini di latenza, ecc, per AES67 (AKA Ravenna) le cose potrebbero essere sensibilmente diverse. Non dovrebbe essere difficile vedere chi sta usando risorse e dove / per cosa.

    edit: che tipo di interfaccia di rete usate per l'uscita AES67? qualcosa di "dedicato" o una NIC generalista?
    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.»

  5. #85

    Predefinito

    Se posso essere franco e diretto, credo che Jussi ci capisca molto di audio digitale e poco di programmazione avanzata
    I suoi filtri audio sono fantastici, ma avrei molto da ridire sul suo sw se me lo portasse come progetto a un esame.

    Originariamente inviato da giordy60
    quando " schiacci l'acceleratore delle prestazioni " è inevitabile mettere in evidenza i difetti ( oltre che i pregi ), sta a noi correggere i primi per godere a pieno dei secondi

  6. #86
    kibibyte L'avatar di grunter
    Registrato
    Oct 2014
    Località
    Pistoia
    Età
    52
    Messaggi
    222
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    ?

    immagino sia casomai il contrario: "Ravenna" nel tuo caso è una uscita, quindi è jack che deve vederlo e non viceversa.
    Sni, nel senso che si, Jack deve vedere Ravenna, e questo sicuramente funziona, perchè tutti i software con uscita asio riescono a vedere Ravenna.
    Come ti dicevo, però, Ravenna è un finto driver Asio, nel senso che diventa tale (cioè passa le chiamate Asio), solo nel momento in cui tramite il software Easy Connect si riesce ad agganciare da un lato il player (in questo caso Jack) e dall'altro il Mergin Hapi.
    Purtroppo alcuni software player che riescono a vedere senza problemi Ravenna Asio NON vengono visti da Easy Connect e dunque non si riesce a collegare il player al Merging Hapi.
    Con Jplay e foobar mi succede proprio questo, dunque di fatto la comunicazione non c'è anche se il player vede Ravenna Asio.
    Metto sotto una immagine per fare capire il meccanismo.
    Anche io, nonostante fossi stato avvertito da Roberto e quindi già sapessi inizialmente cosa aspettarmi, non riuscivo ad entrare nel meccanismo fintanto che non ci ho sbattuto la testa.



    In pratica a sinistra abbiamo il player asio e a destra il nostro merging hapi, si devono vedere entrambi e metterli in contatto.


    Originariamente inviato da bibo01
    Sono quasi certo che l'upmix/channel mapping sia fatto dopo la conversione. Comunque, ho chiesto conferma a Miska. Vi faccio sapere.

    A mio avviso un possibile problema, quindi un rallentamento delle prestazioni, può essere dovuto al traffico Ethernet rappresentato da 8ch DSD256.
    Ciascun segnale stero DSD256 è 2,7 MB/s. Quindi 8 canali sono 10,8 MB/s.

    Inoltre, avete provato con i modulatori in versione "256+fs" (studiati per queste frequenze) ed anche con i filtri in versione -2s? HQPlayer ce la fa oppure no? Qual'è il risultato all'ascolto?
    Dunque, fermo restando l'uso del channel mapping, in windows server 2012 r2 (senza AO) si riesce a fare upsampling a dsd128 partendo da tutti i tipi di file che vanno da pcm 16/44 fino a dsd64, usando come filtro poly-sinc-mp e come modulatore ASDM7 (che sono i settaggi che preferisco), mentre si riesce a fare upsampling a dsd256 partendo da pcm 16/44 fino a pcm 24/96 usando poly-sinc-mp2s e modulatore ASDM7.
    In windows 10 non riesco a fare nessun tipo di upsampling (nemmeno da pcm 16/44 a pcm 24/96) se uso il channel mapping. Disabilitando il channel mapping devo riprovare ma a memoria si può fare tutto quello che si riesce a fare con windows server 2012r2 liscio.
    Devo verificare ma Windows Server 2012r2 con AO si comporta come Windows 10 (ovviamente senza disabilitare quelle voci come i servizi di rete o il servizio che serve ad hqplayer e ai convolutori).
    Non è che la riproduzione non parta, ma si hanno dei rallentamenti e delle distorsioni inserite. La cosa buffa è che premendo stop per qualche frazione di secondo il suono esce normale.

    Concludendo sembrerebbe più sensato usare windows server 2012r2 liscio, eppure devo dire di preferirgli il suono senza upsampling di windows 10.

  7. #87

    Predefinito

    Questa frase aveva ingannato anche me. Avevo chiesto direttamente a Merging: loro intendono gruppi di 8 canali al momento; forse in futuro permetteranno i singoli canali, ma hanno altre priorità al momento (i loro programmatori sono oberati di lavoro).

    Originariamente inviato da UnixMan
    a giudicare da questo:


    da: Merging Technologies | Hapi Mic Pre & AD/DA Converter with RAVENNA AES67

    dovrebbe essere possibile. D'altro canto, in ambito "pro" il channel mapping è una delle funzioni più essenziali e fondamentali. L'unico dubbio è relativo al significato esatto di quel "in blocks of 8 channels".

    Comunque, casomai non lo fosse, per fare il mapping forse potresti utilizzare Jack: JACK Audio Connection Kit|Home a valle di HQP (tra HQP ed ASIO, o tra NAA ed ASIO se usi NAA).

    JACK Audio Connection Kit|Using JACK on Windows

  8. #88

    Predefinito

    Su Windows c'è ASIO Bridge della VP-audio, che funziona e permette di fare queste cose. Tuttavia supporta solo PCM e non DSD al momento. C'ho studiato nei mesi scorsi, non ci sono molte alternative al momento per fare upmix con il DSD se non da host ASIO (come si chiama in gergo il sw che e aggancia e suona l'ASIO driver).

    Originariamente inviato da grunter
    L'unico problema potrebbe essere far vedere Jack a Asio Ravenna, nonostante sia un driver Asio non tutti i player Asio, ad esempio, riescono ad essere visti da ravenna.
    Questo perchè in realtà più che essere un vero driver Asio, Ravenna è una sorta di intercettore di chiamate Asio da dirottare sulla rete.
    Ad esempio Jplay non viene visto da Ravenna e di conseguenza non riescono ad agganciarsi, nemmeno Foobar sono riuscito ad agganciare.
    Comunque mai dire mai... tutto è da provare.

  9. #89

    Predefinito

    L'ASIO Merging Ravenna si prealloca una banda fissa in trasmissione verso l'Hapi di circa 94-95 Mbs (per il DSD/DXD), e di ricezione dall'Hapi di circa 7 Mbs (per l'interfaccia Web), quindi regge tranquillamente 8 canali DSD 256. Non è quello che rallenta, è l'uso smodato della CPU da parte di HQP

    I filtri in versione "-2s" reggono ma, per esempio, il mio setup ideale poly-sinc-mp + ASDM7 suona meglio (alle mie orecchie ovviamente) rispetto a poly-sinc-mp-2s + ASDM7.

    -R

    Originariamente inviato da bibo01
    Sono quasi certo che l'upmix/channel mapping sia fatto dopo la conversione. Comunque, ho chiesto conferma a Miska. Vi faccio sapere.

    A mio avviso un possibile problema, quindi un rallentamento delle prestazioni, può essere dovuto al traffico Ethernet rappresentato da 8ch DSD256.
    Ciascun segnale stero DSD256 è 2,7 MB/s. Quindi 8 canali sono 10,8 MB/s.

    Inoltre, avete provato con i modulatori in versione "256+fs" (studiati per queste frequenze) ed anche con i filtri in versione -2s? HQPlayer ce la fa oppure no? Qual'è il risultato all'ascolto?

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

    Predefinito

    Originariamente inviato da robertopisa
    Se posso essere franco e diretto, credo che Jussi ci capisca molto di audio digitale e poco di programmazione avanzata
    I suoi filtri audio sono fantastici, ma avrei molto da ridire sul suo sw se me lo portasse come progetto a un esame.
    La v3.8.1 (la 3.8.0 è durata 1 giorno) è la prima versione con Matrix, per il quale Miska ha scritto un motore totalmente separato da quello per PCM e quello per DSD. Diamogli del tempo e sicuramente sarà in grado di ottimizzarlo ulteriormente.

Pagina 9 di 21
prima
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ... 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