Il NAA, questo sconosciuto...

[UnixMan]

Ma sul PC server oltre HQPlayer devo istallare i driver ASIO?

no.

Mah, non è detto, forse basterebbe anche un mini pc ma che rispetti alcuni requisiti minimi di qualità.

una cosa importante è come sono connessi i vari "bus" interni. Ad es., IMO un requisito senz'altro importante è che non ci sia condivisione di risorse tra l'interfaccia USB per il DAC e quella Ethernet.

per esempio, oggi ho effettuato altre prove con la nuova versione di HQP (3.6.1) e ho confrontato tre diversi naa (Cubox-i 2 Ultra - quindi su architettura ARM - , Zotac PI320 con Intel Atom, laptop Asus con Intel i5),

con OS diversi, o tutti con lo stesso?

mi sa che ha ragione Miska e che, come anch'io avevo ipotizzato, il vero collo di bottiglia è la condivisione ethernet/usb.

yup... direi proprio.

Io non sono così convinto che - come loro sostengono - la conversione PCM>DSD sia utile soltanto per i files di partenza a comune risoluzione cd (44.1 khz), mentre per le risoluzioni PCM più elevate, come pure per i files dsf, sia inutile o addirittura peggiorativa.
Io - umilissimo appassionato di hifi, e che certamente non sono nessuno al loro confronto - continuo a sentire il contrario. Proprio stamattina ho effettuato altre prove con files PCM a 24 bit e 192 khz, ebbene, ascoltando in PCM avverto quel tipico senso di metallico, di asprezza digitale, e [...]
Poi poco mi interessa se, dal punto di vista dei professori e tecnici, la conversione dsd anche di questo tipo di file a risoluzioni più elevate non dovrebbe essere tecnicamente corretta.

tutto dipende dal DAC (PCM) che usi... se suona male, suona male. La conversione in DSD (sia che tu usi un "NoDAC" che la eventuale modalità DSD del tuo stesso DAC, che in pratica normalmente non è poi molto diversa dal "NoDAC") elimina/disattiva/by-passa quasi tutte le funzioni del DAC hardware, che di fatto viene sostituito da un "DAC software" (il modulatore DSD di HQPlayer o chi per lui).

Nel tuo caso (così come in altri) è proprio quello a suonare meglio... del tuo DAC PCM hardware. A prescindere dal materiale di partenza.

Attenzione però alle facili generalizzazioni... con un buon DAC PCM che suona bene di suo potrebbe facilmente essere vero il contrario.

Io.. il mio cmp2 al momento è naa Linux. . Perché?

niente di che: ero curioso di sapere se/quali/quanti confronti erano stati fatti tra piattaforme hardware diverse (a parità di OS/software), in particolare tra ARM ed x86, e con quali risultati.

Nel mio caso si tratta(va) di un Mac mini i5 con sopra MacOSX (mi riferisco al NAA).

