HQ Player

[stefano_mbp]

19 minutes ago, Miska said:

This confirms the lag that MinimServer has when requested for higher bandwidth tracks

I think you have misunderstood: Minimserver delivers to hqplayerd always and only 16/44.1, they are just transcoded to wave without changing bit depth nor sample rate, the issue occurs when I configure hqplayerd to upsample those 14/44.1 beyond 24/176.400

[giordy60]

Hi Stefano 

I never asked myself the problem ....

because transcode wav all the flac files (I suppose) before sending them to HQP?

thanks 

[bibo01]

9 minutes ago, giordy60 said:

Hi Stefano 

I never asked myself the problem ....

because transcode wav all the flac files (I suppose) before sending them to HQP?

thanks 

Stefano has files in ALAC format and HQP does not read them, so he lets MinimServer transcode them to WAV.

However, that it's not the problem. The problem is that MinimServer does not fulfill HQP's requirements in time to make gapless playback as upsampling rate increases (beyond PCM4x).

[Miska]

1 hour ago, stefano_mbp said:

I think you have misunderstood: Minimserver delivers to hqplayerd always and only 16/44.1, they are just transcoded to wave without changing bit depth nor sample rate, the issue occurs when I configure hqplayerd to upsample those 14/44.1 beyond 24/176.400

 

Is Minimserver on the same machine? Or are you sending output to a NAA?

 

[giordy60]

1 hour ago, bibo01 said:

Stefano has files in ALAC format and HQP does not read them, so he lets MinimServer transcode them to WAV.

.

Ah OK !

did not know 👌

[mfalcon]

@Miska I know you may have said before but what UPBoard do you have?  Has it been a good experience?

[SwissBear]

3 hours ago, Miska said:

I don't have any of such devices. Why would phase noise of ethernet matter in this context? There are no audio clocks being transmitted over the network when using NAA.

 

Using NAA is not so much different than playing something from Tidal or Qobuz servers, where the traffic passes through number of networking devices on the way from some data center to the player application. Using a VPN would allow you to have HQPlayer and NAA located in different countries and have the traffic passing internet. And it would still likely work fine given enough internet bandwidth.

 

Thanks for your explanations. 

Part of me, which received scientific training, and tries to understand physical phenomenon underlying my auditive perceptions, is grateful for these explanations which make perfect sense.

Another part of me, which is subject to cognitive biases, has difficulties to explain why I have the auditive perceptions that the sound produced by my system feels better, with deeper bass, a better tri-dimensional image, aso, when using a device like the sMS-200 Ultra which reclocks an asynchronous music flow.

I was expecting your answer, but wanted to make sure and felt more comfortable asking.

Thanks again.

[stefano_mbp]

1 hour ago, Miska said:

 

Is Minimserver on the same machine? Or are you sending output to a NAA?

 

Minimserver runs on different machine, a MacBook Pro i7/16GB ram late 2011 and music files are on thunderbolt attached hdd.

I’m sending output to NAA, rpi4 4GB running Ropieee XL

[Miska]

3 hours ago, mfalcon said:

@Miska I know you may have said before but what UPBoard do you have?  Has it been a good experience?

 

This one:

https://up-shop.org/up-gateway-atom-x5-z8350-w-4g-memory-32g-emmc-board-w-vesa-plate.html

 

I have two of these, working as NAAs. It also works for USB input side through the USB3 micro-B OTG connector, when set to device mode from BIOS settings.

 

And yes, it is pretty nice small fanless device. (the company making these is part of ASUS)

 

[Miska]

3 hours ago, SwissBear said:

Another part of me, which is subject to cognitive biases, has difficulties to explain why I have the auditive perceptions that the sound produced by my system feels better, with deeper bass, a better tri-dimensional image, aso, when using a device like the sMS-200 Ultra which reclocks an asynchronous music flow.

 

I would say it is because of less noisy USB output, rather than reclocking or such. But it is not reclocking or dealing with network side in any special way (AFAIK). Point of NAA is to sit between network and DAC while having large asynchronous RAM FIFO buffer.

 

We need to recognize that the USB clock is not related to audio clock, it is there just to facilitate the USB packet based data transfer operation. Similar way as CPU or network device clocks. Everything is "timeless" until it reaches the DAC's conversion clock.

 

We recognize that the USB side is potentially sensitive, while the network side is not (at least when used with correct type of cables - U/UTP).

 

[Miska]

2 hours ago, stefano_mbp said:

Minimserver runs on different machine, a MacBook Pro i7/16GB ram late 2011 and music files are on thunderbolt attached hdd.

I’m sending output to NAA, rpi4 4GB running Ropieee XL

 

Have you tried same case without a NAA?

 

[Luca72c]

Friends, i had a (maybe stupid) idea to test if Apple new ARM architecture chips are really capable to spread modulators load across multiple cores. I don't know for sure if it is feasible or not, but i try to throw the ball in the playground...

