Il NAA, questo sconosciuto...

Pagina 18 di 31
prima
... 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 ... ultimo
Visualizzazione dei risultati da 171 a 180 su 302
  1. #171
    mebibyte
    Registrato
    Aug 2009
    Località
    Crotone, Italy
    Età
    60
    Messaggi
    740
    configurazione

    Predefinito

    Io con win 8.1 sul naa non ho problemi con un celeron....vero é che si tratta di roba che avevo in casa...a parte un HD e il case....ma si presta perfettamente alla bisogna..ora speto di poter avere qualche minuto per provare a snellire il SO...
    Gianni...

  2. #172
    byte L'avatar di Esprit
    Registrato
    Sep 2013
    Messaggi
    100

    Predefinito

    Originariamente inviato da UnixMan
    non serve che sia windoze. Puoi usare benissimo Linux (non servono driver aggiuntivi, quella scheda usa un chipset già supportato nativamente dai kernel Linux recenti).
    /me non sa nulla di Linux per cui chiede...
    Ma non c'è il problema dei driver ASIO assenti per cui non è possibile il DSD chiamiamolo "nativo" bypassando il DoP?

  3. #173
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,509
    configurazione

    Predefinito

    Originariamente inviato da Esprit
    /me non sa nulla di Linux per cui chiede...
    Ma non c'è il problema dei driver ASIO assenti per cui non è possibile il DSD chiamiamolo "nativo" bypassando il DoP?
    nei kernel recenti è già stato introdotto anche quello, almeno per alcune interfacce (e sicuramente altre saranno aggiunte man mano che agli sviluppatori di ALSA sarà dato modo di farlo).

    Comunque non vedo la differenza (se non per quelle interfacce che non supportano il DoP e che quindi non potrebbero essere utilizzate altrimenti). Come spiegavo altrove (sempre su questo forum) il "DoP" non è che un modo come un altro (né migliore né peggiore di altri) per trasferire uno stream DSD tra due end-point che "parlano la stessa lingua".

    In effetti si tratta banalmente di un semplice quanto banale "trucco" noto come "incapsulamento" dei dati; è una tecnica estremamente comune e diffusa in informatica e telematica per una infinità di applicazioni (lo stesso TCP/IP si basa sullo stesso principio...). Nel caso specifico serve banalmente per poter trasferire dati DSD utilizzando una infrastruttura esistente che originariamente prevedeva il trasferimento di dati solo in formato PCM.

    Come dovrebbe essere ovvio, "DoP" non significa che lo stream DSD venga convertito in PCM o alterato in qualsiasi altro modo. A tutti gli effetti, il DoP è perfettamente equivalente al "DSD nativo".
    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.»

  4. #174
    kibibyte L'avatar di pocarrie
    Registrato
    Feb 2012
    Età
    53
    Messaggi
    262
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    nei kernel recenti è già stato introdotto anche quello, almeno per alcune interfacce (e sicuramente altre saranno aggiunte man mano che agli sviluppatori di ALSA sarà dato modo di farlo).

    Comunque non vedo la differenza (se non per quelle interfacce che non supportano il DoP e che quindi non potrebbero essere utilizzate altrimenti). Come spiegavo altrove (sempre su questo forum) il "DoP" non è che un modo come un altro (né migliore né peggiore di altri) per trasferire uno stream DSD tra due end-point che "parlano la stessa lingua".

    In effetti si tratta banalmente di un semplice quanto banale "trucco" noto come "incapsulamento" dei dati; è una tecnica estremamente comune e diffusa in informatica e telematica per una infinità di applicazioni (lo stesso TCP/IP si basa sullo stesso principio...). Nel caso specifico serve banalmente per poter trasferire dati DSD utilizzando una infrastruttura esistente che originariamente prevedeva il trasferimento di dati solo in formato PCM.

    Come dovrebbe essere ovvio, "DoP" non significa che lo stream DSD venga convertito in PCM o alterato in qualsiasi altro modo. A tutti gli effetti, il DoP è perfettamente equivalente al "DSD nativo".
    però Miska sottolinea spesso che col dsd nativo si ha circa il 40% di traffico dati in meno sulla rete ethernet locale, nell'utilizzo NAA, rispetto al DoP, con minori overheads.
    è corretto? oppure ho riportato male io il concetto?
    ed è un aspetto realmente rilevante?

  5. #175
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,509
    configurazione

    Predefinito

    Originariamente inviato da pocarrie
    però Miska sottolinea spesso che col dsd nativo si ha circa il 40% di traffico dati in meno sulla rete ethernet locale, nell'utilizzo NAA, rispetto al DoP, con minori overheads.
    è corretto? oppure ho riportato male io il concetto?
    A naso il 40% in più mi sembra tanto ma sì, che ci sia un certo "overhead" (nel senso di un aumento della quantità di dati trasferiti) a causa dell'incapsulamento è senza dubbio normale (prima di inviarli all'interfaccia USB i dati DSD devono essere divisi in blocchi di dimensioni pari a quelle di un frame PCM, e ad ognuno di questi blocchi deve essere aggiunto un header "fake"; dall'altro lato l'interfaccia poi butta via gli headers e riassembla i blocchi per ricostruire lo stream DSD originale).

    Quello che non mi torna è il traffico... su Ethernet? In linea di principio il DoP dovrebbe essere utilizzato solo localmente, sul bus USB (tra il NAA e l'interfaccia audio USB): non vedo il motivo per cui tra HQP ed NAA dovrebbe cambiare qualcosa. Sicuro di non aver capito male in tal senso?

    Originariamente inviato da pocarrie
    ed è un aspetto realmente rilevante?
    buona domanda. La banda (tanto su USB quanto eventualmente su Ethernet, casomai il DoP fosse utilizzato già a monte del NAA) è sufficiente, quindi grossi problemi non ce ne sono. Certo aumentando il traffico aumenta un po' anche il carico del NAA. Ma se consideri che "dall'altro lato" (quello dell'interfaccia audio USB: Amanero, JLsounds, ecc) lo stesso traffico è gestito da un banale microcontrollore...
    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.»

  6. #176
    Moderatore L'avatar di bibo01
    Registrato
    Oct 2010
    Messaggi
    4,540
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    devi installare solo il sistema di base e poi dare un comando per installare il NAA con le relative dipendenze. È di una facilità disarmante, ci riuscirebbe anche un bambino.

    Conviene usare una immagine "mini"/netinstall:

    https://www.debian.org/CD/netinst/

    http://ftp.debian.org/debian/dists/s...tboot/mini.iso

    http://ftp.debian.org/debian/dists/t...tboot/mini.iso

    Basta mettere l'immagine dell'installatore su un CD o su un USB stick, avviare da quello e seguire le istruzioni. Avendo cura di scegliere di installare solo il sistema di base e nient'altro. Al momento dell'installazione la macchina deve essere connessa alla rete via cavo (Ethernet), attraverso un router che fornisca servizi DHCP e connessione ad Internet.
    Per avere l'ultima compatibilità Linux con il ricevitore XMOS, fatta l'installazione di Jessie che potete seguire con schermate passo passo qui, bisogna installare i pacchetti di
    • linux-image (linux-image-3.18.1naa_1_amd64.deb),
    • linux-headers (linux-headers-3.18.1naa_1_amd64.deb),
    • libasound2 (libasound2_1.0.28-1jl1_amd64.deb)
    • libasound2-data (libasound2-data_1.0.28-1jl1_all.deb)

    preparati da Miska e che si trovano a: Index of /src/jessie
    Poi, basta installare l'ultima versione di networkaudiod (networkaudiod_3.0.0-22_amd64.deb) per Linux.

    Sia per i singoli pacchetti che per il deamon bisogna dare due comandi: il primo per scaricarlo, il secondo per installarlo. Ad esempio:

    1) sudo wget http://www.sonarnerd.net/src/jessie/...8-1jl1_all.deb

    2) sudo dpkg -i libasound2-data_1.0.28-1jl1_all.deb


    Ora non ci sono più scuse per non provare!
    Ultima modifica di bibo01 : 16-02-2015 a 11:25
    UnixMan likes this.

  7. #177
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,509
    configurazione

    Predefinito

    Perché a 64bit? Almeno per il NAA non conviene mettere tutto a 32bit? (files *_i386.deb anziché *_amd64.deb).
    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.»

  8. #178
    Moderatore L'avatar di bibo01
    Registrato
    Oct 2010
    Messaggi
    4,540
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    Perché a 64bit? Almeno per il NAA non conviene mettere tutto a 32bit? (files *_i386.deb anziché *_amd64.deb).
    ahahahahah ...avevo messo i files xxx_i386.deb e poi li ho cambiati con xxx_amd64.deb
    Non cambia molto...dipende dalla piattaforma hardware...ho pensato che in fondo Miska sviluppa l'NAA Linux a 64 bit

  9. #179
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,509
    configurazione

    Predefinito

    Sì, se hai hardware compatibile in effetti cambia poco. Ma se hai <=4GB di RAM (e per un NAA ne serve mooolta di meno...) usare un OS a 64bit non ha senso: sprechi solo memoria.
    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.»

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

    Predefinito

    Originariamente inviato da UnixMan
    A naso il 40% in più mi sembra tanto ma sì, che ci sia un certo "overhead" (nel senso di un aumento della quantità di dati trasferiti) a causa dell'incapsulamento è senza dubbio normale (prima di inviarli all'interfaccia USB i dati DSD devono essere divisi in blocchi di dimensioni pari a quelle di un frame PCM, e ad ognuno di questi blocchi deve essere aggiunto un header "fake"; dall'altro lato l'interfaccia poi butta via gli headers e riassembla i blocchi per ricostruire lo stream DSD originale).

    Quello che non mi torna è il traffico... su Ethernet? In linea di principio il DoP dovrebbe essere utilizzato solo localmente, sul bus USB (tra il NAA e l'interfaccia audio USB): non vedo il motivo per cui tra HQP ed NAA dovrebbe cambiare qualcosa. Sicuro di non aver capito male in tal senso?


    buona domanda. La banda (tanto su USB quanto eventualmente su Ethernet, casomai il DoP fosse utilizzato già a monte del NAA) è sufficiente, quindi grossi problemi non ce ne sono. Certo aumentando il traffico aumenta un po' anche il carico del NAA. Ma se consideri che "dall'altro lato" (quello dell'interfaccia audio USB: Amanero, JLsounds, ecc) lo stesso traffico è gestito da un banale microcontrollore...
    L'impacchettamento DoP avviene in HQPlayer non nel NAA, quindi il traffico su network aumenta...fino al 50%.
    A mio avviso un problema che rende preferibile il DSD in bitstream ripetto al DoP è l'applicazione del DSP. Utilizzare un motore DSP in DSD come HQPlayer e poi impacchettarlo in un pseudo-PCM crea dei limiti. Sinceramente non ricordo esattamente in quali condizioni, ma se siete interessati posso chiederlo a Miska...

Pagina 18 di 31
prima
... 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 ... 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-2018

Search Engine Optimization by vBSEO 3.6.1