Che si fa? Sistema HQPlayer e NAA

[UnixMan]

aspettiamo che UnixMan ci dia la luce

"... Si chiami l'Enel, sia fatta la luce!"

"


Scherzi a parte, l'installazione da zero dovrebbe essere senz'altro fattibile. Basta installare il sistema e le utility di base (no "desktop" o altra roba inutile), il server ssh per la connessione remota e poi, ad installazione completata, il pacchetto di NAA (con le relative dipendenze).

Per quanto riguarda la ISO già pronta, non ricordo più com'era la situazione.

È possibile connettersi al sistema via ssh o direttamente in console, se non come root almeno come utente normale?

Domanda scontata: avete provato a chiedere direttamente alla fonte se e come è eventualmente possibile connettersi al sistema?

Per quanto riguarda un eventuale "hackeraggio", ci sono varie possibilità.

Se il sistema non è stato "blindato" ed è possibile avere accesso alla console (monitor e tastiera connessi direttamente al cubox), ottenere accesso come root è relativamente facile. Basta passare un parametro al boot per by-passare il normale avvio del sistema e far caricare al kernel direttamente (e solo) una shell (che ovviamente è di root). A quel punto basta montare a mano i file system ed utilizzare il solito comando "passwd" per cambiare (o creare) la password di root. Per finire a questo punto basta smontare (o rimontare in read-only) i file system e riavviare, ed il gioco è fatto.

Se invece non si ha accesso alla console, si può agire collegando la microSD su un PC con Linux e montando i relativi file system. A quel punto (a meno che il sistema non sia stato "blindato" criptando i file system...) si possono modificare direttamente i files della configurazione di rete e/o ciò che si vuole.

Ad es., se nel sistema pronto c'è già un server SSH attivo, può tornare utile e comodo anche cambiare le password di root (e di eventuali utenti normali), così che in seguito si abbia libero accesso al sistema. Per farlo è sufficiente modificare direttamente (a mano) i files ./etc/passwd ed ./etc/shadow (ovviamente quelli nella uSD), ad esempio sostituendo in quest'ultimo l'hash della password di root con quello di un utente della macchina su cui si sta lavorando di cui si conosce la password.

Se poi si dispone di un sistema Linux alternativo (a cui si ha accesso) da far girare sullo stesso cubox, conviene effettuare l'operazione direttamente con quello. In tal caso, una volta montato il file system di root del disco sistema del NAA, si può usare il comando "chroot" per accedervi ed utilizzarlo direttamente. Ad es. per cambiare le password, creare utenti e installarci un server SSH, casomai non ci fosse già.

[krellz]

mi sa che è meglio chiedere a jussi nuovamente la password

[UnixMan]

mi sa che è meglio chiedere a jussi nuovamente la password

se ve la da è meglio...

altrimenti è molto più facile di quel che sembra.

[giordy60]

se ve la da è meglio...

altrimenti è molto più facile di quel che sembra.

decripti una chiave a 64bit ( se non a 128 )
dai Paolo fai un miracolo, vorrei collegare il cubox-i direttamente al mac
io non saprei da dove iniziare

[krellz]

ieri sera stavo scaricando da internet abbastanza sostenuto, dal momento che anche il sistema audio passa per quel router , alla fine la riproduzione dava parecchi disturbi !!!!
serve quindi un collegamento diretto
sarebbe l'optimum per tutti...

e non mi dite che poi il cavo dire te elimina tutti i problemi e che il sistema naa è esente da disturbi ! ieri sera l'ho provato di persona ! c'erano scoppietii e micro interruzioni

[giordy60]

e non mi dite che poi il cavo dire te elimina tutti i problemi e che il sistema naa è esente da disturbi ! ieri sera l'ho provato di persona ! c'erano scoppietii e micro interruzioni

può essere che hai utilizzato il filtro sbagliato ?

[madman]

E ti assicuro che il problema sta altrove, prova ad abbassare il carico sulla cpu o prova una rioproduzione "standard", anche con altro player. Al 99% stai tirando il collo al PC.
Se non hai problemi di configurazione sulla LAN, dando per scontato che hai tutto il setup Gigabit correttamente collegato e configuato, è letteralmente impossibile che un semplice download possa creare danni.

