E' prima di tutto nel firmware dei lettori SB, che non è open source (e che comunque non mi metteri a modificare), in SlimProto (implementato sia in LMS che in tutti i lettori, compreso Squeezelite) e quindi 'sparso' un po' ovunque in LMS.
Tutto è fattibile, il punto è che difficilmente riuscirei a fare accettare modifiche ad un livello così profondo, dovrei tenerele in una mia versione, cosa che al momento non mi va.
L'alternativa è mettere qualcosa prima di LMS (o di qualsiasi altro server/player) che scarichi da Qobuz (o qualsiasi altra sorgente) e carichi un buffer (o un ram disk o anche un HD, come sky), da cui poi far leggere o direttamente LMS, un generico plugin o magari uscire in streaming.
Sarebbe perfetto, per esempio, per HQP, ma ci sono diversi problemi:
a. Bisogna realizzare e mantenere un modulo per ogni 'sorgente', che si vuole integrare, il che significa tempo ma anche avere le credenziali (API Keys).
b. Si devono gestire problematiche legate ai diritti d'autore: se scarichi su un file, anche se su RAMDISK, devi assicurarti di proteggero dalla copia e cancellarlo a scadenza, sono cose che tipicamente fanno le applicazioni proprietarie, per ovvi motivi.
Al di là di questo - ed è il motivo per cui sono molto scettico sul RAM DISK di Daphile - comunque i dati vengano 'letti' e passati a LMS, la 'famosa' pipeline che comprende il 'tokenized command' con il quale abbiamo litigato con C-3PO, fino ad arrivare al buffer di squeezelite (in e out + il 'piccolo' di alsa o corrispondenti in PA) è lunga e composta di tanti più o meno piccoli serbatoi (buffer), pompe (codice che legge da un buffer e scrive in un altro) e filtri (le varie applicazioni nel tokenized command).
Un qualsiasi collo di bottiglia in questa tubatura rende vana la maggiore capacità di portata a monte, per questo il 'bufferone' di squeezelite rimane l'unica vera misura di difesa.
Rispondi quotando