Che si fa? Sistema HQPlayer e NAA

[marcoc1712]

Non mi stupisce, è abbastanza normale che una GPU più potente si traduca in miglioramenti dell'imagine a parità di formato/frequenza ed altri parametri, perchè non dovrebbe essere così per l'audio? HQPlayer NON sta semplicemente estraendo lo stream PCM da un file trasferendolo al NAA e quindi al DAC (operazioni che si mi stupirei fossero in qualche modo influenzate dalla potenza o settaggio BIOS di una qualsiasi CPU superiore ad un ARM7) ma ricostruendolo proprio, è qualcosa di molto più simile a quello che normalmete avviene all'interno dei DSP/FPGA del dac ed in quel caso non ci stupiremmo minimante, credo.

Per questo comprendo il significato dell'affermazione che il server non serve sia ottimizzato ad uso audio (leggi inutile sot-m card, alimentazione lineare - ma non ne sarei sicuro - fanless, SSD, Sata filters (anche qui aspetterei a dire che è inutile) che non vuol dire che non si giovi di potenza ed opportuni settaggi, in funzione dell'utilizzo che se ne intende fare, come qualsiasi altro pc pensato per qualsiasi altro uso. Vabbè che è asincrono, ma c'è sempre una correlazione tra dimensione del butter e latenza, prestazioni al limite della capacità aumentano la latenza e le contromisure non sempre sono 'indolori', meglio stare dalla parte del frumentone....

In questo senso non mi stupirebbe affatto - anzi quasi ci scommetterei - che un pc ottimizzato per l'audio (quindi normalmente con capacità di calcolo e prestazioni volutamente limitate) si rilevasse meno appropriato di una macchina generica di pari livello di costo.

L'ho già detto, HQPlayer 'rompe' il paradigma file -> server -> Bit perfect -> Dac, il file viene elaborato nel server, quindi al DAC arriva uno stream diverso da quello contenuto nel file per disegno.

La valutazione è giocoforza sull'intera catena file -> server -> NAA -> DAC, comprendendo i trasporti (intesi i mezzi di trasferimento, tipicamente la rete, rappresentata dalle frecce nel disegno).

Grandi possibilità ma meno certezze (nessun led 'bit perfect si accende sui dac...).

Ahi, ahi, ahi, vedo avvicinarsi un branco di scimmie inferocite alla ricerca di nuove spalle audiofile...

[UnixMan]

Non mi stupisce, è abbastanza normale che una GPU più potente si traduca in miglioramenti dell'imagine a parità di formato/frequenza ed altri parametri,

ehm... cambiando GPU (o meglio scheda grafica) cambia (quasi) tutto, spesso a partire proprio dagli algoritmi utilizzati per il rendering. Ovvio quindi che ci possano essere differenze più o meno visibili.

Qui (a parità di settaggi di HQP) non stai cambiando un bel nulla se non la velocità con cui esegui le (stesse, identiche) operazioni. Quindi di differenze nei dati non se ne parla.

Ovviamente lo stream rielaborato che esce dal PC è completamente diverso da quello contenuto nel file di partenza, ma ciò che arriva al DAC è sempre niente altro che il risultato dell'applicazione di un ben determinato algoritmo ai dati originali, cioè del calcolo di una ben determinata sequenza di operazioni matematiche. Va da sé che i calcoli sono calcoli: puoi ripeterli tutte le volte che vuoi, con qualsiasi macchina, il risultato è sempre lo stesso! (la matematica non è un'opinione... e non cambia cambiando CPU, settaggi del BIOS, alimentazioni o altro).

Data poi la (doppia) connessione asincrona, non si può neanche parlare di problemi di jitter. Né tantomeno di problemi di buffering. Da quel punto di vista, ci sono solo due possibilità: o il sistema funziona correttamente o non funziona. Nel qual caso il risultato sono dei "buffer underrun", chiaramente udibili come "buchi" e/o "rumoracci" vari durante la riproduzione.

