C3PO Plugin verisone 0.1alfa

[marcoc1712]

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"?

Be, a volte me lo chiedo anch'io ...chi me lo ha fatto fare!

E' che è una cosa nata così, quasi una sfida dopo l'insucesso di questa primavera con i convert.conf, pensa che io non faccio nemmeno upsampling e continuerò a non farlo almeno finchè Giovanni non mi assemblerà il DAC!

L'idea del "player universale", comandato da LMS al quale puoi facilmente integrare MUSO o altre applicazioni per la gestione della libreria (ce ne fosse bisogno) e passando da una versione di squeezelite con esclusivo compito di passare lo stream (o il comando, se il file è locale) ad HQP mi frulla in testa da un po e sarei partito con quella se avessi trovato un minimo di collaborazione dall'altra parte.

So di certo che qualcuno sta lavorando ad uno "squeezeFat" che potra fare un mare di cose ma lato client, mentre io continuo a credere nel minimalismo,lato player.

In LMS il concetto di Processor non esiste se non come plugin (che poi nessuno ti impedisce di usare il plugin come 'metodo' per collegare un processore esterno, come di fatto fa C-3PO) ma, francamente, non avevo idea delle limitazioni che ho via via incontrato ed ho dovuto aggirare.

Quello che sarebbe da fare davvero è correggere la parte di LMS che gestisce le conversioni di formato, radicalmente. Non è una cosa assurda, basterebbe che:

a. invece di usare una open monodirezionale usasse un metodo IPC più standard (es. sockets TCP/IP, ma pubbliche).

b. invece di farsi le mille storie che si fa aprisse semplicemnete le porte e lasciasse fare ad un processore esterno, che potrebbe fare lo stesso di oggi, come default.

c. prevedesse di 'leggere' il formato in uscita dal transcoder prima di inviarlo al client.

Avessi un minimo di fiducia che venisse presa in considerazione, lavorerei ad una proposta in questo senso, ma temo verrebbe bollata come 'audiofollia' ed abbandonata...

[UnixMan]

In parte ti ho risposto, il problema è che non c'è modo di impedire che LMS e Squeezelite possano comunicare direttamente, quindi farlo funzionare è possibile, ma andrebbe usato con attenzione.

beh, ovvio: si tratta di dire ad LMS di usare (solo) "ManInTheMiddle" (e non Squeezelite) come "player"; se li si abilita entrambi prevedibilmente succede un gran pasticcio e non funziona nulla (mentre, se non ho capito male come funzionano le cose, le app di controllo continuerebbero a dover puntare sempre -e solo- al vero player, cioè a Squeezelite).

Per contro, sempre se ho capito bene, questo potrebbe dare la possibilità di "by-passare" (e quindi escludere completamente) il server intermedio banalmente selezionando come player su LMS Squeezelite anziché "ManInTheMiddle", cosa che potrebbe tornare comoda in qualche caso.

Comunque, come hai già capito da solo, bisognerebbe usare un 'fake' LMS ed un 'fake' Squeezelite, il punto è se ne vale la pena.

Certamente. Ovviamente si tratterebbe di un unico processo (sebbene magari diviso in più thread e/o sottoprocessi) che svolge entrambe le funzioni, per altro estremamente semplificate (non è lui che deve gestire le cose: si limita a "forwardare" i comandi, le info e gli stream che riceve avanti o indietro, al vero server o al vero player, a seconda dei casi).

Be, a volte me lo chiedo anch'io ...chi me lo ha fatto fare!

:-)

So di certo che qualcuno sta lavorando ad uno "squeezeFat" che potra fare un mare di cose ma lato client, mentre io continuo a credere nel minimalismo,lato player.

pienamente d'accordo...

Quello che sarebbe da fare davvero è correggere la parte di LMS che gestisce le conversioni di formato, radicalmente. [...]
Avessi un minimo di fiducia che venisse presa in considerazione, lavorerei ad una proposta in questo senso, ma temo verrebbe bollata come 'audiofollia' ed abbandonata...

