HQPlayer's Network Audio Adapter

[Miska]

14 hours ago, sup27606 said:

It sounds like a network speed issue, although another MacBook Pro on the same LAN network works fine as NAA using 768 khz. I wonder, is this a known issue with RPI4, that 768 kHz sampling rate is too high to work over wifi, that only ethernet is workable? I am using Dietpi OS. Thank you for your responses.

 

It may be similar buffer overflow - resend issue as commonly happens with those small CPUs on Ethernet if 802.3x flow control (aka pause frames) is not active.

 

You could try setting HQPlayer output Buffer time to 10 ms and see if it makes any change.

 

[sup27606]

9 hours ago, Miska said:

 

It may be similar buffer overflow - resend issue as commonly happens with those small CPUs on Ethernet if 802.3x flow control (aka pause frames) is not active.

 

You could try setting HQPlayer output Buffer time to 10 ms and see if it makes any change.

 

 

Hi, thank you for the suggestion. I tested with buffer time of 10 ms and didn't make any difference. Please note, this issue is only with the wifi. I took it to the router and connected using ethernet and the problem went away. However, since the router is in a different room, its not practical.

 

I was also looking to find out if anyone else tested the rpi4 as NAA with 768 kHz upsampling over wifi. Trying to make sure if its a general issue or only me. I understand, its probably more common to use NAA through ethernet.

[sup27606]

@Miska this issue got resolved after I replaced the onboard wifi with a more powerful USB wifi adapter, with external antennas. Just wanted to let you know. Thank you for your help.

[stefano_mbp]

@Miska Hi Jussi, is there any release note for the new NAA 4.5.0 ?

thanks

[Miska]

7 hours ago, stefano_mbp said:

@Miska Hi Jussi, is there any release note for the new NAA 4.5.0 ?

 

I just posted release announcement!

 

[stefano_mbp]

15 minutes ago, Miska said:

 

I just posted release announcement!

 

👍 thanks!

[Apollo]

2 hours ago, Miska said:

 

I just posted release announcement!

 

I can't find an image for Holo Red anymore!?

Dirk

[stefano_mbp]

2 minutes ago, Apollo said:

I can't find an image for Holo Red anymore!?

Dirk

It’s definitely there

 

[Apollo]

23 minutes ago, stefano_mbp said:

It’s definitely there

 

 

sorry, you are correct.

I overlooked due to the 'raspberrypi4' proceeding the 'holored' in the file name 

 

Thanks 

Dirk

[StreamFidelity]

4 hours ago, Miska said:

I just posted release announcement!

Do NAA devices like T+A SDV 3100 HV need to be updated?

[Miska]

43 minutes ago, StreamFidelity said:

Do NAA devices like T+A SDV 3100 HV need to be updated?

 

No, if it works, there's no pressing need to update.

 

 

[Chanh]

On 5/9/2023 at 2:38 PM, Rovo said:

I have not tested it yet, but with the following files and names it should not even be necessary to disable the network port(s) on the motherboard and it would also be suitable for network interface cards with more than two ports: 

 

10-device-enabled.network: 

[Match]

Name=network port name you want to have enabled (the one you have the cable connected to and has an IP address, use ifconfig)

 

[Link]

ActivationPolicy=up

 

 

20-other-devices-disabled.network: 

[Match]

Name=e*

 

[Link]

ActivationPolicy=always-down

 

 

I do not think Jussi can incorporate it in the next release of NAA OS as an automatic feature, because you will still need to put in the name of the network port you want to have enabled. Jussi could put in the above two files and in the first file for the name also use "e*". This way the NAA OS will still function as it always has done for PC's with only one network port. And for all the other situations we would only need to fill in the network port name in the first file. 

 

Apologise for the delay. 

Many thanks to Rovo - I am happy to share that his instructions worked flawlessly. 

Big thank you to you Rovo. I had it’s working with the latest NAA OS 4.50 currently. 

 

[phasedandconfused]

Longtime lurker here, first time poster. Just my two cents. I used to run a NAA on a Pi-like device—one made by Allo—but its performance wasn’t consistent. I now use an ultraRendu as the NAA. Performance is much more consistent with the ultraRendu. Spend the money and save yourself the frustration. 

[Zauurx]

On 7/27/2023 at 12:34 AM, Miska said:

 

No, if it works, there's no pressing need to update.

 

 

Like Gustard A26 ?

[Miska]

20 hours ago, Zauurx said:

Like Gustard A26 ?

 

Yes, same there too...

[Zauurx]

On 7/29/2023 at 4:57 PM, Miska said:

 

Yes, same there too...

Yes.. but installed anyway.. and fully functional ! 😉

[privacyguy123]

Could somebody explain to me why hqplayer embedded insists on seeing these goofy ass sample rates when I've tried explicitly blocking them in every config file I can find?

 

  2023/08/19 20:28:54 ALSA input rate available: 32000
  2023/08/19 20:28:54 ALSA input rate available: 64000
  2023/08/19 20:28:54 ALSA input rate available: 128000

When using auto sample rate it's picking up this nonsense instead of multiples of 44.1 & 48k :S

 

If it's really hard wired into the code then let us choose a dummy or "none" output and use our own programs to route hqplayers audio output perhaps?

[Miska]

15 minutes ago, privacyguy123 said:

Could somebody explain to me why hqplayer embedded insists on seeing these goofy ass sample rates when I've tried explicitly blocking them in every config file I can find?

 

  2023/08/19 20:28:54 ALSA input rate available: 32000
  2023/08/19 20:28:54 ALSA input rate available: 64000
  2023/08/19 20:28:54 ALSA input rate available: 128000

 

