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:
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.Originariamente inviato da robertopisa
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:
Originariamente inviato da robertopisa
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.