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...
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...
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.»
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?
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...
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.»
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
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.»
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.»
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...
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando