C3PO Plugin verisone 0.1alfa

[UnixMan]

“C3PO” è un droide autonomo, indipendente... non un "plugin" di un altro sistema...

"man in the middle", quella poteva essere la soluzione!

Prima che qualcuno chiami la neuro pensando che stia dando i numeri, provo a spiegarmi.

Il nostro problema: avere la possibilità di "processare" a piacimento (ad es. "upsamplare", filtrare, fare convoluzioni o quant'altro) gli stream audio a monte del "player" (o "renderer" che dir si voglia), con la possibilità di svolgere tali operazioni su una macchina diversa da quella dove gira squeezelite.

Come prima cosa abbiamo pensato e tentato di utilizzare direttamente LMS, sfruttandone le opzioni di configurazione... ma ci siamo scontrati con una serie di problemi insolubili. A quel punto Marco ha pensato bene di aggirare quei problemi creando un plugin per LMS.

Ma per il nostro problema originale ci sarebbe stata un'altra soluzione possibile, che probabilmente sarebbe più semplice, più comoda e versatile: anziché agire su LMS (e su squeezelite) avremmo potuto invece aggiungere un altro pezzo, autonomo ed indipendente, che si frappone tra LMS e squeezelite: una sorta di "man in the middle", per l'appunto.

In sostanza si sarebbe trattato di creare un software che si presenta verso LMS come un player e verso squeezelite come un server LMS.

Questo nuovo software riceverebbe i vari comandi, le info e lo stream "nativo" da LMS, lo elaborerebbe come vogliamo e poi ritrasmetterebbe il tutto (adeguatamente corretto) a squeezelite (e quanto ricevuto da questo indietro verso LMS, nel caso la comunicazione sia bidirezionale).

Tutto ciò senza dover modificare in alcun modo né aggiungere alcunché né a squeezelite né a LMS, quindi senza interferenze: nessun problema di compatibilità con altri elementi dell'ecosistema, né con configurazioni, plugin e servizi vari (ad es. "Qobuz"), ecc, che non si accorgerebbero neanche della presenza del nostro "man in the middle".

Inoltre si tratterebbe di un software completamente autonomo ed indipendente, quindi più facile da mantenere, non essendo legato agli sviluppi futuri degli altri software (a meno ovviamente di cambiamenti nel protocollo di comunicazione tra il server LMS ed i "player", cosa però a dir poco improbabile in quanto renderebbe le nuove versioni incompatibili con i sistemi preesistenti).

Come se non bastasse ci sarebbe l'ulteriore vantaggio di avere la possibilità (se si vuole) di separare tale nuovo "server intermedio" tanto dalla macchina su cui gira squeezelite quanto da quella dove gira LMS, cosa che potrebbe tornare comoda ad es. per sfruttare i server LMS che girano su alcuni NAS, ecc.


...perché non ci ho pensato prima?

[DacPassion]

Non è l'approccio di Daphile alla questione?

[UnixMan]

Non è l'approccio di Daphile alla questione?

se non ho capito male no, non fa niente del genere: si limita ad utilizzare un software "smart" che viene utilizzato da LMS per le conversioni di formato. E l'eventuale upsampling lo fa fare a squeezelite.

[marcoc1712]

“C3PO” è un droide autonomo, indipendente... non un "plugin" di un altro sistema...

"man in the middle", quella poteva essere la soluzione!

Prima che qualcuno chiami la neuro pensando che stia dando i numeri, provo a spiegarmi.

Il nostro problema: avere la possibilità di "processare" a piacimento (ad es. "upsamplare", filtrare, fare convoluzioni o quant'altro) gli stream audio a monte del "player" (o "renderer" che dir si voglia), con la possibilità di svolgere tali operazioni su una macchina diversa da quella dove gira squeezelite.

Come prima cosa abbiamo pensato e tentato di utilizzare direttamente LMS, sfruttandone le opzioni di configurazione... ma ci siamo scontrati con una serie di problemi insolubili. A quel punto Marco ha pensato bene di aggirare quei problemi creando un plugin per LMS.

Ma per il nostro problema originale ci sarebbe stata un'altra soluzione possibile, che probabilmente sarebbe più semplice, più comoda e versatile: anziché agire su LMS (e su squeezelite) avremmo potuto invece aggiungere un altro pezzo, autonomo ed indipendente, che si frappone tra LMS e squeezelite: una sorta di "man in the middle", per l'appunto.

In sostanza si sarebbe trattato di creare un software che si presenta verso LMS come un player e verso squeezelite come un server LMS.

Questo nuovo software riceverebbe i vari comandi, le info e lo stream "nativo" da LMS, lo elaborerebbe come vogliamo e poi ritrasmetterebbe il tutto (adeguatamente corretto) a squeezelite (e quanto ricevuto da questo indietro verso LMS, nel caso la comunicazione sia bidirezionale).

Tutto ciò senza dover modificare in alcun modo né aggiungere alcunché né a squeezelite né a LMS, quindi senza interferenze: nessun problema di compatibilità con altri elementi dell'ecosistema, né con configurazioni, plugin e servizi vari (ad es. "Qobuz"), ecc, che non si accorgerebbero neanche della presenza del nostro "man in the middle".

Inoltre si tratterebbe di un software completamente autonomo ed indipendente, quindi più facile da mantenere, non essendo legato agli sviluppi futuri degli altri software (a meno ovviamente di cambiamenti nel protocollo di comunicazione tra il server LMS ed i "player", cosa però a dir poco improbabile in quanto renderebbe le nuove versioni incompatibili con i sistemi preesistenti).

Come se non bastasse ci sarebbe l'ulteriore vantaggio di avere la possibilità (se si vuole) di separare tale nuovo "server intermedio" tanto dalla macchina su cui gira squeezelite quanto da quella dove gira LMS, cosa che potrebbe tornare comoda ad es. per sfruttare i server LMS che girano su alcuni NAS, ecc.


...perché non ci ho pensato prima?

Io ci ho pensato, francamente, ma ho abbandonato l'idea e ti spiego perchè.

Per prima cosa, chiariamo che non è il modo di Daphile, Daphile ha costruito un 'canale di collegamento' tra server e player integrativo (e per certi versi alternativo) a quello stadard (SlimProto) che funziona su Gento e - secondo me - bene sulla stessa macchina, con alcune limitazioni su 2 macchine temo non funzioni con più client e/o più servers, ma potrei sbagliare.

Diciamo che è un ottimo adattamento per uno scopo preciso: un Player standalone, ma fargli fare di più è a mio avviso una forzatura.

Quello che fa C-3PO in 200K di software (che diventano 10Mb in win solo perchè non esiste una DLL eseguibile del perl...) Daphile lo fa in uno script di 200 righe, ma solo in un ambiente configurato esattamente come gli serve, dove il player 'clona' le sue informazioni in un filesystem virtuale condiviso con lo script, senza tutti i giri e le complessità che la portabilità su sistemi diversi impone.

Ribadisco che è un ottima soluzione, ma mirata ad un prodotto chiuso, dove il SO è parte integrante della soluzione. la residua capacità di dialogare con l'ecosistema SB è quasi casuale, non cercata ed infatti, temo, non sempre scontata.


Quello che succede oggi con C-3PO è questo:

[URL=https://up.nexthardware.com/index.php?img=11065&n=MIM1.JPG][/URL


dove a è il formato in ingresso e b quello in uscita.

Paolo, se ho capito bene, ipotizza questo:



mentre 'la via lms' sarebbe piuttosto questa.

[DacPassion]

La tua terza ipotesi che vantaggi avrebbe rispetto alla situazione attuale?

[marcoc1712]

Le diverse soluzioni hanno punti di forza e di debolezza e mi spiego:

Volendo usare componenti 'squeezebox', non si prescinde da SLIMPROTO quindi nella tua ipotesi, Paolo, dovresti implementare in man in the middle un client visto da LMS ed un server visto dal player (Squeezelite).

la prima parte è semplice: LMS -> Squeezelite | ManInTheMiddle, usando LMS e squeezelite (anche standard) per trasmettere lo stram in formato originario, quindi senza nessun problema o necessità di C-3PO o altro.

la seconda parte sarebbe: ManInTheMiddle -> LMS -> Squeezelite

Lasciando per un attimo da parte come far comunicare ManInTheMiddle ed LMS, ancora una volta la comunicazione tra LMS e Squeezelite potrebbe essere asolutamente standard e priva di necessità particolari, dato che lo stream in uscita avrebbe lo stesso identico formato di quello in ingresso.

Ma come far comunicare ManInTheMiddle con LMS?

a. mediante un file di transito (brutto).
b. mediante uno stream URL (probabilmente la via migliore).
c. mediante plugin ed alimentazione da STDIN (semplice PIPE, come Qobuz) problematico in Windows ed incompatibile con i cue sheets.

Dato che sarebbe sempre LMS a tenere la comunicazione con i players, non c'è nemmeno bisogno di averne 2 diversi, riconducendoci al terzo schema.

Ma c'è un però: I player, anche quello intermedio che alimenta Man In The Middle, verrebbero visti e sarebbero comandabili da qualsiasi controller in rete, non c'è modo (che io conosca) di nasconderli e renderli schiavi. Al di la di questo funzionerebbe ed è esattamente quello che avevo in mnte di fare con HQP o qualsiasi altro player: alimentarlo mediante squeezelite come se fosse un qualsiasi SB.

[marcoc1712]

La tua terza ipotesi che vantaggi avrebbe rispetto alla situazione attuale?

Stavo scrivendo, quindi probabilmente ti ho già risposto.

[UnixMan]

Paolo, se ho capito bene, ipotizza questo:

esatto.

Io ci ho pensato, francamente, ...

ottimo.

... ma ho abbandonato l'idea

Premesso che lo chiedo solo per curiosità, va benissimo così come hai deciso di farlo, non ho capito perché la hai scartata: che vantaggi hai a legarti ad LMS piuttosto che agire "a valle"?

[UnixMan]

Volendo usare componenti 'squeezebox', non si prescinde da SLIMPROTO quindi nella tua ipotesi, Paolo, dovresti implementare in man in the middle un client visto da LMS ed un server visto dal player (Squeezelite).

esatto. Ovviamente sarebbero un client ed un server "fake", in quanto si limiterebbero a fare da tramite (apportando solo i cambiamenti necessari in un verso e nell'altro).

la prima parte è semplice: LMS -> Squeezelite | ManInTheMiddle, usando LMS e squeezelite (anche standard) per trasmettere lo stram in formato originario, quindi senza nessun problema o necessità di C-3PO o altro.

la seconda parte sarebbe: ManInTheMiddle -> LMS -> Squeezelite

mmmh, c'è qualcosa che non mi torna, mi pare diverso da quello che avevo in mente. La mia idea era di fare in modo che LMS abbia a che fare (solo) con "ManInTheMiddle", da lui visto come un player qualsiasi, ed a sua volta che Squeezelite veda solo ManInTheMiddle, pensando che sia quello il suo server LMS. In altre parole, la comunicazione sarebbe:

LMS<-(SlimProto)->ManInTheMiddle<-(SlimProto)->Squeezelite, senza alcuna comunicazione diretta tra LMS e Squeezelite o viceversa.

Probabilmente mi sfugge qualcosa dato che non conosco i dettagli del sistema e del relativo protocollo. Ad es., una delle cose cui non ho pensato è: i client (controller, o come si chiamano... insomma le app sul telefono) con chi comunicano? con LMS o direttamente con il/i player?

[marcoc1712]

Il punto di forza di una soluzione dove lo streamer integrato in Man in the middle NON parli con LMS ma direttamente con Squeezelite (come mi per proponga tu Paolo) risolverebbe il problema della visibilità e, programmandolo opportunamente, anche quello della necessità del 'doppio comando'.

Mi spiego:

Nel caso di usare LMS nei due segmenti di comunicazione (non importa se 1 solo o 2 diversi) si dovrebbe 'comandare' una tantum il play di Man in the middle (visto come servizio di rete) verso il player (squeezelite), quindi si comanderebbe solo il play dei diversi files e servizi verso man in the middle.

Usando uno streamer dedicato (pur basato su LMS ma modificato) ed un player altrettanto modificato, si potrebbe fare in modo che non si presentino ad altri e si connettano direttamente allo startup direttamente in play, con un meccanismo di mute se non arriva nessun segnale reale.

Il mio dubbio è che ne valga la pena rispetto ad usare per questo scopo una coppia server/player completamente avulsa da LMS, visto che:

a. avrebbe un compito molto semplice da svolgere
b. potrebbe essere usata per connettere altri player non SB (es. meccanismo play to UPNP o simili).