Abbiamo tollerato? | Stampa

Quoto da un sito di vendita di prodotti hifi:

"Il Merging-Nadac ha messo in discussione la convenzionale connessione usb, proponendo lo standard di connessione Ravenna che risulta molto più efficiente. Allo stesso modo e con un passo logico successivo il Nadac Player sfida la convenzione di avere un computer collegato all’impianto hifi. In effetti il computer non è il mezzo qualitativamente migliore ed ergonomico per accedere alla libreria musicale, ma fino ad oggi è stato in un certo senso tollerato perché rappresentava un mezzo per eseguire il software di lettura per i files musicali ad alta definizione."

Il NADAC Player non è altro che una scheda aggiuntiva, cioè un computer, messa all'interno del NADAC.

Un Naa incorporato?

Qualcosa del genere ... o un Roon Point

Quote:

---

Originariamente inviato da rogers

Quoto da un sito di vendita di prodotti hifi:

"Il Merging-Nadac ha messo in discussione la convenzionale connessione usb, proponendo lo standard di connessione Ravenna che risulta molto più efficiente. Allo stesso modo e con un passo logico successivo il Nadac Player sfida la convenzione di avere un computer collegato all’impianto hifi. In effetti il computer non è il mezzo qualitativamente migliore ed ergonomico per accedere alla libreria musicale, ma fino ad oggi è stato in un certo senso tollerato perché rappresentava un mezzo per eseguire il software di lettura per i files musicali ad alta definizione."

---

vabbè, marketing...allo stesso modo si diceva che lo squeezebox non poteva essere considerato "Hifi"...

Sappiamo bene che qualsiasi dispositivo che riceva dati da ethernet, con qualsiasi protocollo, Ravenna incluso, deve essere dotato di un NIC di rete, una CPU ed un qualche sistema di interfaccia al DAC, magari I2S. Deve poter eseguire istruzioni e - ameno di non tornare agli anni 70 - questo vuol dire essere dotato di una qualche forma di OS (al 99% Linux) ed di un player software.

Vogliamo dare il nome a questa 'cosa' per me è un computer. L'unico punto sul quale sono assolutamente d'accordo è la opportunità/necessità di eliminare USB dal percorso, per il resto si tratta di maggiore o minore qualità costruttiva * hardware e software - in funzione del fine per cui è progettato.

Se per togliere il computer dalla sala d'ascolto lo mettiamo dentro al dac (come abbiamo già visto fare) non mi pare un grosso passo avanti...

L'Hapi è una macchina Linux (basta farci telnet per vedere il prompt). Non sono sicuro al 100% per il Nadac, ma credo che anch'esso sia Linux. Il Nadac player ha all'interno una scheda che fa girare un player Roon scritto in collaborazione tra Merging e Roon. Sì direi che è un computer Linux alla fine :)

