HQPlayer comandato da LMS, come lo vedete?

[bibo01]

In effetti questo è proprio quello che non mi è chiarissimo:

Leggendo qui: Signalyst

da una parte c'è hqp-controll, che è un'applicazione di interfaccia a riga di comando, che mostra come inviare delle richieste/comandi al 'motore' di HQP, dall'altra ci sono le API mediante le quali dovrebbe essere possibile trasformare HQP in un renderer UPNP/DLNA.

Che rapporto c'è tra le due cose?
E' possibile usare hqp-controll per 'far recepire' uno stream in ingresso ad HQP invece di passargli solo l'indirizzo di un file?
E' possibile con le API?

C'è un a implementazione di esempio?

Magari riesci a passare queste domande allo sviluppatore, poi nel caso se è disponibile ed interessato, i mettiamo in contatto diretto.

Grazie.

Ti faccio sapere...non avere fretta

[bibo01]

Buone notizie.
Miska/Jussi, lo sviluppatore di HQPlayer, ha risposto eloquentemente e ho girato il tutto a Marco.
Spero che la cosa vada avanti.

In bocca al lupo!

[marcoc1712]

Buone notizie.
Miska/Jussi, lo sviluppatore di HQPlayer, ha risposto eloquentemente e ho girato il tutto a Marco.
Spero che la cosa vada avanti.

In bocca al lupo!

Ho visto la risposta, la devo "digerire" poi parto con le domande.

Grazie

[marcoc1712]

Ho proprio adesso inviato le mie prime considerazioni e relative richieste a Jussi, sperando che riesca a capire qualcosa nel mio già di suo terribile inglese, stamane reso impossibile dall'assurdo balletto dei tasti sulla tastiera...

Aspettiamo le risposte.

[bibo01]

Ho proprio adesso inviato le mie prime considerazioni e relative richieste a Jussi, sperando che riesca a capire qualcosa nel mio già di suo terribile inglese, stamane reso impossibile dall'assurdo balletto dei tasti sulla tastiera...

Aspettiamo le risposte.

Credo che sia improbabile che HQPlayer possa funzionare come DSP soltanto inserito tra LMS e Squeezelite-R2. Dubito anche che Jussi lo voglia.
Invece, mi sembra molto piu' probabile che HQPlayer si incarichi del playback con eventuale convoluzione\multicanale e collegamento a NAA.

[UnixMan]

Credo che sia improbabile che HQPlayer possa funzionare come DSP soltanto inserito tra LMS e Squeezelite-R2. Dubito anche che Jussi lo voglia.

a meno che la tua considerazione non derivi da informazioni diverse da quelle postate in questa sede (e se non ho capito male io), non era questo che aveva in mente Marco.

Sempre se non ho capito male, l'idea - almeno quella formulata qui - è in sostanza proprio quella di "far vedere" HQP ad LMS come se fosse un player (come uno squeezebox o un sistema con squeezelite). Cioè quella di poter inviare ad HQP lo stream di dati audio "grezzi" (oltre ai vari comandi di play/stop, configurazioni, ecc). Dopo di che è HQP a mandare l'output al dispositivo fisico (direttamente o attraverso NAA), come al solito...

[marcoc1712]

a meno che la tua considerazione non derivi da informazioni diverse da quelle postate in questa sede (e se non ho capito male io), non era questo che aveva in mente Marco.

Sempre se non ho capito male, l'idea - almeno quella formulata qui - è in sostanza proprio quella di "far vedere" HQP ad LMS come se fosse un player (come uno squeezebox o un sistema con squeezelite). Cioè quella di poter inviare ad HQP lo stream di dati audio "grezzi" (oltre ai vari comandi di play/stop, configurazioni, ecc). Dopo di che è HQP a mandare l'output al dispositivo fisico (direttamente o attraverso NAA), come al solito...

Si, in realtà ti manca un pezzo, la prima mail di chiarimeno scambiata con Jussi, dove ho spiegato come, per quanto ne so, può funzionare l'integrazione.

Sostanzialmente ci sono 3 modi:

1. HQP è inserito nella pipe di conversione di lMS/C-3PO e rilascia il suo output in STDOUT, che viene prelevato ed inviato a squeezelite, come al solito. L'interfaccia utente sui parametri di HQP sarebbe costituita, alternativamente, dal file custom-config.conf o da C-3PO.

Questo è quello che Bibo intende come utilizzo come DS, ma non come player.

Poca spesa, massima resa.

2. HQP accetta lo stream in uscita da Squeezelite in input, alternativamente presentandosi come un driver di dispositivo o via STDIN con una pipe.

Questa era la mia idea inziale, ma mi pare sia escluso che HQP accetti lo stream da STDIN e di certo non si presenta come driver di dispositivo (come fa JPLAY, per intenderci).

3. Come dici tu, HQP non è visto da LMS, ma da una versione altamente modificata di squeezelite che 'traduce' i comandi di slimproto in quelli di HQCommander ed il feedback di HQCommaner (se c'è) in slimproto.

Questo è stato già fatto con CromeCast, Upnp/DLN, Airplay ed altro, non è banale e rispetto alle soluzioni precedeti ha i seguenti svantaggi:

a. richiedo uno sforzo molto maggiore di sviluppo (e manutenzione).
b. è da fare quasi integralmente in C, che non è il mio linguaggio preferito.
c. qualsiasi modifica a HQP COmmander (?) e/o slimproto (rarissime) comportano un intervento di manutenzione evolutiva.

Limitando al massimo l'integrazione (i settings di HQP sono accesibili solo su HQP, dato che si usa la versione Desktop) si perde il vantaggio dell'accesso web da remoto integrato in LMS, ma si semplifica certamente il tutto, eliminando la necessità (ammesso sia possibile) di doverli tenere allineati a seguito di cambiamento diretto in HQP.

Se HQP COmmander può fornire lo stato corrente dei settings, si può pensare di integrarli successivamente in un plugin dedicato ad HQP, simile a C-3PO, ma vorrei evitare di costruire l'interfaccia web di HQP...

Anche nel caso minimale, però, slimpoto ha bisogno di ricevere alcuni messaggi di stato dal client, in particolare in merito allo 'stato' del buffering traccia per traccia (stream out), così da poter preparare in anticipo la successiva e garantire il gapeless.

Nella prima ipotesi tutto questo 'bailame' sarebbe dominio esclusivo di LMS, qui dal middleware di interfaccia, la cui complessità (e qualità del risultato) è chiaramente funzione di quanto HQPCommander preveda gli opportuni feedback o meno.

Se ci sono (3a) si può ottenere un buon risultato, se non ci sono (3b) bisogna 'inventarli' nel middleware ed è difficilmente ottenibile un buon risultato.

Non avendone visto alcuno nell'esempio che mi è stato inviato ho chiesto documentazione completa delle API così da poter meglio valutare.

Ultimo, ma non ultimo, aspetto è quello del licensing. Per poter distribuire qualcosa (la libreria delle API?) tramite il meccaniso dei plugin di LMS è necesario che la licenza sia compatibile con GNU v. 2 o successive, altrimenti si cade nel problema di FFMPEG e LAME, che devono essere installati manualmente dall'utente.

In sostanza, ho anticipato che se i casi 1 o 2 sono praticabili, posso volentieri garantire il mio impegno ed ottenere un buon risultato con un minimo sforzo, paragonabile a quello di C-3PO e squeezelite-R2.

Altrimenti, 3a è fattibile - pur costituendo un impegno che un po mi spaventa - mentre 3b rischia di non valer la pena, o quantomeno andrebbe prima verificato e studiato attentamente.

Aspettiamo la risposta di Jussi, è inutile mettere il carro davanti ai buoi.

[bibo01]

a meno che la tua considerazione non derivi da informazioni diverse da quelle postate in questa sede (e se non ho capito male io), non era questo che aveva in mente Marco.

Sempre se non ho capito male, l'idea - almeno quella formulata qui - è in sostanza proprio quella di "far vedere" HQP ad LMS come se fosse un player (come uno squeezebox o un sistema con squeezelite). Cioè quella di poter inviare ad HQP lo stream di dati audio "grezzi" (oltre ai vari comandi di play/stop, configurazioni, ecc). Dopo di che è HQP a mandare l'output al dispositivo fisico (direttamente o attraverso NAA), come al solito...

Infatti, le mie considerazioni si riferivano a quello che ha poi spiegato Marco.
Non sapevo se rispondere a Marco qui o in privato assieme a Jussi...
Comunque, a mio avviso la configurazione auspicabile è tipo Roon+HQPlayer. HQPlayer riceve lo stream lato server (decodificato per PCM e grezzo per DSD) e fa il playback in locale o su NAA. Un client remoto è collegato al server per la gestione della libreria e i comandi di playback (tipo -x><, volume...) fanno capo a HQPlayer. Idealmente, si avrebbe anche una piccola interfaccia per cambiare i settaggi di HQPlayer. In questa maniera i due "versanti" sono indipendenti e nello sviluppo del server e di HQPlayer non si danno fastidio l'uno con l'altro.

[marcoc1712]

Infatti, le mie considerazioni si riferivano a quello che ha poi spiegato Marco.
Non sapevo se rispondere a Marco qui o in privato assieme a Jussi...
Comunque, a mio avviso la configurazione auspicabile è tipo Roon+HQPlayer. HQPlayer riceve lo stream lato server (decodificato per PCM e grezzo per DSD) e fa il playback in locale o su NAA. Un client remoto è collegato al server per la gestione della libreria e i comandi di playback (tipo -x><, volume...) fanno capo a HQPlayer. Idealmente, si avrebbe anche una piccola interfaccia per cambiare i settaggi di HQPlayer. In questa maniera i due "versanti" sono indipendenti e nello sviluppo del server e di HQPlayer non si danno fastidio l'uno con l'altro.

Funzionalmete è di certo così, in tutti i casi, per l'utilizzatore non cambia nulla (o quasi) a lavoro finito:

Naviga la libreria in LMS con un qualsiasi metodo disponibile, riempe la playlist e preme play, senza nessun altro intervento ed il sistema inizia a suonare per come configurato.

Il punto è 'meramente' tecnico: dipendentemente da come HQP è in grado i ricevere lo stream e rilasciarlo in uscita.

Se può/deve interfacciare solo un device audio in uscita, il metodo 1 non è praticabile, se riesce a ricevere uno stream da una pipe si può usare il metodo 2, se - invece - l'unico modo è fornire l'URI di un file o di uno stream, allora va implementato il middleware di interfaccia, previa verifica.

Capisco la perplessità di alimentare un player diverso nel metodo 1, ma nel 2 l'unica diversità è che invece di ricevere uno stream via socket http o file, lo riceve da STDIN, è sempre HQP a suonare, 'schiavo' di LMS, ma - a naso - mi risparmierei un bel po di lavoro...

Però sono solo idee, tutte da verificare nella pratica.

Con roon come funziona? è gapless? se si, come avvisa il server di prepararsi ad inviare la traccia successiva?

[bibo01]

...
Però sono solo idee, tutte da verificare nella pratica.

Certamente

Con roon come funziona? è gapless? se si, come avvisa il server di prepararsi ad inviare la traccia successiva?

Sia con Muso che Roon il playback è gapless.
Con Muso HQPlayer riceve l'intera playlist (la playlist window di HQPlayer si popola degli indirizzi dei files). Quindi, è HQPlayer a gestire il playback, per cui si possono ascoltare solo i formati supportati.
Con Roon, invece, HQPlayer riceve un singolo stream (decodificato nel caso di formati compressi), come si evince dalla playlist window di HQPlayer. Per cui la playlist e il gapless sono gestiti - suppongo - da Roon.

Per l'uscita, HQPlayer supporta i device driver visti dal sottosistema audio (Wasapi/Core Audio/Alsa oppure Asio) o dal backend network tramite il suo networkaudiodeamon.