HQplayer, un audio player per Linux, macOS e Windows

[marino 29]

Boh?!?!? Meno di 2 anni....Mi seccherebbe spendere 250€ w trovarmi con un software obsoleto come è successo con la 3, a proposito, quanto costa il 4 da già cliente e con tutte le agevolazioni del caso che puoi offrire??!?!

[bibo01]

15 minuti fa, marino 29 ha scritto:

Mi seccherebbe spendere 250€ w trovarmi con un software obsoleto come è successo con la 3, a proposito, quanto costa il 4 da già cliente e con tutte le agevolazioni del caso che puoi offrire??!?!

La v3 è perfettamente funzionante.

Come ho scritto in precedenza, con me risparmi sull'IVA. Se sei già cliente della v3, hai un coupon per un totale di 156 (credo).

[marino 29]

Si si, la v3 (presa con la tua mediazione) è attualmente in uso con gran soddisfazione!!!

Poter usufruire de tuo supporto per l'acquisto poi è un grande plus del quale ti ringrazio pubblicamente!!!

[newton]

La 3 va benissimo...suona ancora e sempre meglio di roon

e grazie a @bibo01

[bibo01]

12 minuti fa, newton ha scritto:

La 3 va benissimo...suona ancora e sempre meglio di roon

Questo è certo!

Però, devo ammettere che nella v4 c'è stata un'evoluzione nei filtri disponibili...che è ancora in atto - vedi ad es. i modulatori ASDM5ECv2 e ASDM7ECv2 di prossima uscita.

[stefano_mbp]

Il 22/9/2021 at 00:47, bibo01 ha scritto:

minimserver, gapless...stanno affrontando la questione

… ho chiesto di eventuali aggiornamenti sulla questione …

la risposta di Simon/Minimserver è eloquente:

”The primary cause of the problem is that HQPlayer Embedded does not implement the UPnP protocol for gapless playback.”

e contraddice quanto asserito da Jussi … vedremo come finisce

[bibo01]

1 ora fa, stefano_mbp ha scritto:

la risposta di Simon/Minimserver è eloquente:

che mi sembra però una baggianata perché sicuramente contraddice l'esperienza pratica. Che poi ci siano condizioni particolari - ad es. con MinimServer - in cui non funziona, questa è un'altra faccenda, dato che il protocollo UpnP non è standard.

[stefano_mbp]

7 minuti fa, bibo01 ha scritto:

una baggianata perché sicuramente contraddice l'esperienza pratica

Direi proprio di no …. Si sta parlando di upnp gapless non di gapless in generale

[bibo01]

@stefano_mbp Esattamente.

[bibo01]

Il 23/5/2021 at 18:53, bibo01 ha scritto:

@Saffuria Muso sotto Windows per Desktop, ma non so se può fare streaming.

@Saffuria Con Muso e LMS ora c'è la possibilità di usare Qobuz con HQP Desktop.
https://audiophilestyle.com/forums/topic/64002-article-streaming-local-content-through-hqplayer-a-nice-alternative-with-the-sonictransporter/?do=findComment&comment=1160560 

[stefano_mbp]

Il 11/10/2021 at 13:24, bibo01 ha scritto:

dato che il protocollo UpnP non è standard

La risposta di Simon … come mi aspettavo …

.

”In my test environment (RPi3 for server and RPi4 for renderer, 16/44 FLAC files, no transcoding), the great majority of the delay between tracks that causes these gaps is within HQPlayer (specifically, within the Rygel UPnP stack that HQPlayer uses to enable it to act as a UPnP renderer). Because HQPlayer doesn't use the UPnP gapless protocol, any significant delay during track changing breaks gapless playback.

If HQPlayer is running on a faster machine, renderer track-changing delay will be reduced and any server delay will come into play. Increased resolution and/or server-side transcoding will increase server delay.

The only way to make this work correctly in all cases is for HQPlayer to implement the UPnP gapless protocol. This enables the renderer to start streaming the next track before the current track has finished playing.”

.

Ho postato questa risposta in coda all’articolo di Chris … vediamo che succede …

[bibo01]

26 minuti fa, stefano_mbp ha scritto:

Ho postato questa risposta in coda all’articolo di Chris … vediamo che succede …

Gia...vediamo le reazioni 

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