+1 Hummingboard/Cubox nei SOC eccellono proprio per questo rispetto ai più diffuci e comuni lamponi.Quote:
Originariamente inviato da bibo01
Non sono immuni da compormessi però... MB a 4 strati? mhh...
Ciao.
Printable View
+1 Hummingboard/Cubox nei SOC eccellono proprio per questo rispetto ai più diffuci e comuni lamponi.Quote:
Originariamente inviato da bibo01
Non sono immuni da compormessi però... MB a 4 strati? mhh...
Ciao.
Ciao, chiedendo scusa per la mia patologica tendenza a ciarlare (ma mi pagano a numero di parole, capisci :blblbl) 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":Quote:
Originariamente inviato da audiodan
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.
Sto tentando di fare quello che auspichi qui:Quote:
Originariamente inviato da marcoc1712
http://www.nexthardware.com/forum/cm...-dedicato.html
@marcoc1712,
ciao,
io sono fermo ai bit sono bit :-)
ho letto comunque con interesse il tuo discorso, ma mi sfugge una cosa:
perche' dici
perche' solo Windows?Quote:
Originariamente inviato da marcoc1712
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 :-)
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 :-)Quote:
Originariamente inviato da UnixMan
Dove? Dal NAA al DAC non l'hai...Quote:
Originariamente inviato da marcoc1712
perché no? dipende. Se usa l'interfaccia bulgara, o quella nuova di diyinhk, ecc, ce l'ha eccome...Quote:
Originariamente inviato da EspritDove? Dal NAA al DAC non l'hai...Quote:
Originariamente inviato da marcoc1712
Quote:
Originariamente inviato da bibo01
Quote:
Originariamente inviato da pocarrie
Penso che arriverà la prossima settimana, da odierni contatti telefonici con il venditore.Quote:
Originariamente inviato da bibo01
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.
Quote:
Originariamente inviato da Maggio
Mitico, secondo me è un lavoro utilissimo, non solo per NAA...
Ciao.
Quote:
Originariamente inviato da lucadita
Mi sono perso qualcosa? HQP non è solo windows?
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.Quote:
Originariamente inviato da lucadita
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.
Ma come, i bit smettono di essere bit nel NAA? Scusa, non ho saputo resistere...Quote:
Originariamente inviato da lucadita
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.Quote:
Originariamente inviato da lucadita
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).
Eh, il fascino del vintage... Spero lo scoprano anche le ragazze, ma pare preferiscano le 'moderne repliche' ;censo2.Quote:
Originariamente inviato da lucadita
Ciao.
Marco