HQPlayer Embedded & Ravenna Issue

[bodiebill]

7 minutes ago, Miska said:

 

I think I've heard that JRiver has such limitation. But why do you want to do DSP with JRiver if you use HQPlayer?

 

I do use JRiver DSP when sending tracks to other renderers, so it is possible.

 

Why want this? Well... spreading the CPU load between two PC's. I remember you even recommended this somewhere?

When using the most demanding HQPE settings (EC modulators etc.), adding convolution has a noticeable effect here in terms of dropouts.

 

7 minutes ago, Miska said:

Now it looks more normal...

 

OK, good to know. I no longer get the JRiver error message when streaming to HQPE renderer. But also no sound now :-| I cannot yet get a grip on this...

[bodiebill]

20 minutes ago, El Guapo said:

169.254.x.x is zeroconf IP address. Generated by device itself. Most likely Ravenna network prefer zeroconf for killing less brain cells.😆

 

If you setup 2 VLANs, you can either configure dual RJ45 NAA as bridge or dual RJ45 HQPe server.

 

If you choose first option, designate one of the RJ45 connects to Ravenna VLAN (remember to edit Ravenna configuration file) and the other RJ45 connects to home network. HQPe connects to home network. HQPe will see the NAA at home network side.

 

If you choose second option, NAA is not needed anymore. Just designate one of the RJ45 of HQPe server to connect to Ravenna VLAN (same, needs to properly conf Ravenna). HQPe's audio will direct output to Hapi. The other RJ45 connects to home network. Other devices will see your HQPe server at home network side.

 

The second option applies to me as the Linux PC with Ravenna ALSA and the HQPE server has two NIC's. I just swapped them and now there is music again with JRiver seeing the HQPE renderer as

 

Messing around, but getting there...

[The Computer Audiophile]

On my Netgear M4250-10G2F-PoE+ that I use for my 12 channel Ravenna system, I don't mess around with VLANS. VLANS aren't going to make your audio work or not work, in most cases. It's the other settings that will be important. If you just let all the devices on your network use the same IP subnet, they can communicate without an issue. 

 

My switch has an AES67 profile I enabled, to take care of all the settings. I still get IP addresses from my main router and don't have any special VLANS on this switch. Every device can communicate to every other device and the internet. 

[bodiebill]

2 minutes ago, The Computer Audiophile said:

On my Netgear M4250-10G2F-PoE+ that I use for my 12 channel Ravenna system, I don't mess around with VLANS. VLANS aren't going to make your audio work or not work, in most cases. It's the other settings that will be important. If you just let all the devices on your network use the same IP subnet, they can communicate without an issue. 

 

My switch has an AES67 profile I enabled, to take care of all the settings. I still get IP addresses from my main router and don't have any special VLANS on this switch. Every device can communicate to every other device and the internet. 

 

That sounds great. Where did you get the AES67 profile that you used? 

[The Computer Audiophile]

5 minutes ago, bodiebill said:

 

That sounds great. Where did you get the AES67 profile that you used? 

Built into the switch 

[Miska]

1 hour ago, bodiebill said:

Why want this? Well... spreading the CPU load between two PC's. I remember you even recommended this somewhere?

 

Yes, but not DSP load. For example Roon indexing and graphics, other activity not related to playback itself. All DSP should be preferably done in one place.

 

If you really really need to do DSP in two places, you should ensure that data between source and HQPlayer is 64-bit floating point. This is what Roon uses with HQPlayer to preserve intermediate resolution. But that will use quite a bit a network bandwidth especially at higher rates or multichannel, each sample being 8 bytes.

 

1 hour ago, bodiebill said:

When using the most demanding HQPE settings (EC modulators etc.), adding convolution has a noticeable effect here in terms of dropouts.

 

That's where GPU comes to help. And I doubt JRiver knows how to do convolution properly for DSD -> DSD paths.

 

[bodiebill]

I have decided not to continue with Ravenna ALSA as it is just too unstable here.

 

I will try two alternatives:

 

(1) Ravenna ASIO on Windows with HQP Desktop. I actually tried this yesterday and all went smooth. Also one computer less.

 

(2) Via NAA as suggested by @Miska and @El Guapo, and in this setup:

Linux PC with HQPE --> Windows NUC with NAA and Ravenna ASIO ---> Hapi

 

The second has my preference as I have a HQPE license, but not a Desktop one. However, so far HQPE does not detect NAA on the NUC (with firewall deactivated). I hope I can make this work.

 

P S It works now, NAA is recognized after installing a new version of the Microsoft Visual Redistributable :-)

[bodiebill]

On 8/26/2022 at 10:13 AM, bodiebill said:

I have decided not to continue with Ravenna ALSA as it is just too unstable here.

 

I will try two alternatives:

 

(1) Ravenna ASIO on Windows with HQP Desktop. I actually tried this yesterday and all went smooth. Also one computer less.

 

(2) Via NAA as suggested by @Miska and @El Guapo, and in this setup:

Linux PC with HQPE --> Windows NUC with NAA and Ravenna ASIO ---> Hapi

 

The second has my preference as I have a HQPE license, but not a Desktop one. However, so far HQPE does not detect NAA on the NUC (with firewall deactivated). I hope I can make this work.

 

P S It works now, NAA is recognized after installing a new version of the Microsoft Visual Redistributable :-)

 

Update:

For now, the Ravenna/Linux route for me has to many obstacles and instabilities, so I have chosen for Windows only on one PC with 2 NICs. I got me a HQP 4 Desktop license for that. Now it all plays much more stable, and the results with DSD256 are pretty stunning.

 