magari basta suggerirla toccando i tasti giusti... "tecnofile" piuttosto che "audiofile".

Ad es. anziché parlare di "upsampling" parlare genericamente di DSP, DRC, equalizzatori, cross-over e filtri digitali vari, ecc.

[marcoc1712]

Stupenda, ma non trovo la versione Hires in Qobuz.

beh, ovvio: si tratta di dire ad LMS di usare (solo) "ManInTheMiddle" (e non Squeezelite) come "player"; se li si abilita entrambi prevedibilmente succede un gran pasticcio e non funziona nulla (mentre, se non ho capito male come funzionano le cose, le app di controllo continuerebbero a dover puntare sempre -e solo- al vero player, cioè a Squeezelite).

Per contro, sempre se ho capito bene, questo potrebbe dare la possibilità di "by-passare" (e quindi escludere completamente) il server intermedio banalmente selezionando come player su LMS Squeezelite anziché "ManInTheMiddle", cosa che potrebbe tornare comoda in qualche caso.

mmmh... non riesco ad immaginare come fare una cosa del genere, se selezioni il player finale lo vedi connesso al server intermedio, quindi non puoi inviargli i pezzi che vuoi, ma solo lasciarlo sincronizzato su uno stream esterno, come se fosse una radio, proveniente dal primo LMS e trasformato, è selezionando il primo Squeezelite (quello di man in the middle) connesso al primo LMS che riesci a navigare la libreria.

Forse mi sfugge qualcosa della tua ipotesi, ma è per questo che usando uno streamer ed un player 'avulsi' a LMS sempre connessi tra loro con legame biunivoco (stile HQP e NAD per capirci) si risolverebbe il problema: LMS (e le APP) vedrebbero un solo player che in realtà corrisponde allo SL collegato a man in the middle ed a quello che segue.

Ovvio che si perderebbero le capacità di sincronizzazione 'reali', cioè verrebbero mantenute ma in modo più o meno efficace in funzione della latenza propria del sistema Squeezelite | man in the middle -> proxy x | Player x.

magari basta suggerirla toccando i tasti giusti... "tecnofile" piuttosto che "audiofile".

Ad es. anziché parlare di "upsampling" parlare genericamente di DSP, DRC, equalizzatori, cross-over e filtri digitali vari, ecc.

Certo, può anche essere, ma prima dovrei farlo e testarlo, quindi sottoporlo a giudizio... Senza la certezza che venga nemmeno preso in considerazione, poi certamente qualcuno ne metterebbe in discussione la necessità ed opportunità, visto che chi realizza APP per il telefono non ha nessun interesse, anzi, a che vengano inserite funzionalità lato server che o dovrà controllare o conviverci... Quindi si oppone a qualsiasi innovazione, mentre dall'altra parte c'è chi pretende di prendere una versione per linux portarla su ARM e farla funzionare senza problemi, altrimenti sbraita che il tuo programma non funziona...

E' diventato un posto buio...

[bigtube]

..................................................mentre dall'altra parte c'è chi pretende di prendere una versione per linux portarla su ARM e farla funzionare senza problemi, altrimenti sbraita che il tuo programma non funziona...

E' diventato un posto buio...

Ma per caso il furbacchione si chiama soundcheck's......no perchè se è lui mi meraviglio di brutto

[UnixMan]

Stupenda, ma non trovo la versione Hires in Qobuz.

mmmh... non riesco ad immaginare come fare una cosa del genere, se selezioni il player finale lo vedi connesso al server intermedio, quindi non puoi inviargli i pezzi che vuoi,

perché no? il "server intermedio" deve essere "trasparente", non sarebbe che un "ripetitore" di LMS da una parte e di Squeezelite dall'altra: tutti i comandi che gli arrivano verrebbero ri-spediti ad LMS, e tutte le risposte di LMS tornerebbero indietro per la stessa via (e viceversa). Quindi tutti vedrebbero e potrebbero fare esattamente le stesse cose.