Non so cosa volesse intendere la frase, ma credo che lo scopo del Nadac player sia quello di evitare all'utente l'ottimizzazione del computer per uso audio, che non tutti sono in grado di fare. L'ottimizzazione in pratica te la fa la casa madre tramite gli aggiornamenti del suo firmware. Inoltre, pare che il Nadac player usi all'interno un driver Linux che non è purtroppo disponibile pubblicamente (altrimenti avrei impostato Linux sul mio computer che comunica con l'Hapi invece che Window).

Quote:

---

Originariamente inviato da robertopisa

L'Hapi è una macchina Linux (basta farci telnet per vedere il prompt). Non sono sicuro al 100% per il Nadac, ma credo che anch'esso sia Linux. Il Nadac player ha all'interno una scheda che fa girare un player Roon scritto in collaborazione tra Merging e Roon. Sì direi che è un computer Linux alla fine :)

Non so cosa volesse intendere la frase, ma credo che lo scopo del Nadac player sia quello di evitare all'utente l'ottimizzazione del computer per uso audio, che non tutti sono in grado di fare. L'ottimizzazione in pratica te la fa la casa madre tramite gli aggiornamenti del suo firmware. Inoltre, pare che il Nadac player usi all'interno un driver Linux che non è purtroppo disponibile pubblicamente (altrimenti avrei impostato Linux sul mio computer che comunica con l'Hapi invece che Window).

---

Si, immaginavo fosse così, come è sempre stato, a partire dallo Squeezebox. In questo senso ritengo la frase per come è espressa 'marketing truffaldino', dato che si basa sull'enunciazione di due mezze verità per sostenere l'enunciazione di una terza 'come passo logico conseguente'...

Non ho capito qual'è il driver mancante per Linux, ma questo è esattamente quello che NON mi piace di Ravenna e simili, pur avendo - di fatto - un pc al proprio interno i 'client', si presentano come 'dummy devices' e necessitano di essere gestiti da un driver 'server'.

Ancora una volta, lo capisco in ambito PRO, per motivi di continuità con le pratiche consolidate, ma mi pare limitativo e prono a problemi di compatibilità (come quelli che presenta).

p.s. parzialmente OT

Ho letto parte del suo articolo su CHF, purtroppo non tutto, mi piacerebbe poterlo fare ma non so dove recuperarlo, vorrei capire dove lei vede la superiorità di Ravenna, Dante o anche solo AVB rispetto al semplice TCP/IP ove si tratti di riprodurre un singolo stream multicanale MA su un unico 'renderer', l'API in questo caso.

Mi è invece chiaro il vantaggio quando si devono effettuare misaggi di stream remoti o anche solo sincronizzare le riproduzioni su diversi devices, come ad esempio i monitor su un palco, ma la topologia è completamente diversa ed è necessario ricostruire la sincronia sui diversi stream, cosa che - per definizione - non è necessaria con un solo stream.

La ringrazio in anticipo se vorrà approfondire.

Marco qua ci diamo tutti del tu :)

Il protocollo Ravenna è stato sviluppato da una ditta di Monaco, la ALC NetworX. Ma lo sviluppo di punta credo che sia presso la Merging, che ha un team di ingegneri e informatici molto competenti e si vede che ci sguazzano bene in sistemi Linux.

Purtroppo l’audio pro è principalmente sotto Windows e hanno quindi sviluppato un driver ASIO che in pratica è un “wrapper” per il protocollo Ravenna. In questo modo, un qualunque sw che si basa su ASIO può collegarsi a una macchina Ravenna o AES67 (in teoria) attraverso la rete. Analoga cosa sarebbe utile in Linux, magari tirando fuori un driver ALSA, però non hanno interesse a investirci.

Almeno fino al Nadac player, dove di fatto hanno affiancato al Nadac un sistema interno embedded Linux che usa Ravenna per comunicare. Per far ciò hanno sviluppato un driver Linux, ma non so se sia ALSA o altro. Certamente hanno collaborato con quelli di Roon per questo player interno.

Questa cosa del server / client si capisce meglio in ambito pro, come suggerisci. Devo dire che è spettacolare e uno si chiede perché non l’abbiano fatto prima visto che la tecnologia che usano non è space rocket… esiste da diverso tempo, forse tranne il protocollo per sincronizzare. Qui ho descritto un concerto live con questa tecnologia, dove ne ho capito l’utilità

A un concerto live il suono è analogico o digitale?

In ambito audiofilo, in effetti usare Ravenna può sembrare la classica accetta per affettare il salame :) Un’ottima implementazione I2S può dare altrettanti soddisfazioni. In realtà, Ravenna ha un suo senso se uno utilizza un collegamento a fibra ottica (con i media converter) tra PC e Hapi/Horus/Nadac: in questo modo il PC viene isolato elettricamente dall’impianto audio, in modo trasparente, specialmente se colloca il PC molto lontano dall’impianto (io ce l’ho a 4-5 metri). Ho provato mettere un ottimo cavo in rame al posto della fibra e il suono è diventato pìu graffiante.

Riguardo alla compatibilità manca volutamente l’ingresso USB e, purtroppo, l’I2S. Volendo con l’Hapi si possono usare anche SPDIF (ottico o meno) o AES/EBU, utilizzanto il suo master clock. Per esempio, uso il mio lettore Marantz come meccanica, collegato via cavo ottico (Blue Jean) all’Hapi; il Marantz accetta inoltre il clock esterno proveniente dall’Hapi, e devo dire che il suono è sorprendentemente buono visto che uso la connessione ottica (il clock dell’Hapi aggiusta tutto).

