BubbleUPnP > HQPlayer OS repeats the beginning of tracks

[ohshitgorillas]

6 minutes ago, Miska said:

 

It has six physical cores. See here:

https://ark.intel.com/content/www/us/en/ark/products/199315/intel-core-i5-10600kf-processor-12m-cache-up-to-4-80-ghz.html

 

I have one generation newer i5-11600, but it is lower TDP 65W CPU. IIRC, it is cooled with Noctua NH-U9S cooler. And it can do DSD512...

 

Yours is K-series 95W TDP CPU and it should really be able to do DSD512 with EC-light modulators without any trouble. So if it cannot, I would look into why. Enough cooling? Fast enough RAM? BIOS settings OK?

 

Baseline settings:

1x = poly-sinc-gauss-long

Nx = poly-sinc-gauss-hires-lp

Modulator = ASDM7EC-light

 

 

No, upsampling PCM to 4x (176.4/192k) can work on pretty much any CPU, even RPi4.

 

 

It can do DSD512 with EC-super with most filters except really demanding ones. I also use a Noctua NH-U9S cooler with two fans.

 

Regarding CUDA, is there any downside to leaving CUDA enabled and letting the GPU do part of the processing for PCM at 4x?

 

Also, could you please add Year to the HQPlayer Client, on the left-hand side of Play view, along with Artist/Album/Song?

[ohshitgorillas]

I am still getting drop-outs from Qobuz, streaming from HQPlayer Client to a NAA. These are rare and usually occur a few seconds before the end of a track, but have occurred in the middle of the track. This is the NAA behind a smart managed switch (TP Link TL-SG105E), which has no settings related to 802.3x flow control. The QoS setting is currently DSCP/802.1P Based. The device is a USBridge Sig running RoPieee, since the NAA OS won't run on the USBridge Sig on its own.

 

A few other suggestions or ideas, I apologize if this is out of line or not possible:

• HQPlayer Client could auto-connect to the hqplayer instance on the network. Unless one has multiple instances of HQP on the network, which seems unlikely, or unless I'm missing something, which is far more likely, this feature basically always does the same thing and therefore is a prime candidate for automation. When resetting HQP, e.g. to change settings, Client could just wait and reconnect automatically.
• It would be great to see some kind of library auto-update function, as most media servers these days do this. The fact that HQPDcontrol doesn't automatically sync its library with HQPlayer had me confused for like two weeks as to why some of my music wasn't showing up.

[ohshitgorillas]

On 1/12/2024 at 3:19 PM, Miska said:

 

According to it's manual yes it has, and according to the same manual it defaults to off. So first thing is to enable it for all ports. And you can also verify from the web interface that it actually becomes active on all involved ports (since it is negotiated at hardware level).

 

 

 

Got it, yeah, I overlooked that since I was looking for 802.3** rather than the words Flow Control.

 

I'm actually still getting drop outs near the end of songs even with Flow Control enabled on the switch. Usually, the drop-out occurs when HQPlayer Client appears to switch to the next track, which is slightly premature since the HQPlayer Client tracker is slightly ahead of the actual music. When it moves to the next track, there is a chance of the music dropping out.

 

Freewheel and prefetch are disabled.

 

There is another device in the path that may be affecting things. It's a GL iNet AX1800 wifi router (OpenWRT), although it's acting as a switch and wifi access point only rather than as a router. It sits about halfway between the router and the smart switch and connects both since I don't have a cable long enough to reach the switch directly from the router. I'll check its settings for anything like Flow Control or IGMP snooping.

[ohshitgorillas]

11 minutes ago, Miska said:

 

802.3x is related to Ethernet standard, but not to WiFi which is a separate standard. So the type of flow control over WiFi is different. Of course WiFi can add some extra delay and unpredictability to the picture depending on conditions.

 

 

Sorry, this is a Wifi AP, but none of my music streamers use wifi at all, they are all wired directly into the network. So the fact that this does wifi is irrelevant.

 

I'm having a hard time navigating the OpenWRT settings, do you have any advice for how to set this up properly? That is, enabling IGMP snooping and flow control on OpenWRT?

 

11 minutes ago, Miska said:

 

There is always a load spike when HQPlayer starts loading the next track. If the machine is on the edge of keeping up with the processing demands, this is the place where you usually flip it over and then you have a drop-out as result.

 

 

I am using the sinc-M filter with NS9 dithering upsampling PCM to 4x. The PC should be far, far from the edge of keeping up with processing demands.

[ohshitgorillas]

27 minutes ago, Miska said:

 

Have you tried if using for example poly-sinc-ext3 (variant of the same filter as sinc-M) makes any difference? It can be actually heavier, but it has lower delay.

 

 

No, that still skips near the end of the track.

[ohshitgorillas]

Is there a way to add an album to the queue in HQPlayer while another album is still playing? Or do I have to use HQPDcontrol for that?

[ohshitgorillas]

I'm still having this issue where the music drops out around the end of the song... let me review so you don't have to go back thru the thread:

 

• I am running HQPlayer daemonized on a dedicated headless media server (specs below)
  • I am using PCM so I shouldn't have any problems running into the system's limits
• When streaming from Qobuz via HQPlayer Client, the seek bar is slightly ahead of the actual music. When the seek bar arrives at the end of the song (prematurely) and moves to the next track, the music drops out for a second.
  • This is unique to using Qobuz and HQPlayer Client, as it does not happen when streaming from my local library using HQPlayer Client, and it does not happen when using mConnect (but mConnect has other problems like sometimes forgetting to advance to the next song).
  • This does not happen with every song, in fact most songs play fine
• I have two NAA endpoints, one plugged directly into the router and the other behind a smart switch. Both devices have this problem.
• I have tried setting HQPLAYER_BUFFER_TIME=2500 and =5000 in /etc/default/hqplayer but the problem has persisted.

[ohshitgorillas]

1 hour ago, Miska said:

 

Prefetch and freewheel enabled? (default)

 

What kind of internet connection? I've tested on my three internet connections (no issues). 500 Mbps fiber, 400 Mbps fiber and 1 Gbps 5G.

 

 

Prefetch and freewheel are both disabled.

 

Internet connection is 1.2 Gbps cable.

[ohshitgorillas]

On 1/24/2024 at 2:40 PM, Miska said:

 

It would help trying the possible combinations and see if it makes a difference.

 

But seems like the network access of next track causes the audio playback to drop-out. Either the network interface driver disables interrupts for too long time (typical for some WiFi and BT drivers). Or otherwise the audio output thread is not getting scheduled properly at that moment, despite the fact that it is set to high priority by HQPlayer.

 

 

Enabling both prefetch and freewheel seems to have resolved the issue! I haven't gotten a drop-out in days, just perfect gapless playback.