Why do you think those are goofy? Those are completely standard ones. And your input device seems to support those.

 

15 minutes ago, privacyguy123 said:

When using auto sample rate it's picking up this nonsense instead of multiples of 44.1 & 48k :S

 

Ask your ALSA device, that's what it advertises.

 

15 minutes ago, privacyguy123 said:

If it's really hard wired into the code then let us choose a dummy or "none" output and use our own programs to route hqplayers audio output perhaps?

 

Above you show input device stuff and now you talk about output? Can you explain more about the case?

 

You have option to select [none] as input backend. And you have option to select Null output backend. Although null output backend is mostly useful for benchmarking purposes.

 

HQPlayer wants to have direct low level access to the actual input and output hardware (D/A conversion stage), that's why there's nothing to "route".

 

[privacyguy123]

2 minutes ago, Miska said:

 

Why do you think those are goofy? Those are completely standard ones. And your input device seems to support those.

 

 

Ask your ALSA device, that's what it advertises.

 

 

Above you show input device stuff and now you talk about output? Can you explain more about the case?

 

You have option to select [none] as input backend. And you have option to select Null output backend. Although null output backend is mostly useful for benchmarking purposes.

 

 

The issue is that when using "auto" sample rate option it is preferring multilples of 32000, which is goofy considering the Pi DAC I'm using isn't supposed to be able to compatible with those. I've blocked all such rates except multiples of 44.1/48 in config files and hqplayer is ignoring that. I'm using Pipewire on top of ALSA.

 

In hqplayer embedded I am not seeing a "Null" option on the output page. Input set ot auto is picking up these goofy rates.

[Miska]

3 minutes ago, privacyguy123 said:

I'm using Pipewire on top of ALSA.

 

That's your problem then... You are just spoiling entire point of HQPlayer by putting Pipewire in the middle.

 

8 kHz sampling rate is standard sampling rate for mobile phone calls and also for old wired phone networks. Newer wideband audio calls use 16 kHz sampling rate and then modern audio/video calls over internet use 32 kHz sampling rate for voice, called "ultra-wideband audio".

 

[privacyguy123]

7 minutes ago, Miska said:

 

That's your problem then... You are just spoiling entire point of HQPlayer by putting Pipewire in the middle.

 

8 kHz sampling rate is standard sampling rate for mobile phone calls and also for old wired phone networks. Newer wideband audio calls use 16 kHz sampling rate and then modern audio/video calls over internet use 32 kHz sampling rate for voice, called "ultra-wideband audio".

 

I understand this to an extent, but I am using a 192khz Hifiberry DAC inside of a Pi and capturing audio from outside sources, like Tidal Connect and Spotify Connect, routing it through Hqplayer Embedded for the upsampling and out to speakers. In all the jumbled spaghetti code and config files in Linux there must be a way to block out this 32000 nonsense?

Is there a better way to run a Pi with hqlayer embedded as a "poor mans M-scaler" ? It seems I am not the only one on the internet doing something similar but ALSA backend is the bottleneck, it seems.

[Miska]

1 minute ago, privacyguy123 said:

I understand this to an extent, but I am using a 192khz Hifiberry DAC inside of a Pi to capture audio from outside sources, like Tidal Connect and Spotify, routing it through hqplayer and out to speakers. In all the jumbled spaghetti code and config files in Linux there must be a way to block out this 32000 nonsense.

 

I'm somehow missing what a DAC (analog output device) has to do with HQPlayer inputs!?

 

I use ADI-2 Pro for S/PDIF and AES/EBU inputs, as well as analog inputs, for such purposes. And these are preconfigured already in HQPlayer Embedded, you just need to adjust the device id's in the configuration files, since every RME device has a unique device id. Allowing you to distinguish between multiple connected ADI-2 Pro devices for example.

 

[privacyguy123]

4 minutes ago, Miska said:

I use ADI-2 Pro for S/PDIF and AES/EBU inputs, as well as analog inputs, for such purposes.

 

How would Tidal Connect output to a ADI-2 through SPDIF -> HQPE when it's a Linux program??? I think we are misunderstanding eachother here ...

 

Am I to understand that the only option to get Tidal Connect -> Hqplayer as an upsampler (with correctly working auto sample rate) -> speakers is to buy THREE ££££ boxes? At that point I may as well ditch HQPE and get an Mscaler ...

[Miska]

Just now, privacyguy123 said:

How would Tidal Connect to a ADI-2 through SPDIF when it's a Linux program??? I think we are misunderstanding eachother here ...

 

For example, I have WiiM Pro -> S/PDIF -> ADI-2 Pro -> HQPlayer -> DAC. Automatic sample rate switching works perfectly and anything I can play with WiiM Pro goes through HQPlayer.

 

I also have iPad Pro -> USB-to-AES -> ADI-2 Pro -> HQPlayer -> DAC. This allows Apple Music, bit perfect with automatic rate switching to go through HQPlayer.

 

[privacyguy123]

Just now, Miska said:

For example, I have WiiM Pro -> S/PDIF -> ADI-2 Pro -> HQPlayer -> DAC. Automatic sample rate switching works perfectly and anything I can play with WiiM Pro goes through HQPlayer.

 

Quote

Am I to understand that the only option to get Tidal Connect -> Hqplayer as an upsampler (with correctly working auto sample rate) -> speakers is to buy THREE ££££ boxes

 

Sadly that does seem to be your answer then :|

 

There is no other workaround for a poor mans Mscaler setup?