Anzi, ora che ci penso, c'è anche un modo banale per risolvere il problema della "visibilità indesiderata" del vero server da parte del player e dei controller e viceversa: basta isolarli su segmenti di rete diversi! (e non interconnessi).

Ad es., se i due girano sulla stessa macchina, il server LMS e "ManInTheMiddle" potrebbero parlarsi banalmente utilizzando l'interfaccia virtuale locale (e solo quella) mentre, in caso contrario, -se sono su macchine diverse- possono utilizzare un segmento di rete dedicato (anche "point-to-point") completamente isolato dal resto della LAN (ma non necessariamente da Internet, che anzi deve essere raggiungibile da LMS se si vogliono sfruttare i vari servizi on-line).

Ovviamente "ManInTheMiddle" deve anche essere connesso attraverso una o più altre interfaccia verso la/e LAN cui afferiscono il player ed il/i controller.

Forse mi sfugge qualcosa della tua ipotesi,

mi pare proprio di sì. Credo che tu tenda a pensare a "ManInTheMiddle" come una parte "nativa" dell'ecosistema, un sorta di insieme di “LMS+Squeezelite”... mentre nella mia visione non è niente del genere. È piuttosto un virus, un parassita (o meglio un simbionte) "alieno" che si intromette nell'organismo e lo sfrutta a proprio piacimento, ingannandolo e modificandolo. :-)

Fuor di metafora, sarebbe solo una sorta di "Proxy" trasparente che cambia (alcune) carte in tavola, modificando "al volo" alcuni dei dati in transito come necessario, senza che né il server (LMS) da un lato né il client (Squeezelite, ed i controller) dall'altro abbiano modo di accorgersi di ciò che sta avvenendo sotto al loro naso.

Per l'appunto come in un attacco "man in the middle": http://it.wikipedia.org/wiki/Attacco_man_in_the_middle

Tutta la gestione (normale) del protocollo, della comunicazione, ecc rimarrebbe comunque in carico al "vero server" (LMS) ed al "vero client" (Squeezelite).

[...] E' diventato un posto buio...

brutta cosa...

[marcoc1712]

perché no? il "server intermedio" deve essere "trasparente", non sarebbe che un "ripetitore" di LMS da una parte e di Squeezelite dall'altra: tutti i comandi che gli arrivano verrebbero ri-spediti ad LMS, e tutte le risposte di LMS tornerebbero indietro per la stessa via (e viceversa). Quindi tutti vedrebbero e potrebbero fare esattamente le stesse cose.

Anzi, ora che ci penso, c'è anche un modo banale per risolvere il problema della "visibilità indesiderata" del vero server da parte del player e dei controller e viceversa: basta isolarli su segmenti di rete diversi! (e non interconnessi).

Ad es., se i due girano sulla stessa macchina, il server LMS e "ManInTheMiddle" potrebbero parlarsi banalmente utilizzando l'interfaccia virtuale locale (e solo quella) mentre, in caso contrario, -se sono su macchine diverse- possono utilizzare un segmento di rete dedicato (anche "point-to-point") completamente isolato dal resto della LAN (ma non necessariamente da Internet, che anzi deve essere raggiungibile da LMS se si vogliono sfruttare i vari servizi on-line).

Ovviamente "ManInTheMiddle" deve anche essere connesso attraverso una o più altre interfaccia verso la/e LAN cui afferiscono il player ed il/i controller.

Capisco, ma non con componenti e servizi di 'LMS'!

mi pare proprio di sì. Credo che tu tenda a pensare a "ManInTheMiddle" come una parte "nativa" dell'ecosistema, un sorta di insieme di “LMS+Squeezelite”... mentre nella mia visione non è niente del genere. È piuttosto un virus, un parassita (o meglio un simbionte) "alieno" che si intromette nell'organismo e lo sfrutta a proprio piacimento, ingannandolo e modificandolo. :-)