Non so se sia possibile che, in casi "al limite", il sistema si perda dei "pacchetti"/campioni ogni tanto senza che questo risulti direttamente udibile in modo evidente. Se così fosse (cosa eventualmente dipendente dalle interfacce e dal DAC impiegati, ecc), potrebbe anche essere possibile che un problema simile sia percepibile come un cambiamento nella qualità del suono (in teoria un peggioramento, ma la percezione umana a volte gioca strani scherzi...). Tuttavia, ammesso e non concesso che in qualche caso ciò sia effettivamente possibile, si dovrebbe trattare solo di casi particolari.

L'unica cosa che invece può cambiare e certamente cambia sempre (in termini sia di quantità che di "qualità"), ancorché in modo pressoché imprevedibile è il rumore prodotto dal PC che, nonostante tutto, in vari modi può ancora (sia pure indirettamente) raggiungere il DAC (ed il relativo clock) e quindi può (potrebbe) avere ancora qualche effetto sul segnale analogico di uscita.

[UnixMan]

P.S.: c'è una cosa che si potrebbe fare in modo relativamente semplice per ridurre ulteriormente le eventuali influenze del PC "sorgente": eliminare la connessione elettrica tra questo ed il "NAA", sostituendo la connessione Ethernet su rame con una in fibra ottica oppure... wireless.

La seconda opzione (connessione WiFi) è senza dubbio più semplice, economica ed immediata da realizzare, ma presenta vari inconvenienti: la scarsa qualità dei link radio (che rischia di creare problemi di "discontinuità" del flusso dati) nonché il non trascurabile rumore RF prodotto dall'interfaccia stessa (rumore che però non dipende dalle elaborazioni effettuate dal PC ed ha caratteristiche sensibilmente diverse da quello prodotto da questo: con un po' di fortuna potrebbe anche risultare meno "nocivo"). Visto che quasi certamente vi trovate già in casa tutto il necessario e quindi potete provare a costo zero, IMO qualche prova vale la pena di farla.

Laddove l'hardware su cui gira il NAA non disponga già di una sua interfaccia WiFi, una possibilità è quella di usare una interfaccia WiFi USB. Oppure, il modo forse più semplice è quello di collegare il NAA via Ethernet ad un "access point" WiFi (ad es. il router che probabilmente già avete in casa). Avendo ovviamente cura che, a parte l'alimentazione, via cavo non ci sia collegato nient'altro.


La prima opzione (link di rete in fibra ottica) è invece senza dubbio la migliore dal punto di vista tecnico, ma sfortunatamente ha lo svantaggio di dover impiegare dispositivi di rete molto meno comuni e soprattutto molto più costosi. Però, visto che la velocità non è un problema, con un po' di pazienza potreste trovare qualcuno che butta o (s)vende delle vecchie interfacce di rete su fibra (multimodale...) a 100Mbit/s. Resta però il problema di come collegarle al "NAA". La cosa potrebbe essere anche semplice per chi eventualmente usi un "thin-client" o altro sistema dotato di almeno uno slot PCI, ma impossibile con oggetti tipo i CuBox che ne sono sprovvisti.

Una possibilità comoda e "future-proof" potrebbe essere quella di utilizzare uno (o due) convertitori rame/fibra (media converter) oppure hub/switch di rete dotati di almeno una porta su fibra. Con questi basta connettere il NAA al convertitore (o allo switch) con il solito cavetto UTP (o STP) e poi da questo proseguire verso il PC su fibra ottica (verso una scheda inserita direttamente nel PC o un altro convertitore o switch simile dal quale poi si prosegue su rame verso il PC).

Al solito, il problema sono i costi: oggetti del genere vengono da un ristretto mercato "pro" ed hanno costi proibitivi. Però vale il discorso di prima: dato che basta e avanza roba vecchia ed ormai dismessa quasi ovunque, con un po' di pazienza (e di fortuna) forse si può rimediare qualche "ferro vecchio" a prezzi stracciati...

[marcoc1712]

Credo di essermi espresso molto male io, intendevo dire esattamente quello che hai detto tu ed in pratica l'ho scritto negli stesi termini qualche post fa, con particolare riferimento a buchi nella riproduzione causati dalla perdita di pacchetti in TCP/IP, che però NON mi aspetto se non in casi limite, anche se trattandosi in questo caso di operazioni in memoria, non è strettamente attinente, comunque ok.