Se mi mandi in MP il tuo indirizzo ti posta, ti mando uno scan dell’articolo CHF. Comunque è molto divulgativo non affronta questioni tecniche (la redazione mi aveva chiesto di essere divulgativo ma giustamente i forumisti di CHF si aspettavano qualcosa di più tecnico che avrei volentieri scritto).

Durante la scrittura, c’è stato un piccolo aneddoto con uno dei responsabili di ALC NetworX. Gli ho chiesto se potevo avere la loro libreria Ravenna per uso “educational”, la risposta è stata no perché costa 5000 euro. Allora ho chiesto se, nel caso avessi trovato un finanziamento come università, potevo comprare la libreria: la risposta è stata no perché loro la danno solo per partner commerciali. Al che gli ho fatto notare, mandandolo su tutte le furie, perché definiscano Ravenna un open standard. Per esempio, ASIO lo è ma rende pubblica una libreria SDK dove puoi provare a programmartelo… vabbè, dimentico che c’è sempre un aspetto commerciale dietro queste cose.

Riguardo a usare solo TCP. Teoricamente, l”Hapi dovrebbe accettare direttamente i comandi RTSP (https://en.wikipedia.org/wiki/Real_T...aming_Protocol), quindi non c’è strettamente bisogno di Ravenna. In realtà non sono riuscito a farlo funzionare solo con RTSP (ci avevo provato l’anno scorso, magari le cose sono cambiate). Il punto di forza è il meccanismo di sincronizzazione PTP.

Se uno potesse depositare il file audio direttamente dentro l’Hapi (per es. con FTP), avendo un buffer di capienza sufficiente, questo sarebbe la gioia di noi audiofili! Però nel mondo pro questa cosa non interessa, perché lavorano in real-time. Nonostante ciò, mi ritengo più soddisfatto a usare Ravenna che USB audio. Se potessi entrare nell’Hapi come macchina Linux (la password non viene fornita), proverei a mettere il file audio internamente. Magari un giorno ce lo permetteranno, ma questa cosa interessa a pochi di noi purtroppo. La maggior parte degli utenti pro lo usa con Pyramix o ProTools e non gli importa di avere tale accesso.

Quote:

---

Originariamente inviato da marcoc1712

Si, immaginavo fosse così, come è sempre stato, a partire dallo Squeezebox. In questo senso ritengo la frase per come è espressa 'marketing truffaldino', dato che si basa sull'enunciazione di due mezze verità per sostenere l'enunciazione di una terza 'come passo logico conseguente'...

Non ho capito qual'è il driver mancante per Linux, ma questo è esattamente quello che NON mi piace di Ravenna e simili, pur avendo - di fatto - un pc al proprio interno i 'client', si presentano come 'dummy devices' e necessitano di essere gestiti da un driver 'server'.

Ancora una volta, lo capisco in ambito PRO, per motivi di continuità con le pratiche consolidate, ma mi pare limitativo e prono a problemi di compatibilità (come quelli che presenta).

p.s. parzialmente OT

Ho letto parte del suo articolo su CHF, purtroppo non tutto, mi piacerebbe poterlo fare ma non so dove recuperarlo, vorrei capire dove lei vede la superiorità di Ravenna, Dante o anche solo AVB rispetto al semplice TCP/IP ove si tratti di riprodurre un singolo stream multicanale MA su un unico 'renderer', l'API in questo caso.

Mi è invece chiaro il vantaggio quando si devono effettuare misaggi di stream remoti o anche solo sincronizzare le riproduzioni su diversi devices, come ad esempio i monitor su un palco, ma la topologia è completamente diversa ed è necessario ricostruire la sincronia sui diversi stream, cosa che - per definizione - non è necessaria con un solo stream.

La ringrazio in anticipo se vorrà approfondire.

---

Quote:

---

Originariamente inviato da robertopisa

.

---

La mail è marcoc1712 at gmail dot com, grazie.

Però, se uno potesse depositare il file audio direttamente dentro l’Hapi (per es. con FTP), avendo un buffer di capienza sufficiente, questo sarebbe la gioia di noi audiofili! Però nel mondo pro questa cosa non interessa, perché lavorano in real-time. Nonostante ciò, mi ritengo più soddisfatto a usare Ravenna che USB audio. Se potessi entrare nell’Hapi come macchina Linux (la password non viene fornita), proverei a mettere il file audio internamente. Magari un giorno ce lo permetteranno, ma questa cosa interessa a pochi di noi purtroppo. La maggior parte degli utenti pro lo usa con Pyramix o ProTools e non gli importa di avere tale accesso.[/QUOTE]

Beh in ambito pro per forza devono usare il real time, pensa che casino sarebbe solo con le spie sul palco, per non parlare del mixer! Per questo i protocolli Audio over IP sono nati, trasferiscono AUDIO REAL TIME non files codificati, per questo da sempre mi chiedo il senso di Ravenna e simile ai nostri fini.

Dici che, potendo, depositare il file nell'HAPI sarebbe la soluzione, io non credo, che vantaggi avrebbe rispetto ad uno stream TPC/IP?

Non capisco il punto del driver e Roon:

Il driver è un fatto 'interno' tra il sistema embedded linux ed il DAC, non per permettere a sistemi esterni di vedere l'HApi come 'device'.

Esiste un Driver generico Ravenna per Linux? Se si, dovrebbe permettere di vedere L'HApi come device, se no, il problema è li e quello bisogna risolvere.

Come ha risolto Roon? Se l'HAPI è RON Ready, in quel caso non usa certo Ravenna (RAT è costruito su TCP/IP).

Nuovo press release della Merging Technologies per il Monaco High End:

Munich, May 2017: The introduction of MERGING+NADAC and then MERGING+PLAYER shook the high end audio world by introducing an Ethernet audio protocol in place of the conventional USB connection. RAVENNA offers numerous practical, performance and reliability advantages over USB and the results have been recorded in a series of rave reviews for these products.

Merging’s innovation did not stop there. Both products are offered in stereo or multichannel variants to cater for the former SACD enthusiasts, who can finally listen to the multichannel files as they should be heard. The partnership with Roon with the MERGING+PLAYER goes far beyond some of the simple “Roon Ready” implementations already released. The Roon UI was well accepted but was not capable of DSD multichannel playback. Since version 1.3, that has been implemented with many other new enhancements. This was a major result of the Merging/Roon partnership which is ongoing to introduce other new features.

The advantages of using Ethernet were plainly obvious to other DAC manufacturers and there has been much interest in how this could be be incorporated into other products. The RAVENNA Corner of the Merging stand J06 in Hall 3 will amply demonstrate where this is going. A Melco N1 Hi-Res Digital Music Source will be on display as will the Aurender X100 Digital Music Player. Both these popular products take advantage of Merging’s LINUX Virtual Audio Devicewhich could be adopted by other devices using the same operating system. Merging has also developed drivers for OSX and Windows to ensure that RAVENNA can be used with any computer platform. Of great interest will be the ROCK (Roon Optimized Core Kit) which will be running on a standard Intel NUC. ROCK is the software that Roon will make available to end users who want to build a DIY Roon device using an Intel NUC. This software is based on Roon OS, which is the current software Roon provides to partners (like Merging) who manufacture embedded Roon-based products. These products will be displayed directly connected to MERGING+NADAC via RAVENNA and all will commence shipping in the coming months.

Besides the manufactured products, Merging will introduce ZMan, a new compact and powerful RAVENNA circuit board which will be offered to OEM partners, bringing the advantages of a networked solution to audio components as diverse as loudspeakers, DACs and server/streamers. In addition to RAVENNA, this board will allow for a whole range of other capabilities like Roon Ready support, streaming services and DSP processing for advanced formats decoding or room correction for example. This OEM solution as well as associated development tools will be on display in the RAVENNA Corner and engineers will be available for answering technical questions.

Merging is also delighted to announce the impending introduction of MERGING+POWER as an addition to its audiophile product range. Critical acclaim suggests that MERGING+PLAYER and MERGING+NADAC sound amazing, so that would indicate that the designers did a fine job with the power supply. There is a body of opinion that maintains that removing all AC components from the chassis should improve the performance even more. MERGING+POWER is the answer. The unique hybrid design mixes switch mode and analog toroidal transformer technology to separate the different requirements of the key internal components. All key parts of the power plant meet aerospace or military specifications and have been selected to offer the ultimate in sonic integrity. MERGING+POWER is a product designed to add magic to excellence for the most discerning users.

@Marco1712

Alla fine Ravenna è praticamente uno stream TCP/IP solo che ha un forte controllo sulla sincronizzazione tra trasmettitore e ricevente. Con WireShark puoi guardare i pacchetti che transitano: oltre allo stream dei dati, c’è uno stream parallelo di sincronizzazione e controllo.

Depositare il file dentro l’Hapi non avrebbe il sovraccarico di gestire la rete durante il play (meno interrupt). Quando uso ASIO Ravenna sul PC, l’utiliy perfmon mostra un aumento significativo delle interrupt, inevitabile in ogni meccanismo di trasmissione. Questo vale probabilmente anche all’interno dell’Hapi, a cui non ho accesso. Se depositiamo prima il file (quindi niente gapless…) e poi lo ascoltiamo, teoricamente ci dovrebbero essere meno interrupt.

Non conosco i dettagli interni e quel poco che so me lo ha detto Igor Fiorini, il distributore italiano. Il driver Linux per Ravenna che usano internamente potrebbe, in linea di principio, essere usato anche su un PC esterno Linux: è quello che mi fa gola. Sì, non viene usato per mostrare l’Hapi come device, perché Hapi internamente ha un driver appositamente per questo (ma sono parenti, dovendo colloquiare tra di loro).

Purtroppo l’Hapi non è Roon ready, lo è il Nadac. Qui la strategia Merging ha deciso di separare le linee di sviluppo: l’Hapi è per il pro, mentre il Nadac è per il consumer (e costra tre volte tanto). Per Roon, hanno sviluppato appositamente un software congiunto da mettere dentro il sistema embedded Nadac+Player.

@Bibo01

Interessanti le news, le cose si stanno muovendo. Quando Federico (Grunter) e io abbiamo preso Ravenna e abbiamo detto che ci sembrava migliore dell’USB audio, siamo stati lapidati da alcuni forumisti. Credo che a breve si diffonderà con questa scheda hw Ravenna da inserire nei DAC etc.

Per il driver Linux non è chiaro se lo daranno anche a noi poveri utenti. E comunque potrebbe funzionare solo con Nadac ma non con Hapi (vedi sopra la nuova strategia di Merging). Per esempio la sola PSU per il Nadac costa più dell'Hapi...

Quote:

---

Originariamente inviato da bibo01

Nuovo press release della Merging Technologies per il Monaco High End:

Munich, May 2017: The introduction of MERGING+NADAC and then MERGING+PLAYER shook the high end audio world by introducing an Ethernet audio protocol in place of the conventional USB connection. RAVENNA offers numerous practical, performance and reliability advantages over USB and the results have been recorded in a series of rave reviews for these products.

Merging’s innovation did not stop there. Both products are offered in stereo or multichannel variants to cater for the former SACD enthusiasts, who can finally listen to the multichannel files as they should be heard. The partnership with Roon with the MERGING+PLAYER goes far beyond some of the simple “Roon Ready” implementations already released. The Roon UI was well accepted but was not capable of DSD multichannel playback. Since version 1.3, that has been implemented with many other new enhancements. This was a major result of the Merging/Roon partnership which is ongoing to introduce other new features.

The advantages of using Ethernet were plainly obvious to other DAC manufacturers and there has been much interest in how this could be be incorporated into other products. The RAVENNA Corner of the Merging stand J06 in Hall 3 will amply demonstrate where this is going. A Melco N1 Hi-Res Digital Music Source will be on display as will the Aurender X100 Digital Music Player. Both these popular products take advantage of Merging’s LINUX Virtual Audio Devicewhich could be adopted by other devices using the same operating system. Merging has also developed drivers for OSX and Windows to ensure that RAVENNA can be used with any computer platform. Of great interest will be the ROCK (Roon Optimized Core Kit) which will be running on a standard Intel NUC. ROCK is the software that Roon will make available to end users who want to build a DIY Roon device using an Intel NUC. This software is based on Roon OS, which is the current software Roon provides to partners (like Merging) who manufacture embedded Roon-based products. These products will be displayed directly connected to MERGING+NADAC via RAVENNA and all will commence shipping in the coming months.

Besides the manufactured products, Merging will introduce ZMan, a new compact and powerful RAVENNA circuit board which will be offered to OEM partners, bringing the advantages of a networked solution to audio components as diverse as loudspeakers, DACs and server/streamers. In addition to RAVENNA, this board will allow for a whole range of other capabilities like Roon Ready support, streaming services and DSP processing for advanced formats decoding or room correction for example. This OEM solution as well as associated development tools will be on display in the RAVENNA Corner and engineers will be available for answering technical questions.

Merging is also delighted to announce the impending introduction of MERGING+POWER as an addition to its audiophile product range. Critical acclaim suggests that MERGING+PLAYER and MERGING+NADAC sound amazing, so that would indicate that the designers did a fine job with the power supply. There is a body of opinion that maintains that removing all AC components from the chassis should improve the performance even more. MERGING+POWER is the answer. The unique hybrid design mixes switch mode and analog toroidal transformer technology to separate the different requirements of the key internal components. All key parts of the power plant meet aerospace or military specifications and have been selected to offer the ultimate in sonic integrity. MERGING+POWER is a product designed to add magic to excellence for the most discerning users.

---

Mi sembra che la cosa veramente interessante sia "Merging’s LINUX Virtual Audio Device" + "ZMan" e "ROCK" lato Roon ( "These products will be displayed directly connected to MERGING+NADAC via RAVENNA" ), staremo a vedere e soprattutto staremo a vedere se verrà rispettato lo spirito 'open' di Ravenna o meno.

Comunque, continuo a non vedere vantaggi particolari di RAvenna rispetto al TCP/IP ed a protocolli come, ad esempio RAT, continuano a presentarli verso USB e quelli sono chiari, ma non sono tipici di Ravenna, piuttosto comuni a qualsiasi soluzione basata su ethernet.

La differenza la fa l'implementazione: Ravenna è stato implementato da Merging in modo robusto. Teoricamente potresti farlo anche con altri come RAT, solo che la forza lavoro impiegata da Merging è enorme se paragonata agli altri, perché rivolta innanzi tutto al mercato pro. Nel campo audiofilo non ha ritorno economico fare un tale investimento. Merging ricicla buona parte di quello che ha sviluppato per il mercato pro, altrimenti non converrebbe neache a loro. Il decollo di Ravenna è avvenuto tramite Merging appunto per questo, non tramite ALC NetworX che ha lanciato Ravenna.

Quote:

---

Originariamente inviato da marcoc1712

Comunque, continuo a non vedere vantaggi particolari di RAvenna rispetto al TCP/IP ed a protocolli come, ad esempio RAT, continuano a presentarli verso USB e quelli sono chiari, ma non sono tipici di Ravenna, piuttosto comuni a qualsiasi soluzione basata su ethernet.

---

Quote:

---

Originariamente inviato da robertopisa

La differenza la fa l'implementazione: Ravenna è stato implementato da Merging in modo robusto. Teoricamente potresti farlo anche con altri come RAT, solo che la forza lavoro impiegata da Merging è enorme se paragonata agli altri, perché rivolta innanzi tutto al mercato pro. Nel campo audiofilo non ha ritorno economico fare un tale investimento. Merging ricicla buona parte di quello che ha sviluppato per il mercato pro, altrimenti non converrebbe neache a loro. Il decollo di Ravenna è avvenuto tramite Merging appunto per questo, non tramite ALC NetworX che ha lanciato Ravenna.

---

Il punto è COSA implementa RAVENNA - utile per la riproduzione multicanale di un UNICO stream - in più rispetto ad altri protocolli di livello OSI 5 o superiori?

Dal punto di vista funzionale, si presenta come un device 'schiavo' remoto, che deve essere 'agganciato' ad un 'master' tramite un Driver per poter essere usato. Per fare un analogia, è come utilizzare una stampante remota, NON un print server.

Ha dei vantaggi evidenti (rende remote in modo trasparente applicazioni nate per essere locali) ma perpetua una struttura master/slave, che è potenzialmente un limite e l'implementazione DIPENDE dalle caratteristiche del Master (oltre che dello slave). In altre parole ho bisogno di un driver che gestisca il dispositivo virtuale per ogni possibile Master, oltre a a quello 'vero' che gestisce il dispositivo fisico. E' un'architettura a stella, non a rete.

Aggiunge il controllo di precisione della latenza e la sincronizzazione precisa (a livello di nanosecondi) degli stream, ma - ribadisco - utilizzando un solo stream non ne capisco l'utilità.

Qui probabilmente sta la differenza di opinionie, che ho realizzato bene leggendo il tuo articolo ed in particolare la dissertazione su dimensione dei buffer / latenza / jitter.

A mio avviso si basa su un equivoco, che è lo stesso che riproponi (in senso inverso) quando parli di 'vantaggio' nel trasferire prima il file e quindi mandarlo in esecuzione da locale:

Quote:

---

Originariamente inviato da robertopisa

Depositare il file dentro l’Hapi non avrebbe il sovraccarico di gestire la rete durante il play (meno interrupt). Quando uso ASIO Ravenna sul PC, l’utiliy perfmon mostra un aumento significativo delle interrupt, inevitabile in ogni meccanismo di trasmissione. Questo vale probabilmente anche all’interno dell’Hapi, a cui non ho accesso. Se depositiamo prima il file (quindi niente gapless…) e poi lo ascoltiamo, teoricamente ci dovrebbero essere meno interrupt.

---

Lo stesso lo ottieni usando Buffer (applicativi) di grandi dimensioni in ingresso e ritardando l'inizio della riproduzione di un tempo adeguato, è il vantaggio di una connessione del tutto asincrona rispetto all'utilizzo dei dati.

Questo consente di ridurre - ed idealmente portare a 0, trasferendo il file come proponi - gli interrupt che la CPU riceve dal NIC o, meglio, dal buffer in ingresso, con l'effetto chiaramente osservabile di ottenere profili più o meno 'a dente di sega', concentrando gli altri (inevitabili) nel tempo in cui il player è inattivo (il buffer non si svuota).

Però attenzione, anche se leggi un file da disco hai buffers ed interrupt, quelli non sono evitabili se non - parzialmente - usando il RAMDISK, che è esattamente corrispondente ad un Buffer in ingresso di dimensioni adeguate a contenere TUTTO il brano in riproduzione.

Uno svantaggio di questo approccio è la rottura del gapeless, se vuoi evitare di riempire il RAMDISK/BUFFER durante la riproduzione del brano precedente.

In alcuni sistemi (es. dischi USB, SD, per non parlare di dati su NAS) l'utilizzo di files 'locali' comporta più interrupts rispetto a quelli provenienti dall'attività di rete.

Discorso completamente diverso quello relativo ai buffer di riproduzione (es. ALSA) ed immagino tu ti riferissi a quelli nel tuo articolo, che a favore di chi legge, quoto qui:

Quote:

---

Originariamente inviato da robertopisa

Ora entriamo in una zona delicata della discussione. A cosa mai serve la latenza per noiaudiofili se non dobbiamo mixare o monitorare un evento audio? C'è uno studio sulla rivista delsettore Sound on Sound [10] dove viene mostrato che il jitter aumenta con la dimensione deibuffer ASIO, che è un po’ controintuitivo. Per farmi un’idea, ho chiesto un po’ in giro a esperti:secondo me, il termine “bassa latenza” andrebbe sostituito con "buffer di piccole dimensioni efrequentemente acceduto". Mi spiego meglio a proposito. Nei calcolatori la cache èfondamentale: è una memoria di piccola capacità ma molto veloce, che viene affiancata allamemoria principale ed è fondamentale per garantire le prestazioni dei moderni calcolatori.Aumentare la latenza dell’ASIO, richiede buffer più grandi ma questo non necessariamenteaiuta, a meno di avere salti durante la riproduzione: abbiamo il classico problema informaticodei lettori-scrittori attraverso un paio di buffer condivisi all’interno del driver ASIO; mentre unbuffer è scritto, l’altro viene letto e poi il ruolo si scambia. Più la latenza è piccola, più è piccolo ilbuffer aumentando la località spaziale e temporale: cioè il buffer viene acceduto piùfrequentemente e in posizioni attigue, per cui il sistema lo tiene nella cache veloce invece chenella memoria principale, più capiente ma più lenta. Inoltre, nei sistemi multi-core, è piùprobabile che un core venga adibito a questo scopo, invece di essere condiviso tra i variprocessi in esecuzione. La trasmissione è quindi più fluida e meno sincopata..

---

A. i diversi calcolatori e OS gestiscono IN PROPRIO la reale configurazione della memoria, spesso sovrapponendosi ai buffer dichiarati applicativamente (dai drivers) e come programmatore applicativo ci puoi fare poco, se non intervenendo sulle direttive di compilazione SPECIFICHE per ogni processore e configurazione hw/sw, cosa del tutto impraticabile e sbagliata concettualmente se distribuisci un eseguibile (il driver).

B. il 'jitter' provocato da quanto descrivi si genera sul flusso dati gestito da ASIO, quindi, nel caso di USB tra CLIENT e Interfaccia (XMOS per intenderci) del DAC, nel caso di Ravenna, tra PC e la 'embedded unit' del network player, cioè un secondo PC con la sua NIC passando per tutta l'infrastruttura di rete.

In entrambi i casi si tratta di flussi ASINCRONI, 'ricostruiti' da un FIFO a valle dell'interfaccia ed a monte del collegamento SINCRONO i2S verso il DAC. A detta dei più questo dovrebbe annullare completamente l'effetto del jitter anche per USB, a mio avviso non è certo, comunque non si tratta di una influenza diretta, ma indiretta, al pari - almeno - ad altre di diversa natura.

Però qui stiamo parlando di Ravenna, ove il driver (ed i relativi buffer) sono a monte di un collegamento TCP/IP, cioè asincrono ed a pacchetti, su una infrastruttura complessa a piacere che introduce buffers e latenze per disegno, anzi, Ravenna 'aggiunge' un meccanismo di 'ricostruzione' del tempo a valle di tutto. Ritengo improbabile che vengano mantenute le differenze casuali originate alla dimensione del buffer, sarebbe come chiedersi quanto era grande la cache L1 dell'hard disk del server da cui ho fatto il download originario, ma fosse così, negherebbe - invece di rafforzare - l'utilità di Ravenna.

Il grande vantaggio di TCP/IP è quello di svincolarci da quanto succede sul server, esattamente "come se" trasferissimo un file e quindi lo suonassimo, non fosse così, pensa come dovrebbe suonare male lo streaming remoto, invece...

C: Ovviamente, a valle di Ravenna rimane comunque la necessità di colloquiare con il DAC e qui rientrano certamente in gioco tutti i parametri di buffer e latenza, che però NON dipendono dal come i dati sono stati portati lì...

Per questi ed altri motivi io auspico l'avvento di un'interfaccia 'IP/I2S' diretta, eliminando USB dall'equazione, Ravenna o meno non importa (qualcosa esiste già anche con AVB), l'importante è che sia pensata e realizzata per uso Audio, senza tutti i problemi e limiti dei vari SOB disponibili oggi.

Probabilmente il tono risulta meno distaccato di quanto avrei voluto, ma sono argomenti in merito ai quali discuto da anni e mentre all'inizio registravo una assoluta avversione all'uso di players di rete, oggi si rischia di passare all'estremo opposto, per mere questioni di marketing, che permettono di vendere una tecnologia 'matura' in un nuovo segmento realizzando profitti unitari altissimi.


Gli svizzeri lo fanno da sempre.