appunto. Da un punto di vista dell'architettura, gli "iMac" altro non sono che normalissimi PC marchiati Apple. Tant'è che (anche se legalmente non si potrebbe, stante i termini delle licenze dell'OS di Apple) c'è anche chi fa girare MacOS/X su PC assemblati in proprio con componenti standard...

Dove è stato appurato che 8.1 va meglio come NAA??
Io proverei XP in cMP mode e WinServer 2012 R2 in core mode

Concordo. Se proprio volete usare windoze, mi sembrano scelte molto più sensate. Specie la seconda. Mettere un sistema desktop completo con tanto di GUI su un server dedicato che non deve far altro che ricevere pacchetti di dati dalla rete e ritrasmetterli così come sono su un bus USB è pura follia...

[bibo01]

...
Concordo. Se proprio volete usare windoze, mi sembrano scelte molto più sensate. Specie la seconda. Mettere un sistema desktop completo con tanto di GUI su un server dedicato che non deve far altro che ricevere pacchetti di dati dalla rete e ritrasmetterli così come sono su un bus USB è pura follia...

La scelta di Windows ha senso in relazione ai driver ASIO.
Infatti, scegliere una motherboard a 4 strati con una buona messa a terra ha dei benefici anche se si sceglie un Linux server snellito ai minimi termini.
La differenza, però, la possono fare i driver ASIO qualora questi fossero scritti bene e customizzati ad hoc per l'hardware perché possono raggiungere un grado di integrazione maggiore rispetto ad un'implementazione standard UAC 2.0 che ha maggiori overheads.

[UnixMan]

La scelta di Windows ha senso in relazione ai driver ASIO.

questo è senza dubbio utile laddove l'hardware specifico non sia (ancora) ben supportato da ALSA...

La differenza, però, la possono fare i driver ASIO qualora questi fossero scritti bene e customizzati ad hoc per l'hardware perché possono raggiungere un grado di integrazione maggiore rispetto ad un'implementazione standard UAC 2.0 che ha maggiori overheads.

Eh? e questo chi lo dice?

Perché mai (in generale) i driver ASIO dovrebbero avere un overhead minore di quelli ALSA?

IMHO casomai è più probabile che sia vero il contrario: in generale un kernel "monolitico" come quello di Linux ha molto meno overhead di un "microkernel" come quelli di windows NT (e successivi).

[bibo01]

questo è senza dubbio utile laddove l'hardware specifico non sia (ancora) ben supportato da ALSA...


Eh? e questo chi lo dice?

Perché mai (in generale) i driver ASIO dovrebbero avere un overhead minore di quelli ALSA?

IMHO casomai è più probabile che sia vero il contrario: in generale un kernel "monolitico" come quello di Linux ha molto meno overhead di un "microkernel" come quelli di windows NT (e successivi).

Devo rispondere?!
Lo dico io ...e soprattutto svariati progettisti all'avanguardia di DAC

Intendiamoci, ASIO di per sé non è la panacea, ma il confronto è con le specifiche UAC 2.0, dato che di quello si stava parlando. Sei mai andato a leggere tali specifiche?! Sono dense, poco chiare e farraginose; inoltre, mi sembra che non prevedano il bitstreaming DSD. Lo standard UAC 2.0 è spesso troppo rigido rispetto ad uno sviluppo proprietario.

[UnixMan]

Devo rispondere?!

la domanda era retorica... non mi interessano inutili, irrilevanti ed inconcludenti "Ipse Dixit".

Portami delle solide argomentazioni tecniche documentate, verificate e verificabili e ne possiamo discutere... altrimenti mi spiace dirtelo ma l'affermazione non sta in piedi, non è altro che fuffa. Se non vero e proprio "FUD", magari messo in giro da chi ha interesse a vendere i propri driver proprietari.

Tra parentesi, lo sai vero che la quasi totalità dei driver "proprietari" sono in realtà driver "standard" prodotti da terze parti (due o tre ditte specializzate...) e poi dati in licenza ai vari produttori di hardware dopo averli opportunamente "castrati" in modo che riconoscano esclusivamente la scheda (o le schede) per cui sono stati dati in licenza? E lo sai che, in molti casi, basta editare opportunamente il relativo file ".inf" per fargli riconoscere e quindi farlo funzionare anche con qualsiasi altra scheda che ha la medesima interfaccia hardware?

Intendiamoci, ASIO di per sé non è la panacea, ma il confronto è con le specifiche UAC 2.0, dato che di quello si stava parlando. Sei mai andato a leggere tali specifiche?! Sono dense, poco chiare e farraginose; inoltre, mi sembra che non prevedano il bitstreaming DSD. Lo standard UAC 2.0 è spesso troppo rigido rispetto ad uno sviluppo proprietario.

??

Bibo, Bibo... che c'entra ASIO (che in sostanza non è altro che una "API", pensata per poter offrire ai programmi applicativi una interfaccia "comune" alternativa che by-passa tutta la gestione nativa dell'audio in windows...) con l'UAC2, che è invece uno standard di comunicazione per il trasferimento di dati audio sul bus USB?

Come pensi che facciano i driver proprietari (ASIO o meno che siano) per comunicare via USB con un hardware che "parla" UAC2, se non proprio utilizzando quello stesso protocollo?

...che poi possano esserci differenze tra driver (effettivamente) diversi, che questi possano avere implementazioni leggermente diverse dello standard UAC2 (e magari in qualche caso includere estensioni non-standard specifiche di un determinato hardware) è a dir poco probabile (per non dire certo), ma si tratta appunto di differenze specifiche tra un particolare driver ed un altro: non hanno nulla a che vedere con il fatto che si tratti di un driver per un determinato OS piuttosto che per un altro, o che presentino al software (o ai "middleware") soprastanti una interfaccia ALSA piuttosto che OSS, ASIO piuttosto che KS, ecc.

[UnixMan]

P.S.:

piuttosto, se veramente si vuole ridurre l'overhead e migliorare sensibilmente le prestazioni di NAA, la cosa da fare sarebbe quella di implementare il "core" di NAA (cioè la parte "real-time", quella che materialmente copia i dati dall'interfaccia TCP/IP a quella USB) direttamente in kernel space ovvero, nel caso di Linux, ri-scrivendola sotto forma di un modulo del Kernel.

