Il NAA, questo sconosciuto...

Pagina 20 di 31
prima
... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 ... ultimo
Visualizzazione dei risultati da 191 a 200 su 302
  1. #191
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da bibo01
    Non mi sembra. E' vero il contrario - USB ed ethernet sono separati, non condividono le risorse
    +1 Hummingboard/Cubox nei SOC eccellono proprio per questo rispetto ai più diffuci e comuni lamponi.

    Non sono immuni da compormessi però... MB a 4 strati? mhh...

    Ciao.

  2. #192
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da audiodan
    Ve lo confesso: la mia idea fissa, fin dal primo approccio con HQplayer, era stata quella di usare il Sughetto come NAA, ovvero un PC vero, bello e che finito, alimentato in lineare e depotenziato al punto tale da farlo diventare ben più trasparente di qualsiasi micropc o ciofechine similari.Questa idea nasceva da quanto imparato nel lungo sviluppo di cMP2, durante il quale apparve chiaro che uno dei punti cardine del bel suono era la qualità della mainboard e, in primis, quella delle sue alimentazioni locali, non solo intesa come layout ma anche come componentistica. Quale qualità si può infatti andare a cercare nella componentistica forzatamente scrausissima di un oggetto microscopico quale un cubox o chi per lui? Al di là della volontà e del geniale progetto di questi microPCè ben evidente che i miracoli hanno sempre un prezzo da pagare, in questo caso che rischiava di essere piuttosto salato
    Ciao, chiedendo scusa per la mia patologica tendenza a ciarlare (ma mi pagano a numero di parole, capisci ) secondo me hai toccato un punto cruciale, che sono certo non è condiviso da molti ma a mio avviso trova una evidenza logica dimostrabile ed empiricamente facilmente verificabile da chiunque abbia superato o stadio di "I bit sono bit":

    I S.O hanno la loro impronta timbirica.
    L'hardware suona.

    Banale vero?

    Già, ma in un'architettura come il CMP2, le cose erano più semplici 1 hardware, 1 sistema opertaivo, 1 player, con le architetture distribuite come HQP +NAA le cose si complicano.

    Puliamo il campo dal fatto ce HQP è 'fatto apposta' per modificare lo stream dati e quindi di suo genera differenze sonore ben più ampie di quelle dovute a SO, Hardware e/o PLayer, ipotizziamo quindi di utilizzarlo 'bit perfect' o almeno di mantenerne invariati i settaggi, almeno ai fini di questa analisi.

    HQP = solo Windows, il SO server non è in questo caso una variabile, in altri casi lo è, ma qui non è un'opzione.

    Il player, cioè chi produce lo stream che alimenta il DAC è il networkaudiodaemon, suppongo che la logica sottostante alle versioni per i diversi SO sia analoga ed in questo senso non è una variabile, però - grande però - in qualche modo deve colloquiare con i driver e coi i mixer dei diversi S.O e per farlo lo sviluppatore dispone di alcune scelte (es. utilizzare port audio e lasciare a lui il compito di indirizzare Asio, Wasapi, Kernel stream piuttosto che Alsa o Core Audio) ma oltre ad un certo limite non può andare.

    Non so come sia stato realizzato NAD, comunque ai nostri fini non è un'opzione, quindi le variabili si riducono 'solo' all' HW ed al SW del NAA.

    Alla fine rimangono:

    0. Infrastruttura di rete
    1. HW del Server.
    2. HW del NAA.
    3. SO del NAA.

    Ho messo '0' all'infrastruttura di rete dato che a mio avviso non è una variabile, a meno di non tornare a sistemi stand alone isolati, ne abbiamo parlato diffusamente in un altro thread.

    L'HW del server è importante. Soprattutto se oltre alle 'normali' funzioni compie anche upsampling, DSP, DRC o altro. A mio avviso l'effetto ìnegativo' di questi carichi è infinitamente ridotto se eseguiti su un server remoto piuttosto che in vicinanza dell'impianto, quindi SE servono è bene eseguirli sul server, ma un'effetto lo hanno e quindi occorre che il server sia correttamente dimensionato ad evitare problemi.

    Es. Il 'famigerato' problema della condivisone BUS USB/LAN che è grave se su USB si ha il DAC (quindi su NAA) può essere comunque penalizzante sul server, se su USB si ha lo storage ed utilizzando formati con alta occupazione di banda (es. DSD256 o superiori).
    Pochi considerano che molti hw comunque 'limitano' a 460 Mbs per un problema analogo.

    Sempre a mio avviso, il server è bene sia DEDICATO, cioè non deve fare altre cose mentre alimenta i renderer e possibilmente il suo SO deve essere il più possibile ridotto ed ottimizzato allo scopo, è meno importante che non in CMP2 o sul NAA, ma è importante: un server sovraccarico produce profili di lavoro con picchi e latenze, i buffer sono li per questo e certamente limitano gli effetti, ma prevenire è meglio.

    Un server ben dimensionato e senza colli di bottiglia con una decente infrastruttura di rete cablata, credo diffcilmente si faccia ...sentire.

    Tutta questa tirata, per arrivare a dire che in una architettura come HQP+NAA se HW e SO hanno un'influenza, di fatto, la possiamo sperimentare solo a livello di NAA e come giustamente dici tu, l'esperienza ci insegna che:

    caso 1: un SOC da 30€ alimentato con lo scatolotto di recupero "ex rasoio" colegato alla stessa ciabatta dell'impianto, 'butato li' alla meglio ed appoggiato direttamente sul coperchio del pre phono valvolare.

    caso 2: un pc realizzato con componentisica di qualità (a partire dalla MB), non inutilmente sovradimensionato alimentato in lineare e posizionato con cura ad evitare vibrazioni, EMI ed RFI (prodotte e subite).

    difficilmente 1 suonerà meglio di 2, se le differenze risultassero inudibili mi preoccuperei per capacità risolutive dell'impianto e/o uditive dell'utente.

    Però...

    I grandi vantaggi di NAA sono:

    1. Fanless
    2. Basse emissioni RFI/EMI
    3. Basse/Nulle vibrazioni prodotte
    4. Isolamento galvanico

    Le prime trè sono direttamente correlate al basso consumo ed il basso consumo si ottiene - in un pc generico - limitando al massimo le attività, eliminando le superflue.

    Un SOC con LINUX permette di ottenere questo vantaggi con una spesa a partire da 40€.
    Un NUC (o similia) con Windows sono almeno 200€ (licenza compresa).

    Assemblare un pc su base Micro/Mini ITX 'stile' CMP2 (per chi non ha già il sughetto pronto, ovvio) tenendo conto di tutte le esperienze fatte con CMP2 può essere certamente una valida opzione, avendo però cura di non vanificare i vantaggi dell'architettura distribuita 'sovradimensionando' il NAA e soprattutto facendogli (o in previsione di fargli ) fare 'altre' cose' come ho spesso sentito aleggiare in questo THD:

    un player di rete (NAA) non deve fare upsampling, non deve fare DSP/DRM, non deve accedere a dischi locali o remoti, deve ricevere uno stream TCP/IP e passarlo al DAC via USB, nulla di più e nulla di meno.

    Io non ho le competenze HW specifiche per farlo, ma credo che mettendo insieme quelle dei tanti esperti qui presenti si potrebbero individuare un paio di configurazioni 'di riferimento' per realizzare un NAA senza compromessi, il SO (Win o LINUX, nelle varie versioni) rimarrà comunque una scelta personale, suonano diversi.

    p.s.

    Prima o poi a qualcuno verrà la geniale idea che un oggetto del genere realizzato con HW e firmware progettati ed ottimizzati specificatamente per l'uso sarebbe l'uovo di colombo, potrebbe chiamarlo I2S over IP, magari collegarlo ad un DAC e ...ops avrebbe inventato lo Squeezebox!

    p.p.s.

    Ho parlato di HQP ed NAA solo per rimanere in tema del THD, le stesse considerazioni si possono estendere (ed io così le ho sperimentate) a qualsiasi architettura distribuita, nel qual caso al SO del server vanno applicate le stesse attenzioni riservate all'hardware ed all'infrastruttura di rete.

    Marco.

  3. #193
    kibibyte L'avatar di Maggio
    Registrato
    Nov 2013
    Messaggi
    376

    Predefinito

    Originariamente inviato da marcoc1712
    Io non ho le competenze HW specifiche per farlo, ma credo che mettendo insieme quelle dei tanti esperti qui presenti si potrebbero individuare un paio di configurazioni 'di riferimento' per realizzare un NAA senza compromessi, il SO (Win o LINUX, nelle varie versioni) rimarrà comunque una scelta personale, suonano diversi.

    Marco.
    Sto tentando di fare quello che auspichi qui:
    http://www.nexthardware.com/forum/cm...-dedicato.html

  4. #194
    kibibyte L'avatar di lucadita
    Registrato
    Oct 2014
    Località
    Vercelli
    Età
    53
    Messaggi
    445
    configurazione

    Predefinito

    @marcoc1712,
    ciao,
    io sono fermo ai bit sono bit :-)

    ho letto comunque con interesse il tuo discorso, ma mi sfugge una cosa:
    perche' dici
    Originariamente inviato da marcoc1712
    HQP = solo Windows, il SO server non è in questo caso una variabile, in altri casi lo è, ma qui non è un'opzione.
    perche' solo Windows?
    a mio parere, l'OS del server non puo' in nessun modo inficiare la "qualita' sonora dei bit" se e' in grado, insieme all'hardware di mandare un flusso di dati "ininterrotto" al NAA... qui, sempre a mio parere, i BIT sono BIT!

    Il Naa e' tutto un'altro discorso perche' bisogna vedere come si "interfaccia" con il DAC e qui hardware, alimentazioni e software possono come giustamente dici avere un notevole impatto...
    Tutto questo se il NAA e' stato implementato come un "buffer" che riceve in ingresso su ethernet e scrive su USB.... e che comunque ha una sua "memoria" (il buffer appunto) che permette di dare il tempo al server di ritrasmettere eventuali pacchetti che non sono andati a buon fine...

    Per il resto, alla fine come dici si sta "reinventando" lo squeezebox :-) Un po' come tutti gli OS prima o poi tornano a papa' Unix :-)

  5. #195
    byte L'avatar di Esprit
    Registrato
    Sep 2013
    Messaggi
    100

    Predefinito

    Originariamente inviato da UnixMan
    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".
    Grazie, lo so perfettamente come funziona l'incapsulamento il punto è che con DoP difficilmente necessitando di una banda PCM elevata si riesce ad andare oltre DSD128 ed a me interessa almeno il DSD256 :-)

  6. #196
    byte L'avatar di Esprit
    Registrato
    Sep 2013
    Messaggi
    100

    Predefinito

    Originariamente inviato da marcoc1712
    4. Isolamento galvanico
    Dove? Dal NAA al DAC non l'hai...
    Ultima modifica di bibo01 : 31-01-2015 a 01:05 Motivo: Impaginazione quote

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

    Predefinito

    Originariamente inviato da Esprit
    Originariamente inviato da marcoc1712
    4. Isolamento galvanico
    Dove? Dal NAA al DAC non l'hai...
    perché no? dipende. Se usa l'interfaccia bulgara, o quella nuova di diyinhk, ecc, ce l'ha eccome...
    Ultima modifica di bibo01 : 31-01-2015 a 01:06 Motivo: Impaginazione quote
    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. #198
    kibibyte L'avatar di pocarrie
    Registrato
    Feb 2012
    Età
    56
    Messaggi
    262
    configurazione

    Predefinito

    Originariamente inviato da bibo01
    Alternative hardware per Win NAA:

    Gigabyte GB-BXBT-2807, fanless, 2.5A @ 12V...$130 a Newegg

    Allegato 16087
    Originariamente inviato da pocarrie
    L'ho ordinato e mi arriva nei prossimi giorni.
    Originariamente inviato da bibo01
    Quando ti arriva, prova a fare chiavette per NAA con OS differenti: Linux, Win 8.1 snellito e/o Win Server core mode snellito.
    Penso che arriverà la prossima settimana, da odierni contatti telefonici con il venditore.

    Nell'attesa, ho una curiosità: quel barebone Gigabyte non ha slot esterni per sd card, ma solo due USB 2.0 sul retro e una USB 3.0 sul fronte.
    Ha invece uno slot interno per half-size Mini-PCIe, occupato in fabbrica dalla scheda WiFi/Bluetooth, che tuttavia ho intenzione di rimuovere.
    Ho preso su Amazon questo adattatore Mini-PCIe>SD/SDHC, per metterci una SD card da 64 gb classe 10.
    Il venditore tedesco specifica (da quanto si capisce con la traduzione automatica di Bing) che La maggior parte dei computer notebook non può essere avviato da mini slot PCIe. Eventuali impostazioni nel BIOS sono necessarie. Se c'è un'impostazione per "Mini PCIe mode", ecc., deve essere settata su "USB".

    Io comunque l'ho preso perché non costava molto, e perché la scheda sd ce l'ho già.

    Pensate che possa funzionare, nel senso di essere bootabile dalla sd card?

    Lo chiedo perché - a proposito di quanto mi suggerisce bibo, di preparare tre diversi supporti di avvio con i tre diversi S.O. - , come ho già evidenziato in un altro post, su questo punto ci sono diverse opinioni, Miska suggerisce di evitare il classico hard disk, anche ssd, e anzi di disattivare sata, Phil di Audio Optimizer invece sconsiglia decisamente l'installazione del sistema (nel suo caso Win Server 2012 R2) su altro che non sia hd ssd (niente CF e simili).

    Grazie per un eventuale parere tecnico.

  9. #199
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da Maggio
    Sto tentando di fare quello che auspichi qui:
    http://www.nexthardware.com/forum/cm...-dedicato.html

    Mitico, secondo me è un lavoro utilissimo, non solo per NAA...

    Ciao.

  10. #200
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da lucadita
    @marcoc1712,

    perche' solo Windows?

    Mi sono perso qualcosa? HQP non è solo windows?

    Originariamente inviato da lucadita
    a mio parere, l'OS del server non puo' in nessun modo inficiare la "qualita' sonora dei bit" se e' in grado, insieme all'hardware di mandare un flusso di dati "ininterrotto" al NAA... qui, sempre a mio parere, i BIT sono BIT!
    A mio avviso il SO del server è una delle variabili meno influenti, ne convengo, allo stesso livello dell'infrastruttura di rete e dell' Hardware del server stesso. tendo infatti a considerare server (HS e SO) come parte dell'infrastrttura di rete, quindi come qualcosa di necessario che deve essere meso in condizione di lavorare pre non crere problemi.

    Mi spiego con un esempio: la 'corrente' di casa è una componente fondamentale e la sua qualità ha una grossa influenza sul suono, credo ne converrai. Non ha molto senso chiedersi di che marca è il trasformatore di rete in centrale, ma molto si può fare per 'ottimizzarla' alle prese dl nostro impianto, in primis evitando errori grossolani come ciabatte multipresa 'asfittiche' e grovigli informi di cavi a formare belle antenne, quindi inserendo con giudizio isolatori e condizionatori di rete sulle sorgenti più sensibili e/o che generano maggior rumore.

    Allo stesso modo l'infrastruttura di rete (server compreso) va ottimizzata evitando grossolani errori e coli di bottiglia, fatto questo poco conta a mio avviso il S.O. del server in se, ma se usi un NAS con 256 mb per fare samba, uTorrent, server multimediale,... beh, di certo avrai situazioni di picco che certamente si rifletteranno sullo streaming, a volte avvertibili come drop outs, a volte molto più sibillini. I buffer ci sono e limitano il problema, ma non lo eliminano del tutto, guarda il profilo di lavoro di un player con attività di rete regolare e buffer sempre ben alimentato e confrontalo con quello in situazioni di periodiche interruzioni di collegamento e successivo picco di attività per recuperare, sono ben diverse ed alcuni sostengono che questa differenza di carico generi rumore, io non lo so, ma certo è il sintomo di una influenza che l'attività del server ha sul client.


    Originariamente inviato da lucadita
    Il Naa e' tutto un'altro discorso perche' bisogna vedere come si "interfaccia" con il DAC e qui hardware, alimentazioni e software possono come giustamente dici avere un notevole impatto...
    Ma come, i bit smettono di essere bit nel NAA? Scusa, non ho saputo resistere...

    Originariamente inviato da lucadita
    Tutto questo se il NAA e' stato implementato come un "buffer" che riceve in ingresso su ethernet e scrive su USB.... e che comunque ha una sua "memoria" (il buffer appunto) che permette di dare il tempo al server di ritrasmettere eventuali pacchetti che non sono andati a buon fine... .
    Appunto, è un FIFO a monte del quale c'è il client TPC/IP con i suoi processi ed a valle il 'player' che mediante il mixer di SO ed i driver dei dispositivi 'scrive' verso la porta USB in un altro buffer, che a sua volta viene letto da un processo (del DAC) REAL TIME, quindi pesantemente influenzato dallo stato del buffer, diversamente da quello che succede - per esempio - per un file excell.

    Convengo che fintanto che il secondo buffer non si svuota completamente non si hanno dropouts, ma questo è solo il problema più evidente, ben sappiamo però che anche il 'profilo' con cui si alimenta e svuota il buffer (leggi latenza e dimensioni) ha la sua importanza e questo è in buona parte legato al lavoro del player che a sua volta risente indirettamente del funzionamento del FIFO e quindi del buon funzionamento/carico di attività del server.

    E' ovvio che più ci si allontana dal DAC più i fenomi diminuiscono di intensità in modo esponenziale e come ho scritto ritengo che almeno fino al NAA ci si debba preoccupare solo di evitare situazioni 'patologiche', mentre condizioni normali possono considerarsi a mio avviso equivalenti, ma ti assicuro che c'è chi sostiene che anche avere i dati su nas e non direttamente su dischi collegati al server ha un effetto deleterio e non si tratta di ammalati di audiofilia nervosa ma di rispettabilissimi professionisti (v. Audirvana o Volumio).

    Originariamente inviato da lucadita
    Per il resto, alla fine come dici si sta "reinventando" lo squeezebox :-) Un po' come tutti gli OS prima o poi tornano a papa' Unix :-)
    Eh, il fascino del vintage... Spero lo scoprano anche le ragazze, ma pare preferiscano le 'moderne repliche' .

    Ciao.

    Marco

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