HQplayer, un audio player per Linux, macOS e Windows

[bibo01]

@stefano_mbp Ho pensato un po' alla questione gapless... Dato che Embedded supporta UPnP attraverso Rygel (non so se ne eri al corrente), che è essenziale per questa comunicazione. In molti casi quest'accoppiata funziona - verificato. Evidentemente, nel caso di MinimServer, la parte gapless non funziona.

Però, mi chiedo quanto Rygel influisca sull'implementazione del gapless.

[bibo01]

@stefano_mbp Se il gapless è determinato dall'interazione tra control point, server, e renderer, forse il problema che ha in alcuni casi Embedded come renderer è costituito dalle informazioni che riceve dall'UPnP stack di Rygel, che evidentemente non sono corrette a sufficenza per avere il gapless correttamente, e quindi dalla comunicazione Rygel-server-controller.

Mi sembra che qui Embedded sia un player renderer "stupido", che agisce sulla base delle informazioni ricevute, che mette poco di suo se non abilitare un buffer appropriato. Di solito, cerca anzi di favorire il gapless - ad es. con il plugin per LMS.  

[stefano_mbp]

@bibo01 sapevo di Rygel e Simon attribuisce proprio allo upnp stack di Rygel il mancato funzionamento del gapless.

Ragionando un po’ più a fondo mi sono reso conto (credo) che siamo di fronte a due modalità di comunicazione upnp:

• la modalità push, usata per esempio da Audirvana, in cui il gapless funziona. In questo caso Audirvana ha il controllo e provvede ad inviare a HQPe gli stream nei tempi adeguati e il gapless funziona.
• la modalità pull, usata quando entra in gioco un control point e Minimserver. In questo caso il control point invia al renderer, quindi HQPe, l’intera playlist di riproduzione e a questo punto il suo lavoro è terminato, infatti se chiudi (swipe off) il control point la riproduzione continua (a parte il caso particolare di MConnect e Bubbleupnp). In questo caso il renderer deve provvedere a richiedere al server (Minimserver) le varie tracce della playlist precedentemente ricevute dal control point, e qui il meccanismo gapless non funziona poiché HQPe/Rygel agiscono in ritardo

Credo di poter dire che LMS (a intuito) funziona come Audirvana e per questo motivo il gapless funziona.

[stefano_mbp]

@bibo01 … e temo di capire il motivo per cui Jussi è così “reticente” su questo tema: Rygel non è una sua “creatura” e qualsiasi modifica potrebbe avere un impatto su tutto il parco installato di Rygel … la vedo dura.

[bibo01]

52 minuti fa, stefano_mbp ha scritto:

Ragionando un po’ più a fondo mi sono reso conto (credo) che siamo di fronte a due modalità di comunicazione upnp:

• la modalità push, usata per esempio da Audirvana, in cui il gapless funziona. In questo caso Audirvana ha il controllo e provvede ad inviare a HQPe gli stream nei tempi adeguati e il gapless funziona.
• la modalità pull, usata quando entra in gioco un control point e Minimserver. In questo caso il control point invia al renderer, quindi HQPe, l’intera playlist di riproduzione e a questo punto il suo lavoro è terminato, infatti se chiudi (swipe off) il control point la riproduzione continua (a parte il caso particolare di MConnect e Bubbleupnp). In questo caso il renderer deve provvedere a richiedere al server (Minimserver) le varie tracce della playlist precedentemente ricevute dal control point, e qui il meccanismo gapless non funziona poiché HQPe/Rygel agiscono in ritardo

Se questo è ciò che avviene, e a mio avviso dovrebbe essere sempre in modalità push, mi viene spontaneo dire quanto fragile sia il protocollo UPnP. Ovviamente qui c'è qualcuno che non fa il lavoro giusto: il server deve provvedere a mandare il segnale e il controller deve fare...il controller, cioè controllare che a valle il renderer sia pronto a ricevere il segnale e avvertire il server a riguardo.

43 minuti fa, stefano_mbp ha scritto:

… e temo di capire il motivo per cui Jussi è così “reticente” su questo tema: Rygel non è una sua “creatura” e qualsiasi modifica potrebbe avere un impatto su tutto il parco installato di Rygel … la vedo dura.

Se Rygel fosse la causa primaria, un punto di snodo che in alcune condizioni s'inceppa nel suo lavoro di media server, capisco anche che Jussi possa soltanto proporre delle soluzioni al gruppo principale di sviluppo (Zeeshan Ali, Jens Georg, Thijs Vermeir, James Henstridge e Jussi Kukkonen) nel GNOME git repository.  

[stefano_mbp]

7 minuti fa, bibo01 ha scritto:

e a mio avviso dovrebbe essere sempre in modalità push

Non può esserlo … altrimenti non potresti chiudere la app control point …

Se provi con Lumïn, Kazoo o Linn te ne potrai rendere conto.