Quello che intendevo io è che a parità di calcoli e di risultato binario atteso - ovvio - l'utilizzo di sistemi al limite delle prestazioni è molto più prono a generare disturbi rispetto ad un sistema meno tirato, disturbi che in casi limite possono manifestarsi in campo video come immagini meno scolpite e definite e via di seguito, chiaro che se cambi tipo di processore e/o algoritmo, le differenze probabilmente sono più evidenti, ma la mia era solo un'analogia non voglio discutere di quale scheda video sia meglio e meno prona ai disturbi.


Dove probabilmente siamo meno daccordo è che i disturbi possano avere un'influenza SOLO indiretta e SOLO a valle (come mi sembra di capire) ed in particolare sul clock del dac, influenzando il risultato analogico.

Sono parzialmente in disaccordo perchè:

a. Se usi un sistema come questo, il server 'dovrebbe' essere posizionato lontano ed isolato dal dac proprio ad evitare questo fenomeno (è il vantaggio principale del NAA), Ethernet è isolata galvanicamente per disegno e per i disturbi sull'alimentazione (ma non tanto e non solo provocati dal server) un bel filtro sulla presa o un autotrasformatore è una pratica consigliabilissima un ambienti rumorosi, ma IMHO il 90% lo fa la distanza fisica... mettilo in cantina se puoi.

b. quello che tu indichi come problemi di "buffer underrun" sono ...problemi di buffer o latenza... Probabilmente sono quelli a cui mi riferisco io e ti garantisco che tutti i sistemi moderni appllicano contromisure per cercare di evitarli (in quanto errori veri e propri in un sistema real time). Quello che succederebbe se non fossero gestiti sarebbe un hang di sistema (non più così almeno dal 1980), faccio fatica a capire cosa intendi per buchi e rumoracci - siamo in ambito dati, che si tratti di audio è un caso, potrebbero essere formule di conversione di valuta applicate ad un database o elaborazioni video, o calcoli di traiettoria balistica o...

Quello che normalmente succede è che bel rispetto delle prioritò di funzionamento di un sistema multitasking, il SO cerca di ridurre tutte le altre attività al fine di diminuire frequenza ed entità del problema e questo avviene se e solo se a livello applicativo (nei diversi strati sopra il kernel) non sono state opportunamente gestite (o sono state gestite a livello insufficiente) queste situazioni, se non ci riesce ...

L'unica opportunità a livello applicativo è quella di incrementare i buffer (rischioso, si potrebbe innescare un meccanismo di paging) o riempire e svuotare i buffer a frequenza maggiore.

Riporto un'analogia - non mia, non ricordo dove l'ho letta - grossolana ma efficace: pensa al buffer come ad una classe scolastica che debba essere trasferita in palestra: puoi portarcela in 1 volta sola con un pulman, in 4 colte con il pulmino (8 ragazzi per volta in diciamo 20minuti), con un'auto (4 ragazzi per volta in 10 minuti) o con una moto (1 ragazzo per volta in 2,5 minuti).

Il risultato è lo stesso, ma il traffico che si è generato è molto maggiore, in caso di ritardi con il pulmino avresti avuto un buco di 8 ragazzi per un massimo di 20 minuti, con la moto di solo 1 al massimo di 2,5 minuti.

In sistemi pseudo real time - quando cioè non si può semplicemente far girare una clessidra su uno schermo è quello che avviene. L'opportunità di 'buchi' è normalmente prevista e gestita come estrema ratio con interpolazioni, che introducono errori statistici. Capisci che interpolare 1*2,5/30 rispetto a 8*20/30 è ben diverso, meglio sbagliare al massimo di 1/1000 di grado 1000 volte che di 1 grado una volta sola, se stai guidando un missile sull'obiettivo.

