HQPlayer's Network Audio Adapter

[Miska]

2 hours ago, Rovo said:

@MiskaI take it is not the initramfs I am looking for.

 

If you look on how to modify initramfs image, then you are looking at the correct instructions.

 

[Miska]

7 hours ago, Apollo said:

@Miska, can you please provide a complete link to your custom kernel packaged for Ubuntu?

I can locate a hqplayerd folder with images at signalist.eu/bins , as well as NAA images, but nothing else ):-

 

I prefer not to post direct links, since those are subject to change and get broken over time when people read these posts later.

 

There's a link provided on the HQPlayer Desktop product page for example. Just search for "kernel" on that page.

 

[Miska]

Why not just use the non-ramfs image?

 

[Miska]

16 hours ago, the_bat said:

Looking at a connected monitor everything seems to boot up and run fine, and the box can be pinged over the network but it looks like the NAA service never starts up.  I can log in from the console and i've tried to restart the networkaudiod service, which doesn't return an error but still doesn't show up as a networked device in HQPlayer preferences.

 

The same SSD works perfectly in a Pi4.

 

If networkaudiod doesn't get started, it is because network doesn't become fully configured, which is dependency for the networkaudiod service. Does "ifconfig" show more than one ethernet interface?

 

[Miska]

3 hours ago, the_bat said:

I don't believe so - see ifconfig output below.

 

 know the multiple ethernet inputs was an issue if trying to use the CM4-CM3 adapter, but the IO board should only be exposing the CM4s ethernet interface.

 

What does "systemctl status networkaudiod" and "journalctl -u networkaudiod" say?

 

[Miska]

6 hours ago, the_bat said:

Again, the discovery/connection/disconnection cycle repeated many times

 

Looks like networkaudiod is working just fine. You just don't have any discoverable audio devices available...

 

[Miska]

2 hours ago, the_bat said:

I have an Allo Digione Signature card attached to it and powered up.  It works with other systems, but networkaudiod doesn't seem to be detecting it.

 

It would likely need correct overlay to be specified in config.txt, but I don't think it is part of the official RPi kernel. Supported overlays are listed on my HQPlayer Embedded installation instructions web page.

 

On ARM systems, there's no such thing as ACPI on PC's that would allow straightforward auto-detection of onboard hardware. Instead ARM platforms rely on something called device tree which consists of component specific files defining that they exist and how they are connected on hardware level. In Raspberry Pi world, snippets of these device trees are called "overlays".

 

USB devices support such auto-detection though, because it is part of the USB bus specification.

 

[Miska]

3 hours ago, the_bat said:

I'm not sure if this applies to other i2s HATs.

 

HifiBerry doesn't need this, as it's overlay in itself contains the necessary bits and pieces.

 

[Miska]

19 hours ago, Schafheide said:

Does the "naa-440-raspberrypi4-holored image" support PCM1536 on the Holo Red ??

 

Yes it does...

 

[Miska]

Just now, Schafheide said:

I note that in Device settings in HQP "Outputs",  I have the choice of .........Gen2 Enhanced: USB Audio

 

This is the DAC attached through USB port.

 

Just now, Schafheide said:

and .......Gen2 - Red: USB Audio.

 

This is the Red's built-in DDC, meaning S/PDIF, AES and I2S outputs.

 

[Miska]

43 minutes ago, sledwards said:

Must me related to DietPi or my network. I get the same static during playback with Roon only thru RoonBridge.

 

This is known problem for RPi2 and RPi3 because they have cut too many corners in the hardware design. Ethernet controller is attached to the same bus where the USB port resides and it causes lost USB audio packets which causes such pops.

 

RPi4 doesn't have such shortcoming, instead they use the ethernet controller built right into the CPU.

 

This is the reason I'm not providing NAA OS images for RPi3, but only for RPi4.

 