In questo modo si potrebbero evitare un mare di mode transition e di context-switch, rendendo il codice molto più efficiente.

(oppure -cosa che probabilmente sarebbe più semplice nonché, se ben fatta, forse anche migliore- potrebbe riscrivere il NAA per farlo girare su un buon vecchio "DOS" come e.g. FreeDOS. Non essendo il DOS un vero e proprio OS, essendo privo di un vero e proprio Kernel degno di questo nome, essendo "single-task" e facendo girare tutto interamente a "ring 0", sarebbe il sistema ideale per applicazioni real-time single-task. Se solo ci fossero i driver per le interfacce audio...).

[aletas]

Oggi ho avuto modo di provare HQPlayer tramite NAA; come dicevo mi son fatto prestare un PC tower con I7 win 8.1 connesso al router tramite ethernet e come NAA ho usato il notebook di casa I7 win 8.1.
Dopo il primo intoppo dei driver ASIO risolto con l'aiuto di bibo ho potuto sperimentare i vari settaggi con "upsampler" PCM>DSD superiori a 128x.
Il notebook = NAA collegato in WiFi oltre 128x non ce la fa proprio nella mia rete e ho dovuto provvedere con una prolunga ethernet (dove ascolto non c'è un punto ethernet) e comunque qualche drop out ogni tanto si faceva notare.
A questo punto ho connesso il PC tower direttamente alla Amanero e naturalmente tutto è filato liscio.
Invece non ho potuto sperimentare 512x perché i drop out rendevano inascoltabile il file.
Ma possibile che per fare upsampler oltre 256 serva un mainframe? Sbaglio qualcosa nella configurazione di HQPlayer?
Però una considerazione fuori dal coro la voglio fare: secondo me quando si vuole andare oltre con gli up il NAA non apporta nessun beneficio ma può rappresentare solo una complicazione-limitazione e il fatto che JRiver non consenta up oltre 128 mi fa pensare che fino a quel limite tutto il sistema (PC -rete- NAA) regga mentre oltre o è tutto superottimizzato o i risultati sono fallimentari.
Nel mio caso, oltretutto stò sperimentando (con ottimi risultati) l'isolamento galvanico con un trasformatore dopo il filtro RC quindi vorrei ottimizzare al massimo il PC collegato direttamente senza NAA e con il so ottimizzato al massimo.
A proposito per ottimizzare win 8 c'è una specifico 3D? (ho cercato velocemente senza trovare nulla)

[bigtube]

P.S.:

piuttosto, se veramente si vuole ridurre l'overhead e migliorare sensibilmente le prestazioni di NAA, la cosa da fare sarebbe quella di implementare il "core" di NAA (cioè la parte "real-time", quella che materialmente copia i dati dall'interfaccia TCP/IP a quella USB) direttamente in kernel space ovvero, nel caso di Linux, ri-scrivendola sotto forma di un modulo del Kernel.

In questo modo si potrebbero evitare un mare di mode transition e di context-switch, rendendo il codice molto più efficiente.

Paolo ci dici di piu' su come realizzare una cosa del genere . Per esempio che tu sappia è stato attuato su Voyage o su altri sistemi Linux compreso Daphile(x86)? Da cio' che lasci intuire
cio' implicherebbe una attenta ricompilazione del Kernel soprattutto se in Real Time.
Di sicuro con il Raspberry cio' non è stato possibile se non in parte per evidenti problemi hardware(USB in comunione con il network).

[bibo01]

P.S.:

piuttosto, se veramente si vuole ridurre l'overhead e migliorare sensibilmente le prestazioni di NAA, la cosa da fare sarebbe quella di implementare il "core" di NAA (cioè la parte "real-time", quella che materialmente copia i dati dall'interfaccia TCP/IP a quella USB) direttamente in kernel space ovvero, nel caso di Linux, ri-scrivendola sotto forma di un modulo del Kernel.

...

Non c'è vantaggio a spostare networkaudiod in kernel space. Anzi, peggiorerebbe parecchie cose perché molti dei kernel services non sono disponibili in kernel space nella stessa maniera. Inoltre, Miska promuove fortemente OS di tipo microkernel.

[pocarrie]

con OS diversi, o tutti con lo stesso?

se ti riferisci (credo di sì, ovviamente) ai tre NAA, naturalmente non potevano tutti avere lo stesso OS: sul Cubox-i gira Linux come da immagine iso aggiornata fornita da Miska, sullo Zotac Win 8.1 N 32 bit preinstallato, sul laptop Asus Win 8.1 64 bit.
Il pc server invece era sempre lo stesso, ed è quello che si può vedere in configurazione qui a lato.