HQPlayer comandato da LMS, come lo vedete?

[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.

[marcoc1712]

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.

Muso, probabilmente, gli invia una serie di comandi per aggiungere file alla playlist, che viene eseguita da HQPlayer, come farebbe con LMS, infatti muso non è un server ma solo un front end.

Immagino che i comandi di next, previous, pause e stop vengano rediretti da muso a HQP sempre via HQPlay commander.

Muso ottiene feedback dello stato del playback? (traccia corrente, in pausa, avanzamento,...)?

Tutte le funzionalità di LMS così verrebbero meno, si userebbe meramente la web gui come front end, per la via è di certo meglio muso, non credo ci sia un beneficio reale con LMS (si perderebbe anche l'accesso ai servizi di rete quali Qobuz, Spotify o Tidal) e comunque non riuscirei a inviare files decodificati.

Con Roon, se capisco bene, HQP sottoscrive uno stream 'generico' attivo per tutto il tempo della riproduzione, come se fosse una web radio, per intenderci.

In questo caso è - in pratica - come intendevo usare la pipe: HQP è 'schiavo' del server, non gestisce la playlist, ma rimane in attesa su uno stream aperto e lo riproduce per come gli arriva, con la difficoltà di dover generare uno stream HTTP che HQP possa sottoscrivere.

Purtroppo LMS non funziona così, ma ragiona per traccia, quindi bisogna usare un middleware che può essere basato su squeezelite, come avevo già previsto, si aggiunge la difficoltà di dover pubblicare uno stream HTTP.

Non ho idea di come si possa fare, ma forse trovo qualche esempio o magari un piccolo 'streamer' cha possa essere alimentato via STDIN da squeezelite.

Che feedbacks riceve ROON da HQP? SE HQP va in pausa, lo stream riprende dal punto di interruzione o no?

Punto di attenzione:

Uno stream ha un formato unico, possiamo decidere parametricamente quale, ma è uno solo.

Fino a che si tratta pcm non è un problema, qualsiasi sia il formato in ingresso con C-3PO si porta ad un solo formato in uscita (es. wav 44100Hz, 16 bit). Ovviamente sarà l'utente a selezionare il formato di uscita più idoneo per lui e dovrà essere avvisato che non è una grande idea operare due conversioni di formato in serie, ma tant'è. La maggior parte delle persone avrà files wav o flac o aiff 44100/16 e magari qualcosa in HD, come flac 96/24, uscendo PCM 96/24 si risolve.

Ma se voglio trattare anche files 'nativi' DSD? Li converto in PCM e quindi HQP li riconverte in DSD?


L'alternativa è 'rompere' la playlist ad ogni cambio di formato, che non mi pare sia un problema.

Cosa succede con ROON?

p.s.

Visto che credo che adesso sia più chiaro, dovrei chiedere a Jussi se invece di uno stream HTTP può accettare l'input da STDIN. Se lo ha già previsto (non cambia nulla in realtà) mi risparmierebbe un mare di lavoro.

Devo rispiegare tutto a lui o magari sei già allineato tu con lui e quindi 'fai prima' visto anche il mio inglese?

[bibo01]

...
Muso ottiene feedback dello stato del playback? (traccia corrente, in pausa, avanzamento,...)?

Sì.

Con Roon, se capisco bene, HQP sottoscrive uno stream 'generico' attivo per tutto il tempo della riproduzione, come se fosse una web radio, per intenderci.

In questo caso è - in pratica - come intendevo usare la pipe: HQP è 'schiavo' del server, non gestisce la playlist, ma rimane in attesa su uno stream aperto e lo riproduce per come gli arriva, con la difficoltà di dover generare uno stream HTTP che HQP possa sottoscrivere.

Infatti, HQPlayer ha un pulsante per attivare il "network control".

Purtroppo LMS non funziona così, ma ragiona per traccia, quindi bisogna usare un middleware che può essere basato su squeezelite, come avevo già previsto, si aggiunge la difficoltà di dover pubblicare uno stream HTTP.

Non ho idea di come si possa fare, ma forse trovo qualche esempio o magari un piccolo 'streamer' cha possa essere alimentato via STDIN da squeezelite.

Che feedbacks riceve ROON da HQP? SE HQP va in pausa, lo stream riprende dal punto di interruzione o no?

A livello di programmazione, non lo so. A livello visivo, c'è l'avanzamento del brano e l'output selezionato.
Se HQP va in pausa, il timer di Roon avanza di circa 10 secondi (il buffer) e lo stream riprende da quel punto, non da quello di interruzione.

Punto di attenzione:

Uno stream ha un formato unico, possiamo decidere parametricamente quale, ma è uno solo.

Fino a che si tratta pcm non è un problema, qualsiasi sia il formato in ingresso con C-3PO si porta ad un solo formato in uscita (es. wav 44100Hz, 16 bit). Ovviamente sarà l'utente a selezionare il formato di uscita più idoneo per lui e dovrà essere avvisato che non è una grande idea operare due conversioni di formato in serie, ma tant'è. La maggior parte delle persone avrà files wav o flac o aiff 44100/16 e magari qualcosa in HD, come flac 96/24, uscendo PCM 96/24 si risolve.

Ma se voglio trattare anche files 'nativi' DSD? Li converto in PCM e quindi HQP li riconverte in DSD?


L'alternativa è 'rompere' la playlist ad ogni cambio di formato, che non mi pare sia un problema.

Cosa succede con ROON?

Roon non effettua dsp, effettua decodifica di formati compressi tipo MP3 e FLAC (in questa maniera HQP può riprodurre anche formati che non supporta normalmente) e per il DSD lo manda grezzo/nativo.

p.s.

Visto che credo che adesso sia più chiaro, dovrei chiedere a Jussi se invece di uno stream HTTP può accettare l'input da STDIN. Se lo ha già previsto (non cambia nulla in realtà) mi risparmierebbe un mare di lavoro.

Devo rispiegare tutto a lui o magari sei già allineato tu con lui e quindi 'fai prima' visto anche il mio inglese?

Qui stiamo facendo soltanto un po' di brainstorming.
Secondo me, conviene che tu continui con Jussi direttamente, sperando che continuate a mettermi in copia conoscenza. Non ti preoccupare per l'inglese - non sarà perfetto, ma è OK.
Aspettiamo la sua replica.

[marcoc1712]

Sì.


Infatti, HQPlayer ha un pulsante per attivare il "network control".


A livello di programmazione, non lo so. A livello visivo, c'è l'avanzamento del brano e l'output selezionato.
Se HQP va in pausa, il timer di Roon avanza di circa 10 secondi (il buffer) e lo stream riprende da quel punto, non da quello di interruzione.


Roon non effettua dsp, effettua decodifica di formati compressi tipo MP3 e FLAC (in questa maniera HQP può riprodurre anche formati che non supporta normalmente) e per il DSD lo manda grezzo/nativo.


Qui stiamo facendo soltanto un po' di brainstorming.
Secondo me, conviene che tu continui con Jussi direttamente, sperando che continuate a mettermi in copia conoscenza. Non ti preoccupare per l'inglese - non sarà perfetto, ma è OK.
Aspettiamo la sua replica.

OK, Jussi ha risposto.

Come pensavo, anche con ROON lo stream è unico e si interrompe necessariamente quando cambia il formato, non è possibile utilizzare la pipe, ma si deve necessariamente creare uno stream http 'raw' con delle header specifiche di HQP.

L'esempio che mi ha fornito può essere utilizzato come base per produrre lo stream, non sembra particolarmente difficile, da verificare che la libreira sia disponibile in C per squeezelite e rimane da realizzare tutta la componene di acquisizione dei diversi stream da LMS/Squeezelite per convogliarli in uno unico, devo pensarci, ma non mi pare banale.

[bibo01]

OK, Jussi ha risposto.

Come pensavo, anche con ROON lo stream è unico e si interrompe necessariamente quando cambia il formato, non è possibile utilizzare la pipe, ma si deve necessariamente creare uno stream http 'raw' con delle header specifiche di HQP.

L'esempio che mi ha fornito può essere utilizzato come base per produrre lo stream, non sembra particolarmente difficile, da verificare che la libreira sia disponibile in C per squeezelite e rimane da realizzare tutta la componene di acquisizione dei diversi stream da LMS/Squeezelite per convogliarli in uno unico, devo pensarci, ma non mi pare banale.

...ma tu ami le sfide