[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.

 

[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!

 

[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.

 

 

[Miska]

20 hours ago, Zauurx said:

Like Gustard A26 ?

 

Yes, same there too...

[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".

 

[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".

 

[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.

 

[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.

 

[Miska]

Just now, privacyguy123 said:

Sadly that does seem to be your answer then :|

 

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

 

You can make it cheaper if you are OK to manually switch sampling rate. For Spotify it is non-issue since Spotify is always fixed 44.1k rate.

 

Simpler and cheaper solution for Tidal is to use Roon as HQPlayer front-end.

 

Or even cheaper, switch from Tidal to Qobuz and use HQPlayer's native Qobuz support. You also get rid of MQA that way.

 

[Miska]

Although, how do you come up with three €€€€ boxes? Only the ADI-2 is a bit more expensive. USB-to-S/PDIF is cheap or WiiM Pro or WiiM Mini as source is cheap.

 

[Miska]

7 minutes ago, privacyguy123 said:

While I have you here can you explain if I force set input in HQPE to 192 am I resampling everything using the low quality ALSA/Linux algo yes?

 

Yes, if you get audio and the source rate is not 192k.

 

If you use input hardware, and the rates mismatch, then you just don't get any sound until you restart the input with matching rate. HQPlayer always attempts to use low level hardware access without any OS rate conversion algorithms. (ALSA "hw" devices)

 

With ADI-2, HQPlayer has specific support for that particular piece of hardware, and HQPlayer can detect the correct input rate and switch automatically. But generally, ALSA or USB Audio Class doesn't support input rate slaving, it requires some custom workarounds, both in hardware and in software.

 

[Miska]

26 minutes ago, privacyguy123 said:

Can you comment on if WiiM Pro SPDIF out straight into RPi HQPE OS box with SPDIF in board https://www.hifiberry.com/shop/boards/hifiberry-digi2-pro/ (which claims to have "dual-domain 44.1/48kHz clock circuit to support all rates") will allow for automatic sample rate matching? Or is there a necessity for the transport to be USB?

 

So far I have only https://www.hifiberry.com/shop/boards/hifiberry-digi-io/ (IIRC). See their notes about the digital input though:

https://www.hifiberry.com/docs/hardware/comparison-of-hifiberry-cards-for-audio-recording/

 

That Digi2 Pro is output-only as it says there.

 

No need to be USB, also RME HDSPe AIO card works (PCIe card). But note that it's Linux drivers are a bit buggy. So it is only partially functional. IIRC, Toslink input rate switching works fine up to 96k, AES input rate switching works fine up to 192k, but coaxial only up to 48k. This is because the driver is a bit buggy.

 

So far verified:

• RME ADI-2 Pro on Linux
• RME HDSPe AIO fon Linux, partially functional
• RME HDSPe AIO on Windows

RME Digiface USB would be otherwise fine on Windows, and can auto-switch 44.1 <-> 48, or 88.2 <-> 96 or 176.4 <-> 192. But not between rate families. This is driver bug and RME didn't bother to respond to me about this anymore.  RME also refuses to fix their ADI-2 Windows driver to work, although it is technically entirely possible. So far, only RME HDSPe AIO (latest version) works properly on Windows, which they fixed after my request.

 

I have burned some 5000€ buying other hardware trying to find something that would work as well, but so far it has been just lost money. Manufacturers don't document anywhere whether they support proper sample rate slaving. ASIO on Windows is only driver framework that fully and properly support this. But since it is defined as optional there, most manufacturers don't implement it in their hardware / drivers. On Linux, these can be made to work since we have the full OS and driver source code available, but it still also requires that the hardware supports it.

 

Thus, if you want automatic rate switching, you have those three above options. Or you can try alternatives if you are ready to burn money to get disappointed like I have been doing.

 

[Miska]

50 minutes ago, privacyguy123 said:

Are you saying Digi+ IO works with auto sample rate changing or not?

 

As it says in the HifiBerry notes, no it doesn't. Because it cannot detect or indicate the incoming rate. So you need to manually match the rate. And if the incoming bitstream stops, the device gets stuck because it doesn't have a fallback clock for such cases.

 

50 minutes ago, privacyguy123 said:

WiiM Pro SPDIF (supports auto sample rate in documentation) -> Digi+ IO (weird wording in documentation, unsure) -> RPi HQPE -> DAC (doesn't have to be RMI ADI 2, too expensive.)

 

If you want automatic rate switching, there are the options I stated earlier. No other options I'm aware of. But would be happy to hear about such if someone finds some other ones.

 

With manual rate switching there's almost endless list of possible input hardware.

 

[Miska]

14 minutes ago, privacyguy123 said:

Looking for specifically auto sample rate switching bud - I have hit a brick wall with this RPi homebrew stuff, I don't think it will ever work the way I expected.

 

RPi4 works fine as input NAA - with ADI-2 Pro connected as the input interface.

 

With manual rate switching, for example miniDSP USBStreamer is preconfigured in HQPlayer / NAA (device needs to be flashed with their Toslink Stereo firmware variant if not shipped as such from the factory).