Detto ciò, non credo che questo avvenga MAI all'interno dei nostri sistemi. Molto più probabile che il suono venga fermato e fatto riprendere in rapida successione, provocando nei casi peggiori il classico istante di silenzio (hickup o singhiozzo), nei casi migliori un continuo ma quasi impercettibile stop and go che noi non avvertiamo come tale ma alla peggio come fastidio e fatica all'ascolto, se ci pensi è "come se" fossero stati interpolati dei brevissimi periodi di silenzio nel messaggio musicale. Ribadisco però che solo in csi estremi di pesantemente errata o sottodimensionata configurazione mi aspetto problemi di questo tipo!

c. Ricordo che il risultato è influenzato dalla precisione, diretta conseguenza della profondità in bit e caratteristica di un sistema. Lavorare a 8,16,18,20,24,32 o 64 bit ha influenza e cambia il risultato, pur rimanendo vero che la matematica non è un'opinione, quindi cambiando CPU o lunghezza di world certo che 'può' cambiare i dati, difficile che siano opzioni di bios, ed impossibile siano conseguenza diretta dell'alimentazione, concordo.

Non capisco però perchè ti risulti impossibile nel PC ma normale (e non lo è) nei dac, non sono poi così diversi.

A mio modesto modo di pensare, però, tutte le variazioni dovute a quanto sopra (salvo gli hickup) sono ordini di grandezza meno rilevanti rispetto alle variazioni di segnale introdotte da un processo di resampling, conversione e filtro, in questo senso dicevo che perde di significato il paradigma file -> server -> stream bit perfect -> Dac.

Spero converremo - a grandi linee e senza entrare in nomenclature tecniche che mi sembrano fuori luogo.

Ciao, Marco.

[marcoc1712]

P.S.: c'è una cosa che si potrebbe fare in modo relativamente semplice per ridurre ulteriormente le eventuali influenze del PC "sorgente": eliminare la connessione elettrica tra questo ed il "NAA", sostituendo la connessione Ethernet su rame con una in fibra ottica oppure... wireless.

A me risulta che Ethernet garantisca l'isolamento galvanico di suo, il passaggio a fibra serve solo per aumentare la distanza tra un repeater e l'altro e la banda passante, però vado a memoria sono esperto in cose molli non in quelle dure

Ci siamo incorciati con i post, ma metti il server in cantina e lascia stare i ferri vecchi, dai retta a me...

Ciao.

[krellz]

Non è esatto. Quello che ho verificato, e che può verificare chiunque sia in possesso di una motherboard Gigabyte o di altra marca ma sufficientemente moderna e con bios gestibile , è che agendo sui settaggi bios della cpu il suono cambia in modo sensibile. L'overclocking è un'altra cosa e infatti continuo a non poter fare PCM>DSD128 con poli-sync/DSD/6100, limitandomi a 5644.

agendo su quei paramentri vai inevitabilmente ad aumentare (di quanto?) la potenza computazionale si parla in questo caso o si può parlare di overclock ...

mentre per quanto riguarda la possibilità di usare fibra o wifi, posso portare un piccola esperienza ho infrapposto tra router e NAA un filtro della ACOUSTIC REVIVE :
LAN-Isolator RLI-1?ACOUSTIC REVIVE
non cambia nulla al messaggio sonoro né migliora né peggiora !!!

[krellz]

A me risulta che Ethernet garantisca l'isolamento galvanico di suo, il passaggio a fibra serve solo per aumentare la distanza tra un repeater e l'altro e la banda passante, però vado a memoria sono esperto in cose molli non in quelle dure

Ci siamo incorciati con i post, ma metti il server in cantina e lascia stare i ferri vecchi, dai retta a me...

Ciao.

mi potrei essere perso...
affermi che se spostiamo la sorgente (il pc) dall' NAA il suono migliorerebbe ?!
un bel cavo di rete cat7 da 15-25 metri potrebbe andar bene ?!

[marcoc1712]

mi potrei essere perso...
affermi che se spostiamo la sorgente (il pc) dall' NAA il suono migliorerebbe ?!
un bel cavo di rete cat7 da 15-25 metri potrebbe andar bene ?!

Non sono nessuno per affermare, ma non sopporto un PC con HDD, Ventole, Video, mouse e tastiera (a dire il vero nemmeno la tv) in sala d'ascolto e questo è già un motivo sufficiente per tenerlo fuori, se poi si ottiene un vantaggio anche sugli altri fronti tanto meglio, di certo male non fa.

