HQ Player

[stefano_mbp]

.... as usual ... 

 

... it is Java's fault or it is Minimserver's fault or it is Euphony's fault. Asset, who knows? maybe Rygel? but who chose Rygel?

...  come on!

52 minutes ago, Miska said:

Gapless not working with UPnP is not an "issue", it is just something that sometimes does and sometimes doesn't work on UPnP. It is optional extra with UPnP anyway.

...  This is truly the joke of the century!

[ted_b]

49 minutes ago, stefano_mbp said:

...  This is truly the joke of the century!

Stefano_mbp...either grow up or please leave.  Your comments border on childish.  Jussi has spent hundreds of posts trying to troubleshoot.  Not sure why; your appreciation level is zero. 

[stefano_mbp]

.... so do you share the concept of the randomness of upnp's gapless operation?

[The Computer Audiophile]

3 minutes ago, stefano_mbp said:

.... so do you share the concept of the randomness of upnp's gapless operation?

 

Hi Stefano, let's take a step back and cool off a bit. This way we can all hopefully get somewhere. 

 

I'm sure you're aware that Jussi is one of the leading experts in the world with respect to computer based audio. You may not know, that he's one of the nicest and most honest people in this entire industry. This doesn't mean that we must always except his answers as facts, but proving he is incorrect on this type of stuff will take some serious research. Jussi eats, sleeps, and breathes this stuff. 

 

I understand your frustration, I really do, but I don't believe aiming it at Jussi will get anyone anywhere. 

 

UPnP is the most non-standard standard. It's a soup sandwich. I've had some really strange issues with UPnP over the years, especially when it comes to using hardware endpoints. Outputting from something like a River UPnP server to a JRiver UPnP renderer works best, but still isn't foolproof. 

 

There are also many things at play when using network based audio. It's just a fact of life. 

[stefano_mbp]

Dear Chris .... All my best ....

[luisma]

20 hours ago, Miska said:

I actually now have two separate locations, 15 km apart, both with >100 Mbps fiber internet, now I need to set up VPN to be able to access also between the locations.

That's easy to do especially if you have static IPs, with dynamic can also be done, and I know you are aware of all that, is it the same provider so you'll stay on-network?

 

Would be interesting to see multicast routed over it, I think there is a way for a layer 2 VPN, never done it myself but will look into it.

 

[stefano_mbp]

2 hours ago, The Computer Audiophile said:

UPnP is the most non-standard standard. It's a soup sandwich. I've had some really strange issues with UPnP over the years, especially when it comes to using hardware endpoints. Outputting from something like a River UPnP server to a JRiver UPnP renderer works best, but still isn't foolproof. 

Well ... you are talking about UPNP in general, and I know that some issues can occur, for example if you have to go through too many hops, and a single switch is one hop.

But the issue I was discussing is GAPLESS, and once upnp works as expected gapless must work too, it cannot be considered as an optional, extra, maybe, ultra gadget.

The audio industry (for streamers of course) is mostly based on upnp and gapless functionality, and the lacking of gapless is everywhere considered a big minus.

Think about Lumïn and Auralic just to mention two .... they do rely on upnp and gapless and their value/appeal should be less then 0 if upnp and gapless weren’t reliable.

[Holzohr]

13 hours ago, stefano_mbp said:

Think about Lumïn and Auralic just to mention two .... they do rely on upnp and gapless and their value/appeal should be less then 0 if upnp and gapless weren’t reliable.

 

Lumin and Auralic use OpenHome when I remember right. I had an Aries Femto many years ago and added BubbleUPnP to my Minimserver at that time.

[stefano_mbp]

OpenHome is UPNP with Linn extension .... gapless is standard in upnp ... check SetNextAVTransport ...

[Holzohr]

34 minutes ago, stefano_mbp said:

OpenHome is UPNP with Linn extension .... gapless is standard in upnp ... check SetNextAVTransport ...

 

All I wanted to say was that Auralic and Lumin use OpenHome instead of just UPnP. You may check this and ask them why.

[Solstice380]

20 hours ago, stefano_mbp said:

Dear Chris .... All my best ....

 Stefano, do you write code?

[stefano_mbp]

Yessss!

[Solstice380]

3 minutes ago, stefano_mbp said:

Yessss!

Excellent.  Professionally? For what type of applications?

[Miska]

23 hours ago, luisma said:

That's easy to do especially if you have static IPs, with dynamic can also be done, and I know you are aware of all that, is it the same provider so you'll stay on-network?

 

No, two different ISPs. But it shouldn't be an issue...

 

23 hours ago, luisma said:

Would be interesting to see multicast routed over it, I think there is a way for a layer 2 VPN, never done it myself but will look into it.

 

At least OpenVPN supports TAP adapters to deal with Ethernet packet level traffic. Multicast should work over such... Have to see.

 

[Miska]

8 hours ago, stefano_mbp said:

OpenHome is UPNP with Linn extension .... gapless is standard in upnp ... check SetNextAVTransport ...

 

SetNextAVTransport is optional extra feature in UPnP AV specifications. For example most hardware streamers don't support it. And at other times it is just flaky.

 

If HQPlayer UPnP feature doesn't work for you the way you want, just don't use HQPlayer but use something else instead where everything works the way you want.

 