[stefano_mbp]

@bibo01  il motivo per cui MConnect e Bubbleupnp si comportano in maniera diversa da tutte le altre app control point credo sia per il fatto che puoi configurarle per gestire il gapless da app o da renderer, quindi devono rimanere attive 

… questo è MConnect …

… ma comunque non funziona se imposti il gapless gestito da app

[bibo01]

@stefano_mbp Forse potresti suggerire a Simon/MinimServer se può supportare HQPlayer (tipo Roon) a prescindere da UPnP, in maniera tale che anche Desktop verrebbe supportato. In pratica, si tratterebbe di usare HQPlayer control API. C'è un'implementazione di riferimento e una hqp-control2 utility. Non credo sia affatto complicato 

[stefano_mbp]

@bibo01 mi pare una soluzione che stravolgerebbe la logica di Minimserver.

Da quel che posso capire Roon è il server, gestisce la libreria e soprattutto la riproduzione dei brani (come fanno anche Audirvana e JRiver).

Utilizzando le API di HQPlayer Roon invia (quindi è la parte attiva) i brani a HQPlayer, alla stessa maniera di Audirvana e JRiver se a valle ci sono dei renderer UPNP, la differenza è che Roon non usa UPNP.

Ma Roon è e rimane la parte attiva di questa catena.

Nel caso di Minimserver invece la situazione è differente:

• Minimserver analizza la libreria e compila un file xml nel quale ogni brano è correlato ai propri tag e al proprio URL
• il control point scelto (sia esso Lumïn, Linn, Kazoo, MConnect, Bubbleupnp poco importa) richiede a Minimserver il file xml in modo che sia possibile selezionare una playlist di riproduzione
• questa playlist viene poi inviata al renderer e a questo punto il compito del control point si esaurisce,
• è infatti il renderer che “prende le redini del gioco” e si preoccupa di richiedere a Minimserver i brani da eseguire.

In tutto questo Minimserver è passivo, al contrario di Roon che invece abbiamo visto essere attivo.

In altre parole Roon opera in modalità “push” nei confronti di HQPlayer mentre il renderer UPNP opera in modalità “pull” nei confronti di Minimserver.

Pertanto la richiesta di poter utilizzare le API di HQPlayer in Minimserver significherebbe stravolgere la logica di Minimserver che dovrebbe diventare parte attiva (quindi assumere la modalità “push”).

 

 

[bibo01]

22 minuti fa, stefano_mbp ha scritto:

Pertanto la richiesta di poter utilizzare le API di HQPlayer in Minimserver significherebbe stravolgere la logica di Minimserver che dovrebbe diventare parte attiva (quindi assumere la modalità “push”).

...non vedo il problema visto che quello è lo scopo di un server, e sopratutto bisogna uscire dalla logica UPnP. Più che altro bisognerebbe avere un client per MinimServer perchè non so se un controller UPnP andrebbe bene.

Non ricordo perché non uso MinimServer da parecchio, MinimServer può fare un semplice playback di un file? Se fosse possibile, basterebbe un banalissimo link a HQPlayer per il playback come ha fatto Muso.

[stefano_mbp]

3 minuti fa, bibo01 ha scritto:

MinimServer può fare un semplice playback di un file?

Assolutamente no, Mimimserver non ha un player proprio.

È proprio qui il problema, Minimserver è totalmente passivo.

Come dicevo sopra, dopo aver compilato il file xml Minimserver aspetta che il renderer vada a prendersi i file utilizzando le informazioni che il control point gli ha inviato

[stefano_mbp]

@bibo01 per intenderci …

questo è l’indirizzo del file che Minimserver ha trasmesso via xml al control point.

Il renderer riceve dal control point l’indirizzo e lo usa per andarsi a prendere in Minimserver il file

 

[stefano_mbp]

19 minuti fa, bibo01 ha scritto:

..non vedo il problema visto che quello è lo scopo di un server, e sopratutto bisogna uscire dalla logica UPnP

Ma i server upnp si comportano tutti così (Minimserver, Asset, Twonky ecc.), se così non fosse non sarebbero server UPNP.…

e poi perché mai bisognerebbe uscire dalla logica upnp? 
Funziona benissimo ovunque tranne che con HQPe … 

altrimenti sarebbe come dire che quel tizio con i baffetti a cui non piaceva certa gente ebbe una buona idea nel cercare di sterminarli (un po’ forte ma rende l’idea …)

Se HQPe non funziona bisogna cambiare HQPe e non cambiare tutto il resto, non ti pare?

[bibo01]

49 minuti fa, stefano_mbp ha scritto:

Se HQPe non funziona bisogna cambiare HQPe e non cambiare tutto il resto, non ti pare?

Certamente.