Per onestà devo dire che c'è chi pensa che una qualsiasi forma di collegamento di rete sia deleterio, io non la penso così o comunque penso siano maggiori i vantaggi che gli svantaggi.

In ogni caso, se intendi usare un NAA, una qualche forma di rete la devi predisporre per forza ed a quel punto non hai nulla da perdere a spostare il server in un'altra stanza. L'unico problema rimane comandare HQP, il che non è così immediato come per altri sistemi, dato che purtroppo non dispone di APP di controllo e nemmeno della possibilità di essere controllato da WEB, qualcuno ha proposto applicazioni di schermo remoto su Tablet o simili, non le conosco, non le ho provate e non so dirti, vale la pena provare.

Il metodo che proponi è un collegamento punto punto che andrebbe realizzato con cavo cross (uguale agli altri esternamente, con geometria interna leggermente diversa), la lunghezza massima teorica a 1Gb è di 100 mt con quel cavo, oltre ai quali hai bisogno di un repeater (basta uno switch).

Se hai internet, probabilmente hai un router già collegato al pc, nel qual caso ti conviene collegare anche NAA al router, direttamente se riesci o altrmenti mediante uno switch., se sei sfortunato e non hai un router ma un modem, allora devi procurarti il router e collegare a questo il modem lato 'WAN' ed il PC, NAA e tutto quello che vuoi lato LAN.

Altri metodi sono il wiFi o il powerLine, non sono da escludere configurazioni miste, è il bello di di IP, è assolutamente indipendente dallo strato fisico.

Ciao.

[krellz]

allora, ho già una configurazione funzionante con pc win 8.1@64bit un bel processore i7 che mi consente senza problemi di uscire a DSD128x @ 6.144 MHZ (penso sia per i multipli di 48khz)
un bel cavo di rete 15 metri cat7 verso l'NAA un Supremo dac che da ieri è collegato in bilanciato e devo dire che è come cambiare DAC (da rca a xlr cambia tutto: in un brano che sento abitualmente ho avvertito, a fine canzone, che il cantante poggiava dei fogli da qualche parte e delle voci fuori campo!!!)

inizialmente ho più volte tentato la strada del collegamento diretto con cavo dritto (le moderne schede gigabit applicano un incrocio interno quando necessario, per collegare dispositivi delle stesso livello appunto un pc con un computer linux, nel nostro caso)
ma non c'è stato nulla da fare ! con un cavo che esce da un adattatore di rete del mio pc win verso il NAA non si vedono mai ! ho provato tutto ! (mi manca solo il cavo incrociato, lo dovrei ordinare magari lo farò...)
usando uno switch (netgear GS105E) tra PC E NAA raramente si vedevano (dovevo empiricamente accende e spegnere più volte il NAA, fino a farlo riconoscere, ne ho parlato qui tempo fa... un incubo !!!)
mentre usando il Router (access point, che collego al modem a fibra di fastweb che fa cagare è solo HUB (quello di fastweb)) quindi sono stato costretto a comprare un router wifi netgear che ha anche uno Switch gigabit al quale è appunto collegato sia il pc che il NAA, in questa configurazione va tutto liscio..
certo mi piacerebbe provare ancora a collegare direttamente con un singolo cavo i due computer (pc win e NAA) si potrà tentare ?si ma come ?!

[marcoc1712]

Non sono espertissimo, ma direi che così dovrebbe funzionare:

1. imposta il server con indirizzo IP tipo: 192.168.0.1.
2. riavvia il pc o almeno la conessione di rete.
3. imposta l'NAA con indirizzo IP tipo: 192.168.0.2, default gateway 192.168.0.1.

Collega i 2 pc con cavo cross (ma potrebbe funzionare anche con cavo normale, dipende dalle 2 schede) e dovresti essere in rete, prova a pingare 192.168.0.1 dal NAA e 192.168.0.2 dal pc per sicurezza.

Ma scusa la curiosità, perchè vuoi usare il collegamento diretto? Come farai a connetterti ad internet?

Marco.