Is there a way to force HQPlayer to play a mono music file and thus converting a single channel to DSD256 EC?

If this can be done, some M1 users can try that (maybe even converting to DSD512 EC, if more load is needed) and see if 4 cores or just 2 are equally loaded. Some hint would be needed to distinguish between modulators and filters loads, maybe Jussi could help about that...

If 4 cores are equally loaded, then probably Silicon ARM architecture (and its management firmware/software) are capable of spreading modulator load across multiple cores and that would be very good news for HQPlayer community!

[stefano_mbp]

11 minutes ago, Miska said:

 

Have you tried same case without a NAA?

 

No. Tomorrow I’ll try and report you back the result

[Outlaw]

7 hours ago, Miska said:

 

Possibly yes, at DSD256 the amount of RAM on GPU can become close to being issue though. I don't have any 1080Ti model to test and the amount of RAM needed depends on the GPU model.

 

Video card has 11 gb ram

[Zauurx]

7 hours ago, Miska said:

 

Traffic is packet based, on multiple layers. There is no "stream", it is only virtual. Same for USB, when you use USB Audio Class, there is packet sent every 125 µs (8 kHz rate).

 

These small devices have only few ethernet MTUs (1500 bytes) worth of hardware buffer. At higher level, single TCP or UDP packet consists of multiple MTUs. When that hardware buffer comes full, the ethernet interface sends 802.3x pause frame towards switch asking it to stop sending. Switch handles this in it's own buffering and sends another 802.3x pause frame towards HQPlayer computer as needed.

 

Ethernet hubs used to be such dumb devices, but modern switches can be relatively smart, with multiple priority queues (buffers) for each port and such. So they know how to handle traffic of different priorities, like HQPlayer uses 802.1p/802.1Q.

 

Now the challenge is that the connection from the ethernet interface to the CPU and the CPU itself cannot handle full gigabit speed traffic. If the 802.3x flow control packet is getting ignored by the upstream devices, the hardware buffer will overflow and the remaining arriving packets are lost. This in turn triggers re-send at the higher level protocol when it is noticed. Since the traffic needs to be constant rate to transfer realtime audio, lost packets mean increased amount of traffic. Which is not making things any better...

....

 

 

I configured my NUC with a USB-Ethernet adapter directly connected to my Allo Sig, without going through a switch.
I also use Roon on the same server (2 USB-Ethernet cards). No bridge under Win10 but Roon which transmits to HQP.
HQP and Allo in IPV6. In IPV4 the NUC and the Allo are on 2 differents networks.
Roon: 192.168.1.89 (no IPV6)
HQP: 192.168.1.90 (+ IPV6)
Allo: IPV6 (+ 169.254.xx)
 

I configured the 2 adapters in 100Mb.
No problem in DSD 128 / ASDM7EC

[Miska]

2 hours ago, Zauurx said:

I configured my NUC with a USB-Ethernet adapter directly connected to my Allo Sig, without going through a switch.
I also use Roon on the same server (2 USB-Ethernet cards). No bridge under Win10 but Roon which transmits to HQP.
HQP and Allo in IPV6. In IPV4 the NUC and the Allo are on 2 differents networks.
Roon: 192.168.1.89 (no IPV6)
HQP: 192.168.1.90 (+ IPV6)
Allo: IPV6 (+ 169.254.xx)
 

I configured the 2 adapters in 100Mb.
No problem in DSD 128 / ASDM7EC

 

Yeah, with 100 Mbps it doesn't overwhelm much. The Freescale/NXP SoC used in many devices like Rendu can do up to 400 Mbps when 802.3x flow control is functional, this is documented in their datasheets. 100 Mbps will begin to have problems at higher rates because it is starting to run out of bandwidth.

 

You may still have 802.3x active between the two devices. It doesn't require a switch, but some smart switches are by default configured to discard those pause frame packets. And some optical gear doesn't gracefully handle it either (it is negotiated by the hardware at low ethernet level). That's why that is usually first thing I ask when someone says there's a problem.

 

[Miska]

2 hours ago, Outlaw said:

Video card has 11 gb ram

 

Yeah, someone needs to test it and report if it works or not. But I think there was such report above...

 

[Miska]

3 hours ago, Luca72c said:

If this can be done, some M1 users can try that (maybe even converting to DSD512 EC, if more load is needed) and see if 4 cores or just 2 are equally loaded. Some hint would be needed to distinguish between modulators and filters loads, maybe Jussi could help about that...

If 4 cores are equally loaded, then probably Silicon ARM architecture (and its management firmware/software) are capable of spreading modulator load across multiple cores and that would be very good news for HQPlayer community!

 

You can have the modulator running either on one or two cores. Technically some of it could be spread more, but the overhead keeps increasing, so it is not done at the moment. This spread doesn't come by itself, it needs to be explicitly programmed in.

 

[Outlaw]

6 minutes ago, Miska said:

 

Yeah, someone needs to test it and report if it works or not. But I think there was such report above...

 

Probably be better off to get the new 3070 when available ?