But in your case the problem seems to be that it takes way more than 500 ms for your server to provide 10 seconds worth of audio for HQPlayer when HQPlayer requests it. Even more than 1 second. Since you seem to be doing transcoding, does the server pre-transcode the data, or does it begin transcoding only after getting first GET request for the URI? If it's dumb, it will begin transcoding only once the initial request comes in and transcode the entire file before any audio leaves the server. This would explain your problems for example.

 

Quote

But the issue I was discussing is GAPLESS, and once upnp works as expected gapless must work too, it cannot be considered as an optional, extra, maybe, ultra gadget.

 

Wrong.

 

Quote

The audio industry (for streamers of course) is mostly based on upnp and gapless functionality

 

Wrong again, most of the time it doesn't work.

 

[Miska]

9 hours ago, stefano_mbp said:

OpenHome is UPNP with Linn extension .... gapless is standard in upnp ... check SetNextAVTransport ...

 

With OpenHome, SetNextAVTransport is not used or needed, because the Renderer is holding the entire playlist instead of having just one URI.

 

If you want, you can implement OpenHome (or UPnP Renderer in general), over HQPlayer Control API. Since you are doing coding anyway, you have all the freedom to make UPnP things work the way you like with HQPlayer!

 

But on the other hand, for better performance it is better to skip UPnP altogether and stick to HQPlayer Control API instead.

[stefano_mbp]

32 minutes ago, Miska said:

But in your case the problem seems to be that it takes way more than 500 ms for your server to provide 10 seconds worth of audio for HQPlayer when HQPlayer requests it. Even more than 1 second. Since you seem to be doing transcoding, does the server pre-transcode the data, or does it begin transcoding only after getting first GET request for the URI? If it's dumb, it will begin transcoding only once the initial request comes in and transcode the entire file before any audio leaves the server. This would explain your problems for example

.... the issue occurs :

• with and WITHOUT transcoding (then transcoding is a false problem) ...
• using Minimserver and Asset (then Java is a false problem)
• using several control points OpenHome (Lumïn, Kazoo, Linn) and not OpenHome based (MConnect) ...

... but it seems obvious where the issue is ... “extra optional upnp feature” missing

 

[Miska]

5 minutes ago, stefano_mbp said:

.... the issue occurs :

• with and WITHOUT transcoding (then transcoding is a false problem) ...
• using Minimserver and Asset (then Java is a false problem)
• using several control points OpenHome (Lumïn, Kazoo, Linn) and not OpenHome based (MConnect) ...

... but it seems obvious where the issue is ... “extra optional upnp feature” missing

 

 

No, the issue seems to be that your server or network is too slow providing HQPlayer the data when asked. As long as this is the case, no matter what kind of UPnP stuff there is or is not. If HQPlayer runs out of currently playing audio before the next one is available, you will have a gap.

 

P.S. HQPlayer doesn't support OpenHome, so none of the OpenHome stuff matters.

 

[stefano_mbp]

1 minute ago, Miska said:

your server or network is too slow

Never had this kind of issue with other sw using upnp renderer ... 

[Miska]

1 minute ago, stefano_mbp said:

Never had this kind of issue with other sw using upnp renderer ... 

 

OK, just use the other upnp renderer sw then...

[Account Closed]

1 hour ago, Miska said:

 

OK, just use the other upnp renderer sw then...

Thanks Jussi. I think it is time to give this one a rest!

[BCRich]

Gapless playback is working for me in Euphony now thanks to Jussi and Željko.

[Iceaero]

I have a question about convolution and the clipping (i.e., 'limited') indicator. 

 

I've using REW and RePhase to generate impulses that are essentially only gain reductions to flatten the response between 30-200Hz and then phase adjustments above 200Hz.

 

Oddly, I've got to run HQPlayer's gain at -10dB in order to avoid hitting the limiter.  This surprises me because I have essentially no boosts and the headroom indicator was 0dB.  So, why am I hitting the limiter?  Could the phase adjustments trip that?

[Account Closed]

47 minutes ago, Iceaero said:

I have a question about convolution and the clipping (i.e., 'limited') indicator. 

 

I've using REW and RePhase to generate impulses that are essentially only gain reductions to flatten the response between 30-200Hz and then phase adjustments above 200Hz.

 

Oddly, I've got to run HQPlayer's gain at -10dB in order to avoid hitting the limiter.  This surprises me because I have essentially no boosts and the headroom indicator was 0dB.  So, why am I hitting the limiter?  Could the phase adjustments trip that?

Any DSP outside of the HQP engine has been reported to cause this behavior.

[SwissBear]

On 3/7/2021 at 10:09 PM, Iceaero said:

I have a question about convolution and the clipping (i.e., 'limited') indicator. 

 

I've using REW and RePhase to generate impulses that are essentially only gain reductions to flatten the response between 30-200Hz and then phase adjustments above 200Hz.

 

Oddly, I've got to run HQPlayer's gain at -10dB in order to avoid hitting the limiter.  This surprises me because I have essentially no boosts and the headroom indicator was 0dB.  So, why am I hitting the limiter?  Could the phase adjustments trip that?

 

You might want to check, when generating your convolution impulses inside rePhase, the gain which is displayed in the message box just under the button "Generate". The gain should be close to zero or below.