Quello che dicevo era di uscire dalla logica UPnP ed eventualmente aggiungere una feature a MinimServer. Forse utilizzare l'API di HQPlayer è semplice...credo che HQPlayer debba solo ricevere l'indirizzo del file (più o meno quello che hai postato).

[stefano_mbp]

7 minuti fa, bibo01 ha scritto:

aggiungere una feature a MinimServer

… che in altre parole significherebbe far lavorare Minimserver come Audirvana/JRiver usando le API HQP invece di UPNP … non sarebbe più un server UPNP …

ma allora usiamo Audirvana o JRiver che già funzionano (non ho provato JRiver che però ho letto avere qualche problema, infatti c’è uno sviluppatore che ha realizzato, solo per Windows, un accrocchio per farlo funzionare con HQPe) … se ci piace … inoltre Audirvana già trasforma in wav qualsiasi altro formato prima di inviarlo al renderer.

Ma Audirvana ha un db che è un disastro, è estremamente fragile, fa spesso una gran confusione con i metadati, è un “mattone” spaventoso e poi è piuttosto limitato nella disponibilità di metadati, inoltre ha un problema con il formato Alac per cui non legge i metadati multi item (li simula solamente) … questi sono i motivi per cui l’ho abbandonato.

Insomma, cadrebbe tutta l’impalcatura UPNP, il control point diventerebbe un telecomando del player (vedi Audirvana Remote) alla stregua della app di Roon.

Ma poi … perché diamine si dovrebbe stravolgere tutto quando basterebbe un po’ di buona volontà e buon senso per mettere una “toppa” a Rygel.

UPNP è per me eccellente, pensa che da qualche mese ho installato Daphile, ho attivato il plugin per accedere alle librerie remote e quindi vedo Minimserver, ho attivato C-3PO e ho due endpoint RoPieee/Squeezelite in rete.

Daphile/C-3PO fa upsampling a DSD512 rispettando senza problemi il gapless prendendo i file da Minimserver che li ha trasformati “on the fly” in wav, e posso quindi sfruttare le caratteristiche di navigazione per metadati in cui Minimserver è per me imbattibile … quindi le condizioni sono analoghe a quelle in cui ho provato HQPe che fa cilecca col gapless.

Insomma, Daphile (gratuito) con i plugin C-3PO e Remote Music Libraries (gratuiti) lavorano meglio di HQPe che costa una mezza fortuna (per essere un sw), e il tutto gira su un Nuc10i3 al contrario di HQPe che ha bisogno di potenze elaborative enormi e quindi impone costi elevati per l’hardware.

 

[stefano_mbp]

@bibo01 avrai visto le risposte su AS …

dopo un po’ di bla bla su OpenHome e DLNA la risposta al commento di Simon è 

“Rygel does support SetNextTransportURI.

 

HQPlayer doesn't implement any UPnP stuff at all. Only Rygel's renderer-interface.

 

But the way HQPlayer works, if the control point and media server are quick enough, you get gapless playback even without SetNextTransportURI, because there's enough buffer.”

.

che io traduco:

Rygel supporta SetNextTransportURI

HQPlayer non implementa nessuna roba UPNP. Solamente l’interfaccia renderer di Rygel

Ma per come lavora HQPlayer, se il control point e il media server sono abbastanza veloci, hai il gapless anche senza SetNextTransportURI poiché c’è sufficiente buffer

.

Quindi io capisco che :

• Rygel sarebbe ok
• ma HQPlayer non lo usa
• perché se il control point (che c’entra come i cavoli a merenda perché posso anche “killarlo”) e il media server sono abbastanza veloci (quanto veloci? È un prenderci come il tiro al piattello) il buffer basta

… insomma, ogni altra discussione sull’argomento è solo tempo sprecato … soprattutto dopo le affermazioni:

• ”ma HQPlayer non usa roba UPNP”
• ”se sono abbastanza veloci …”

 

 

[bibo01]

E' uscito HQPlayer 4 Embedded 4.26.0 !

Add new ASDM5ECv2 and ASDM7ECv2 modulator variants. Add support for PCM gain compensation. Add support for RIAA EQ plugin. Improved web interface. Support TYER/TORY ID3v2.3 tags. Control API improvements. Sound quality improvements. Streaming improvements. Bug fixes. HQPlayer OS now ships with HQPWV control interface. CUDA is now supported also on Fedora 34 build.

[bibo01]

A domanda lo sviluppatore di HQPlayer risponde -

"Puoi fornire qualche informazione sui nuovi modulatori ASDM5ECv2/7ECv2 e cosa possiamo aspettarci da loro, dal punto di vista sonoro, rispetto agli attuali modulatori ASDM5EC/7EC?"

Oggettivamente, secondo me, è solo una piccola messa a punto, con un leggero maggiore impiego della CPU. Ma soggettivamente c'è forse un po' (anche) più chiarezza e dettaglio. Ma sono felice di sentire cosa ne pensa la gente.