[Miska]

1 minute ago, Outlaw said:

Probably be better off to get the new 3070 when available ?

 

Depends on price and what you want to do. I still haven't got time to test even on the 3080 I have available. But from future proofing perspective getting something fresh is certainly better.

 

[Outlaw]

2 minutes ago, Miska said:

 

Depends on price and what you want to do. I still haven't got time to test even on the 3080 I have available. But from future proofing perspective getting something fresh is certainly better.

 

Okay thanks.Is there a CPU that can do all filters up to dsd 256 including sinc-l 

[Rune]

38 minutes ago, Outlaw said:

Probably be better off to get the new 3070 when available ?

Or a 3060 if the rumor is true that there will also be a 12GB version. It should be faster and cooler than the 1080 Ti which is also a physically big card.

So the 1080 Ti has to be really cheap else you should wait.

The 3060 TI and 3070 both have 8GB so not sure if the extra compute of the 3070 make any notable difference?

[bibo01]

4 hours ago, Miska said:

 

Have you tried same case without a NAA?

 

@Miska  I suppose that your look ahead request to MinimServer gets anticipated as the upsampling rate increases.

It seems that MinimServer cannot comply with that request in time for a successful gapless playback as the rate increases. 

Would that be possible for you to anticipate that request (perhaps for MinumServer only) just enough to execute the gapless operation? On the other hand, possibly Simon Nash of MinimServer can facilitate this operation on his side.

I think the two of you have good chances to solve this problem together.  

[k6davis]

6 hours ago, Luca72c said:

Friends, i had a (maybe stupid) idea to test if Apple new ARM architecture chips are really capable to spread modulators load across multiple cores. I don't know for sure if it is feasible or not, but i try to throw the ball in the playground...

Is there a way to force HQPlayer to play a mono music file and thus converting a single channel to DSD256 EC?

If this can be done, some M1 users can try that (maybe even converting to DSD512 EC, if more load is needed) and see if 4 cores or just 2 are equally loaded. Some hint would be needed to distinguish between modulators and filters loads, maybe Jussi could help about that...

If 4 cores are equally loaded, then probably Silicon ARM architecture (and its management firmware/software) are capable of spreading modulator load across multiple cores and that would be very good news for HQPlayer community!

 

@Luca72c this sounds like a great idea! 

The problem I see is that mono tracks still play out of both the left and right channels. I opened a normal stereo flac file in an audio editor and saved it as a mono flac file. The editor displayed it with one waveform instead of two and it was half the size of the original file. The stereo separation was gone, but it still played through both channels on the computer and through my stereo system.

@Mischa, is it possible for you, in a test scenario, to send only a single channel of a recording through HQP? Or maybe turn one of the two channels off in HQP?

[toddrhodes]

Hi all. Just curious if anyone has run into anything similar. I am listening to a new-to-me Ares II DAC and am really enjoying it. It sounds phenomenal in DSD256, poly-sinc-xtr-2s. The issue is I'm hearing minor "ticks and pops" during playback. I'm running Roon to a Pi3 endpoint that also has a Pi2AES hat on it, but since I'm using USB - I don't think that hat is really factoring in here.

 

As someone who also listens to a lot of vinyl - trust me I can appreciate the random tick or pop here and there. But it's a bit unexpected via digital. In any case, I've tried a couple of USB cables and have the same result. None of my USB cables are high-grade. 

For now I'm just using the Coax output and it sounds glorious but limits me to DSD64/PCM 192.

Am I on the right track that it's likely the Pi3 USB out causing the issue? I was using it for a couple of nights into my other DAC, a Benchmark DAC3L and never noticed anything like that but I am also limited to 192/DSD64, totally, on that DAC. So my thought is that maybe doing DSD256 and DSD512 is proving to be too much for the Pi3 to handle via USB without minor issues cropping up. Or, perhaps the USB input on the DAC3L is a little better than on Ares II? 

 

Anyway, just curious if anyone has any thoughts on how to troubleshoot this. I've reached out to Alvin of course but since I bought it secondhand, I fully expect to need to do some of this legwork on my own to track it down.

 

PS - I need to update my signature. That stuff is like 5 years old and I don't have any of it nowadays. So, uh, disregard that blob of text down there.

 

Edit 2 - So, using USB if I stick with DSD128 or DSD64 and use 44.1 as the bitrate, and use a light modulator like ASDM5 or ASDM7, it plays pretty much flawlessly. At least I haven't heard any issues. But as soon as I use the same modulators and try 256/44.1, or try to use something like ASDM5EC, I start getting these little ticks intermittently. Not sure if that helps any. I doubt it's my PC but in case it's the PC that can't keep up, I should be getting a Ryzen 3700X tomorrow that I hope to put together over the weekend and on my week off next week. My current machine is about 5 years old, but it's at least an i7 6700K, 32G RAM, 2070 Super GPU and I'm using CUDA Offload. So no slouch, but it's seen better days, for sure.