I am now trying out different HQP modulators and filters. Any recommendations from owners of Merging devices are welcome. The Merging website recommends these settings:

but I guess this may be outdated as new filters/modulators were created by @Miska since then.

[El Guapo]

12 minutes ago, bodiebill said:

Any recommendations from owners of Merging devices are welcome.

For any rate upsampling to DSD256 on Merging's interface I prefer

1x: poly-sinc-gauss-long

Nx: poly-sinc-gauss-hires-lp

Modulator: ASDM5ECv2

[bodiebill]

3 minutes ago, El Guapo said:

For any rate upsampling to DSD256 on Merging's interface I prefer

1x: poly-sinc-gauss-long

Nx: poly-sinc-gauss-hires-lp

Modulator: ASDM5ECv2

 

Thanks!

 

Given Merging's and your recommendation: is there any intrinsic reason that level 5 modulators are more suited for Merging DACs than level 7?

[Miska]

23 minutes ago, bodiebill said:

Given Merging's and your recommendation: is there any intrinsic reason that level 5 modulators are more suited for Merging DACs than level 7?

 

Settings proposed by @El Guapo are good for all Merging devices.

 

If the DAC card you have is based on ESS chip, ASDM5ECv2 is a good starting point. At DSD256 you can use ASDM7ECv2 as well if you like. IIRC, Merging has had DAC cards based on both ESS and AKM chips. For AKM chips, ASDM7ECv2 is good.

 

[bodiebill]

9 minutes ago, Miska said:

 

Settings proposed by @El Guapo are good for all Merging devices.

 

If the DAC card you have is based on ESS chip, ASDM5ECv2 is a good starting point. At DSD256 you can use ASDM7ECv2 as well if you like. IIRC, Merging has had DAC cards based on both ESS and AKM chips. For AKM chips, ASDM7ECv2 is good.

 

 

Thanks Jussi. I have a DA8P card with a ES9008 or ES9028PRO chip. Not sure how I can see which...

[Miska]

5 hours ago, bodiebill said:

Thanks Jussi. I have a DA8P card with a ES9008 or ES9028PRO chip. Not sure how I can see which...

 

It shouldn't matter much. The basic conversion thing has not been changing in these ESS chips.

 

[matthias]

On 8/29/2022 at 3:39 PM, bodiebill said:

 I have a DA8P card with a ES9008 or ES9028PRO chip. Not sure how I can see which...

The latest one use the ES9028PRO, the former one the ES9008. AFAIK, the change was around 2019.

 

Matt

[bodiebill]

11 minutes ago, matthias said:

The latest one use the ES9028PRO, the former one the ES9008. AFAIK, the change was around 2019.

 

Thanks Matt, in that case I believe I have ES9008 as S9028PRO was introduced with Run 11.

 

[matthias]

10 minutes ago, bodiebill said:

 

Thanks Matt, in that case I believe I have ES9008 as S9028PRO was introduced with Run 11.

 

Yes, afaik introduced with Run 11.

 

Matt

[bodiebill]

I was told that the DAC chip is not so crucial as many tasks are performed by the Hapi FPGA (especially for DSD?). Maybe someone with more technical knowledge than me can corroborate...

[matthias]

10 minutes ago, bodiebill said:

I was told that the DAC chip is not so crucial as many tasks are performed by the Hapi FPGA (especially for DSD?). Maybe someone with more technical knowledge than me can corroborate...

+1,

would be nice to know what exactly happens to the signal in the Hapi FPGA.

 

Matt

[Musicimage]

On 8/29/2022 at 8:29 PM, Miska said:

 

Settings proposed by @El Guapo are good for all Merging devices.

 

If the DAC card you have is based on ESS chip, ASDM5ECv2 is a good starting point. At DSD256 you can use ASDM7ECv2 as well if you like. IIRC, Merging has had DAC cards based on both ESS and AKM chips. For AKM chips, ASDM7ECv2 is good.

 

@MiskaMay I ask which Model of DA card from Merging based on both ESS and AKM chips? Thank you!

[Miska]

1 hour ago, Musicimage said:

@MiskaMay I ask which Model of DA card from Merging based on both ESS and AKM chips? Thank you!

 

I have to say it is best to ask them directly. I don't have any Merging gear anymore and I don't remember right now.

 

I believe the earlier 8 channel "pro" DA card was based on an old ESS DAC chip model. And the newer one based on AKM. But I'm not completely up to date with their current lineup. In addition there are non-"Pro" DA card models that cannot do DSD.

 

[Musicimage]

@MiskaThanks for your reply!
Some time ago, I also saw MERGING HAPI on the "Recommended hardware" list on the official HQPLAYER website, but now it has been removed from the list, what is the reason?
I am planning to buy a multi-channel DAC for HQplayer to play with, can you recommend a multi-channel DAC suitable for HQplayer?

[Miska]

3 hours ago, Musicimage said:

Some time ago, I also saw MERGING HAPI on the "Recommended hardware" list on the official HQPLAYER website, but now it has been removed from the list, what is the reason?

 

I don't have it anymore. And Merging has second generation of Hapi which I have not tested.

 

3 hours ago, Musicimage said:

I am planning to buy a multi-channel DAC for HQplayer to play with, can you recommend a multi-channel DAC suitable for HQplayer?

 

exaSound s88 for example has built-in NAA functionality and can do 8 channels of DSD256. If you need more channels, then Hapi is better choice.

 

[Musicimage]

Thank you so much!