Puoi mettere tutte le schede di rete che vuoi, collegare più o meno direttamente, ma i componenti responsabili della riproduzione senza "drop" sono principalmente due: la CPU e l'HD.
Tutto il resto viene dopo....

[UnixMan]

Scusate se rispondo in ritardo ed in modo piuttosto prolisso, ma ritengo che si siano toccati alcuni argomenti molto interessanti ed importanti, che IMO vale la pena approfondire...

l'ho scritto negli stesi termini qualche post fa, con particolare riferimento a buchi nella riproduzione causati dalla perdita di pacchetti in TCP/IP

ahem... questo non può accadere: si possono "perdere" dei pacchetti IP, ma il protocollo TCP garantisce che *tutti* i pacchetti arrivino a destinazione e senza errori. Gli eventuali pacchetti persi o corrotti vengono ritrasmessi fino a completa e corretta ricezione (o finché non si supera il limite max di tempo o di tentativi di ritrasmissione, nel qual caso la connessione viene chiusa e viene segnalato l'errore).

Ovviamente non c'è nessuna garanzia sul *tempo* necessario alla corretta trasmissione. Per cui poi, nel caso specifico, dato che alla fine della catena di elaborazione e trasmissione dati c'è un DAC che necessita di uno stream sincrono ("real-time"), con un ben determinato data-rate, qualora il flusso dati TCP/IP sia troppo lento rispetto allo stream sincrono richiesto dal DAC ci possono essere problemi di "buffer underrun", ovverosia il buffer (lato "ricevitore", e.g. NAA) viene "svuotato" con una velocità superiore a quella con cui viene "riempito" e quindi lo stream sincrono a valle che "rifornisce" il DAC non ha di che alimentarsi.

In tali condizioni, a seconda dei casi (dell'implementazione dei vari sistemi) il campione/i mancante/i viene sostituito con uno "vuoto" (cioè con un campione corrispondente al silenzio), con la ripetizione di campioni ricevuti in precedenza (caso abbastanza tipico laddove si impiegano "buffer circolari") oppure ancora con valori più o meno casuali (e.g. locazioni di memoria non inizializzate).

In tutti i casi, ogni volta che si verifica un "underrun" ciò che ne consegue è inevitabilmente un "glitch" nella riproduzione.

Tali "glitch" possono risultare più o meno evidenti (come tali) all'ascolto in funzione della loro lunghezza (durata), del tipo di dati "spuri" che vanno a sostituire i campioni mancanti (nonché dal contenuto dei campioni "reali" che precedono e seguono il glitch).

In particolare "glitch" lunghi e poco frequenti sono immediatamente percepibili come tali, in modo evidente, similmente a quanto avviene per i graffi profondi sulla superficie di un LP.

Viceversa, "glitch" molto brevi (ad es. della durata di pochi "sample") non sono percepibili, quanto meno non come tali. Verosimilmente, se sono molto frequenti potrebbero essere percepiti come un "cambiamento" nella qualità del suono (più avanti torno su questo punto, provando a spiegarmi meglio).

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,

dipende da cosa intendi per "disturbi". Se per "disturbi" intendi possibili "buffer underrun" (con ciò che ne consegue), questo è ovviamente vero.

Se invece ti riferisci al rumore EM generato dal PC non vedo motivi ovvi per cui un PC più potente ma meno carico debba necessariamente produrre meno rumore di uno più lento ma più "carico". Se sia vero questo, il suo contrario o se invece non esista alcuna semplice correlazione diretta tra le due cose sarebbe tutto da verificare. A naso direi che l'opzione più probabile sia l'ultima, perché quantità e "qualità" del rumore prodotto dipendono da un gran numero di fattori (senza dubbio incluso anche il "carico" della macchina, ma anche la sua velocità e molti altri fattori indipendenti).

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.

la questione è semplice: posto che tutto funzioni correttamente e (quindi) che i "disturbi" in questione rientrino nei limiti operativi, in un sistema informatico errori nei dati (e nei calcoli) non ce ne sono. Di conseguenza, tali "disturbi" semplicemente non possono avere alcun effetto diretto sulla sequenza di campioni che giungono al DAC... e quindi "sul suono".

Se si assume che invece (come molti sostengono) degli effetti ci sono (sono percepibili), esistono soltanto due possibilità: o il sistema non funziona correttamente (ed in qualche modo commette errori, provocando in qualche modo la corruzione dello stream di dati che giungono al DAC) o è necessario ipotizzare meccanismi diversi, che non coinvolgono l'integrità dei dati che giungono al DAC.

Nel secondo caso, visto che per quanto ci riguarda la connessione tra "sorgente" (PC) e DAC è ormai sempre asincrona e quindi effetti diretti sul Jitter (del clock del DAC) sono da escludersi, l'unica causa ipotizzabile (l'unica cosa che possa provocare una qualche alterazione del segnale audio senza modificare i campioni) è il rumore EM che in qualche modo raggiunge il DAC.

Tale rumore può agire sia più o meno direttamente (sovrapponendosi al segnale ed interferendo con il funzionamento dei circuiti analogici, ad es. per effetti di IM) che in modo indiretto, ad es. raggiungendo l'oscillatore di clock del DAC e causando un aumento del suo Jitter.

Al solito, è questione di capire cosa sia fisicamente possibile e cosa invece non lo è. Se un fenomeno è fisicamente possibile (per quanto improbabile e/o di scarsa entità) si può discutere all'infinito se questo possa o meno essere anche percepibile all'ascolto. Ed ovviamente possono sempre esistere una infinità di fenomeni fisicamente possibili ma "sconosciuti", nel senso che non sono stati adeguatamente investigati o presi in considerazione, almeno nel contesto specifico.

Se invece si ipotizza un fenomeno che è fisicamente impossibile, c'è poco da discutere: ciascuno è libero di credere ciò che vuole, anche che gli asini volano, ma resta il fatto che se si crede in qualcosa che è fisicamente impossibile si sta sicuramente prendendo una solenne cantonata.

Un approccio empirico non è necessariamente sbagliato anzi, al contrario, direi che è fondamentale. Specie in un campo come quello della riproduzione musicale, laddove è evidente che esistono ancora un gran numero di fenomeni tutt'altro che chiari e ben definiti (e per altro molto difficili da indagare, essendo legati ai meccanismi percettivi umani).

Se però si prescinde da una comprensione dei sistemi con cui si ha a che fare si rischia di prendere le proverbiali lucciole per lanterne, finire fuori strada, procedere in circoli viziosi e non arrivare mai da nessuna parte.

Per cui, per prima cosa, è necessario separare il grano dal loglio e capire cosa è fisicamente possibile e cosa invece non lo è, per poter poi utilizzare questa informazione fondamentale per cercare di interpretare correttamente i risultati di ciò che si osserva sperimentalmente, così da evitare di prendere cantonate, giungendo a conclusioni errate e fuorvianti.

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.

senza dubbio, l'idea è proprio quella: "allontanare" il più possibile (sia fisicamente che metaforicamente) le sorgenti di rumore dagli elementi sensibili.

Purtroppo, pensare che il problema si possa risolvere completamente, alla radice, banalmente con l'isolamento galvanico e/o con un approccio client/server tipo quello HQP+NAA è solo una pia illusione. Queste infatti sono senza dubbio misure potenzialmente utili a ridurre l'entità del problema, ma ben difficilmente possono eliminarlo del tutto.

Ad es., l'isolamento galvanico dato da un trasformatore (come quelli presenti nelle reti Ethernet su cavi UTP/STP) "taglia" la DC e le frequenze più basse (e con questo previene anche eventuali "ground loop", con tutto ciò che ne consegue) ma, in un modo o nell'altro, sia pure con una certa attenuazione variabile con la frequenza, lascia passare (quasi) tutto il resto. Incluse le componenti del rumore a frequenze sufficientemente alte (sia quelle di modo differenziale che, per effetto degli inevitabili elementi parassiti, quelle di modo comune).

Un accoppiamento in fibra ottica ha il vantaggio di eliminare qualsiasi accoppiamento di tipo elettrico, così che tutte le componenti di rumore di modo comune (e quelle "fuori banda") vengono bloccate completamente, mentre le restanti componenti di modo differenziale dovrebbero essere (quasi) del tutto eliminate dai circuiti di condizionamento del segnale necessariamente presenti ad entrambi gli estremi della linea.

Inoltre qualsiasi conduttore elettrico (incluso il cavo Ethernet) costituisce inevitabilmente una "antenna" in grado di captare il rumore EM presente nell'ambiente circostante e veicolarlo verso i circuiti che vi sono in qualche modo collegati, cosa che al contrario non accade con le connessioni in fibra ottica (che sono costituite interamente da materiali isolanti). Ovviamente, stesso dicasi per una connessione senza fili.

Va da sé però che anche i segnali che "girano" nelle interfacce di rete, siano esse in rame, in fibra o Wireless, dal punto di vista del DAC costituiscono rumore di per sé stessi. Per giunta si tratta di un "rumore" inevitabilmente correlato con i dati in transito e quindi, in qualche misura, indirettamente correlati anche con l'attività del PC remoto. E questo anche se il PC stesso è connesso attraverso Internet e fisicamente si trova all'altro capo del mondo!

b. quello che tu indichi come problemi di "buffer underrun" sono ...problemi di buffer o latenza...

Ovvio che sono problemi di buffering... lo dice il nome stesso.

BTW: la latenza (o tempo di latenza) non è che l'intervallo di tempo che intercorre fra il momento in cui arriva un input al sistema ed il momento in cui diventa disponibile l'output corrispondente. In altre parole, la latenza non è altro che una misura della velocità di risposta del sistema (ad es., nel nostro caso la latenza complessiva del sistema è la misura del ritardo tra il momento in cui premi "play" e quello in cui cominci a sentire musica).

In alcune applicazioni la latenza può essere un parametro importante se non fondamentale, ad es. quando si considera la risposta agli eventi dei dispositivi di input come tastiere e mouse, tastiere MIDI, ecc. Oppure quando si ha a che fare con diversi data-stream che devono essere sincronizzati tra di loro (ad es. per l'A/V, in alcune applicazioni DAW, ecc).

Per quanto ci riguarda, la latenza potrebbe essere rilevante esclusivamente nel caso in cui uno o più dei software utilizzati separino lo stream audio stereo in due stream mono indipendenti (uno per canale) per processarli separatamente e poi ri-sincronizzarli alla meno peggio prima di inviarli all'uscita. In tal caso, problemi di latenza potrebbero causare un errato (ri)"allineamento" tra i due canali, con le immaginabili conseguenze del caso. Ma dubito fortemente che esista qualcuno così folle da aver fatto davvero una cosa del genere...

Quindi, in definitiva (almeno finché non assuma valori veramente "abnormi", tali da rendere scomodo l'impiego del sistema) per le nostre applicazioni la latenza è un parametro sostanzialmente irrilevante.

Almeno di per sé stesso: non ho modo di escludere che variando la latenza di alcuni processi non si possa alterare lo spettro del rumore EM prodotto dal PC e/o la sua correlazione con lo stream audio (anzi, questo è anche piuttosto probabile). Almeno in linea di principio, non è inoltre impossibile che possano esserci degli effetti secondari, indiretti, che in qualche modo possano arrivare ad influenzare il segnale audio in funzione delle "attività" svolte dal PC (dai processi che ci girano). Di conseguenza, non è del tutto impossibile che le latenze dei vari processi che girano sulla sorgente abbiano una qualche ripercussione sull'uscita analogica del sistema (ancorché personalmente ritengo alquanto improbabile che tali eventuali effetti -ammesso che ci siano- abbiano entità tale da poter essere "sensibili", cioè percepibili... ma questo è un altro discorso).

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.

ottima analogia.

Il punto è però che (salvo casi particolari, tipo conversioni PCM->DSD "estreme") oggi disponiamo di sistemi che sono perfettamente in grado di far fronte alle esigenze richieste dalle nostre applicazioni audio, di solito anche con margini abbondanti. Per cui, se il sistema è dimensionato e configurato correttamente, di "buchi" non dovrebbero essercene affatto.

Vale però la pena di chiedersi: qualora di "buchi" ve ne siano, nel nostro caso è meglio che siano "piccoli" ma frequenti o piuttosto "grandi" ma rari?

IMO, è molto meglio che siano "grandi" (cioè, "lunghi") ma rari, piuttosto che piccoli (cioè brevi) ma frequenti!

Questo perché, come dicevo prima, mentre un buco "grande" (diciamo con durata > 0.1s) risulta palesemente percepibile come tale, e quindi ci si rende conto immediatamente che c'è un problema (e di che natura è), "buchi" anche molto frequenti ma molto brevi sfuggono facilmente alla nostra percezione "diretta".

Ad es., se ci fosse un singolo campione "mancante" (vuoto, ripetuto o alterato) diciamo ogni 100 campioni, questo costituirebbe un problema abnorme: un sistema che si comportasse in questo modo sarebbe semplicemente "rotto", malfunzionante.

Eppure, all'ascolto un simile problema non verrebbe affatto percepito direttamente, identificandolo come tale, ma solo come un qualche (probabilmente lieve) cambiamento nella "qualità" del suono! :o

L'effetto di un simile problema sarebbe infatti sostanzialmente quello dell'introduzione di una modesta quantità di "rumore" nel segnale audio ricostruito, qualcosa di simile ad una forma di distorsione non-lineare (di entità non particolarmente elevata) che, all'ascolto, così come altre forme di distorsione non lineare di entità moderata non risulta direttamente percepibile come un malfunzionamento del sistema ma solo come un leggero cambiamento nella "qualità del suono" (e/o, come giustamente dicevi, possibile fonte di fastidio e/o fatica d'ascolto).

quindi cambiando CPU o lunghezza di world certo che 'può' cambiare i dati,

direi... "ni". Ovviamente la precisione conta eccome ma, ancorché in qualche caso possano effettivamente esserci degli effetti legati al (tipo di) hardware impiegato, in pratica la precisione dipende quasi esclusivamente da come è scritto il software piuttosto che dall'hardware (del PC). Ad es., se il software usa variabili a 32bit (o meno), farlo girare su una architettura a 64 bit piuttosto che su una a 32 non cambia minimamente la sua precisione, mentre nulla vieta di utilizzare variabili a 64 o più bit anche su architetture che hanno word molto più piccole (ovviamente si pongono problemi di prestazioni... ma questo è un altro discorso).

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

qui mi sono perso... a cosa ti riferivi?

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.

Idem. Che volevi dire?

[Maggio]

ieri sera stavo scaricando da internet abbastanza sostenuto, dal momento che anche il sistema audio passa per quel router , alla fine la riproduzione dava parecchi disturbi !!!!
serve quindi un collegamento diretto
sarebbe l'optimum per tutti...

e non mi dite che poi il cavo dire te elimina tutti i problemi e che il sistema naa è esente da disturbi ! ieri sera l'ho provato di persona ! c'erano scoppietii e micro interruzioni

Che router utilizzi?
Per non aver problemi dovresti utilizzare un Gigabit L2 Managed Switch e configurarlo dando priorità alle porte che ti interessano.

[krellz]

allora ho cpu i7 4770k carico massimo circa 20 percento, tutta la rete è gigabit il router è il top della netgear (devo però usare anche un secondo router quello che dà fastweb per fibra)(ma è collegato ad un altro adattatore di rete sul pc)

il problema è che ieri sera stavo facendo download a circa 100 megabit avevo saturato tutta la banda internet, non so se questo possa causare qualche problema al router ma cmq ho avvertito quei problemi da me descritti nei post sopra.
stasera riprovo e vi aggiorno...

alla fine avrei desiderio (per semplificare le cose) di provare un collegamento diretto pc--> naa