Fuor di metafora, sarebbe solo una sorta di "Proxy" trasparente che cambia (alcune) carte in tavola, modificando "al volo" alcuni dei dati in transito come necessario, senza che né il server (LMS) da un lato né il client (Squeezelite, ed i controller) dall'altro abbiano modo di accorgersi di ciò che sta avvenendo sotto al loro naso.

Per l'appunto come in un attacco "man in the middle": http://it.wikipedia.org/wiki/Attacco_man_in_the_middle

Tutta la gestione (normale) del protocollo, della comunicazione, ecc rimarrebbe comunque in carico al "vero server" (LMS) ed al "vero client" (Squeezelite).

Esatto sarebbero 2 proxy con in mezzo il transcoder, che deve 'filtrare' e manomettere i messagi di slimproto (oltre a ricostruire lo stream).


La mia preoccupazione è che:

1. i due proxy 'sanno' come parlare con LMS e squeezelite, ovvio, quindi implementano SLIMPROTO, il primo (tra LMS e MITM) è sostanzialmente un renderer, quindi già implementato, solo da enucleare, il secondo è un server senza esserlo, è da studiare.

2. Nel transcoder c'è una componente 'dedicata' a mastruzzare slimproto, quindi spedicifa, il resto è semplice.

A prima vista non è una cosa da qualche ora e la domanda è sempre, ne vale la pena? Per la via non è meglio 'aprirsi' di più?

[UnixMan]

Capisco, ma non con componenti e servizi di 'LMS'!

magari mi sfugge sempre qualcosa, ma non vedo perché no. Ad LMS "MITM" apparirebbe come un qualsiasi player, mentre al resto dell'ecosistema apparirebbe come un qualsiasi server. Specie se si isola il "vero" LMS dal resto della rete, non vedo quali limitazioni o "effetti collaterali" possano esserci (beh, a parte forse il caso di sistemi complessi che coinvolgono più di un server LMS, che non ho idea come funzionino).

sarebbero 2 proxy con in mezzo il transcoder, che deve 'filtrare' e manomettere i messagi di slimproto (oltre a ricostruire lo stream).

esattamente.

1. i due proxy 'sanno' come parlare con LMS e squeezelite, ovvio, quindi implementano SLIMPROTO,

non necessariamente, quanto meno non completamente: MITM dovrebbe solo saper riconoscere quelle parti della comunicazione che devono causare una sua qualche azione/reazione. Tutto il resto può limitarsi a "ripeterlo" così come lo ha ricevuto, senza necessità di interpretarlo.

A prima vista non è una cosa da qualche ora e la domanda è sempre, ne vale la pena?

beh, questo è tutto un altro discorso. Arrivati a questo punto la discussione è puramente accademica: con C3PO già scritto e funzionante, a meno che non si manifestino problemi o necessità impreviste che non sia possibile risolvere con un plugin o che tu non voglia farlo per puro esercizio intellettuale... direi proprio di no.

Ad averci pensato prima invece sarebbe stato da valutare: quanto è più semplice (o più complesso?) seguire questo approccio rispetto alla via del plugin di LMS? Di sicuro rispetto al plugin avrebbe avuto il vantaggio di avere meno vincoli esterni, ed in particolare di dipendere esclusivamente da "SlimProto", cioè da qualcosa che difficilmente cambierà mai. Quindi ad es. sarebbe esente da possibili problemi di manutenzione a seguito di sviluppi futuri di LMS, nonché da qualsiasi possibile interazione indesiderata con altri plugin, configurazioni particolari, ecc.

Per la via non è meglio 'aprirsi' di più?

in che senso? cosa intendi con "aprirsi"?

[claudio67]

Ho installato LMS su pc Win con il plugin C3PO, come player uso un minipc con installato Daphile versione Squeezelite-R2.
Pur avendo impostato la funzione in C-3PO Transcoding Helper "ricampiona sempre" alla frequenza massima supportata, uscita waw, sul display del dac leggo 44.1 khz.
Cosa mi sfugge?