HQPlayer's Network Audio Adapter

[Miska]

2 minutes ago, Johnseye said:

Would you be willing to share your kernel customization in the spirit of open source with Pierro & Zeljko so that they can support HQPlayer upsampling to DSD1024 and 1536 PCM?  

 

Why? They can of course do their homework... ;)

 

I did mine when I implemented support for it.

 

[Johnseye]

2 minutes ago, Miska said:

 

Why? They can of course do their homework... ;)

 

I did mine when I implemented support for it.

 

 

Well, that's an easy answer.  It's in support of your product.

 

[Miska]

2 minutes ago, Johnseye said:

Well, that's an easy answer.  It's in support of your product.

 

No, it would be supporting their product.

 

I support mine (HQPlayer OS and NAA OS). Plus Ubuntu and Debian as extra...

 

[Johnseye]

2 minutes ago, Miska said:

 

No, it would be supporting their product.

 

I support mine (HQPlayer OS and NAA OS). Plus Ubuntu and Debian as extra...

 

 

I guess if that's the way you view the inclusion and use of HQPlayer in their platforms.

[hifi25nl]

I can say this because all my code is open to look at and has been copied by some... and I am also making support for HQPlayer and I am using HQplayer myself as the main audio application.

 

...BUT if you have modified some part of a kernel module or application that was released under a variant of GPL you should make the source available, I think.

[Miska]

2 minutes ago, hifi25nl said:

...BUT if you have modified some part of a kernel module or application that was released under a variant of GPL you should make the source available, I think.

 

For example you can download exact source tarballs of my custom Ubuntu/Debian kernels from the same place where the .deb packages are. You just need to extract the package, and run "make oldconfig ; make bindeb-pkg" to get the same .deb packages I've built.

 

Unlike many other vendors who ship Linux-based products, I comply with the GPL requirements.

 

[Miska]

42 minutes ago, Johnseye said:

I guess if that's the way you view the inclusion and use of HQPlayer in their platforms.

 

I should do their work for free, for them, so they can charge money for it? Come on please...

 

When they ship HQPlayer on their platform, they are primarily responsible for supporting HQPlayer on their platform.

 

I'm well busy enough working on my products on the platforms I support.

 

[Johnseye]

13 minutes ago, Miska said:

 

I should do their work for free, for them, so they can charge money for it? Come on please...

 

When they ship HQPlayer on their platform, they are primarily responsible for supporting HQPlayer on their platform.

 

I'm well busy enough working on my products on the platforms I support.

 

 

I personally don't care.  It's your relationship with your business partners.  Some business owners view things differently.

 

As a consumer all I want is to be able to use your software on their platform to upsample at the highest frequency my DAC supports.  All of you make great software.  I'm just asking for something that it seems only you have done.

 

I have high confidence that Piero at least will take what you've told him and do something with it.

[hifi25nl]

23 minutes ago, Miska said:

I should do their work for free, for them, so they can charge money for it? Come on please...

 

Yes but MANY hqplayer Licenses has been bought because of Audiolinux and other archlinux distributions that otherwise you would not have sold.

 

Not taking into account the licenses that some hardware manufacturer have bought in their Audiolinux systems, sometime in bundle.

 

From a commercial point of view and a more realistic business view a different approach could be better.

 

My humble opinion. 

[Miska]

35 minutes ago, hifi25nl said:

Yes but MANY hqplayer Licenses has been bought because of Audiolinux and other archlinux distributions that otherwise you would not have sold.

 

Or likewise you have sold many Audiolinux licenses due to HQPlayer that you wouldn't have otherwise sold.

 

I guess your thing is making Audiolinux. You are asking money specifically for Audiolinux. I'm not asking any money for HQPlayer OS or NAA OS.

 

I just don't like being asked to help other people make money on something I do for free.

 

If some commercial entity needs help, I can think about it at hourly fee.

 

[Miska]

We can also just compare who has most upstreamed Linux kernel patches...

 

[Johnseye]

50 minutes ago, Miska said:

 

Or likewise you have sold many Audiolinux licenses due to HQPlayer that you wouldn't have otherwise sold.

 

I guess your thing is making Audiolinux. You are asking money specifically for Audiolinux. I'm not asking any money for HQPlayer OS or NAA OS.

 

I just don't like being asked to help other people make money on something I do for free.

 

If some commercial entity needs help, I can think about it at hourly fee.

 

 

Or, you have both sold more licenses by working together and combining your products.  

 

By the way, I've purchased HQPlayer Embedded, Windows desktop and previously Linux desktop when they were separate products.  I've also bought upgraded versions.

 

[jabbr]

On 10/21/2021 at 3:44 PM, Johnseye said:

 

Would you be willing to share your kernel customization in the spirit of open source with Pierro & Zeljko so that they can support HQPlayer upsampling to DSD1024 and 1536 PCM?  

 

There are several aspects to custom kernels :

 

1) direct modification of source code files

2) patches to source code files

3) custom compilation flags i.e. build process

 

In the same way that Audiolinux and other distribution vendors typically do not supply their build scripts, there is no expectation that  @Miska supply the build scripts for NAAOS or HQPlayerOS.

 

I'm a bit surprised that the Audiolinux folks @hifi25nl don't develop their own patch file to add support for higher bitrates to their kernel. I'm assuming you know your way around the ALSA code like the back of your hand. The support is not HQPlayer specific rather for any source that is DSD1024 or PCM 1536

 

@Miska why hasn't higher bitrate support been mainlined if you don't mind sharing?

 

 

[jabbr]

On 10/21/2021 at 4:04 PM, hifi25nl said:

...BUT if you have modified some part of a kernel module or application that was released under a variant of GPL you should make the source available, I think.

 

I'm befuddled by this ... the source is available.  Is it too hard to look through it and see what mods might be? ... I mean I haven't but they are somewhat obvious ... so why should he handhold you? Adding a new bitrate has been done many times in the past and there is a history of edits that can instruct on the methods... you guys can do this, right?

 

@Miska has a long history of adding features to the GPL linux drivers that enable DSD features (including new bitrates). These have been upstreamed and are in the linux kernel.

[Miska]

1 hour ago, jabbr said:

@Miska why hasn't higher bitrate support been mainlined if you don't mind sharing?

 

It wouldn't be accepted because it violates USB specifications.

 

USB specifications are public, anybody can read those to understand.

 

[hifi25nl]

All Audiolinux/Archlinux files for compiling realtime kernels can be obtained here:

 

LINUX-RT: https://aur.archlinux.org/cgit/aur.git/snapshot/linux-rt.tar.gz

LINU-RT-LTS: https://aur.archlinux.org/cgit/aur.git/snapshot/linux-rt-lts.tar.gz

LINUX-RT-BFQ: https://aur.archlinux.org/cgit/aur.git/snapshot/linux-rt-bfq-dev.tar.gz

 

In Audiolinux I have added an extra simple patch to linux-rt-bfq kernel file /sound/usb/quirks.c for a pair of DAC not working with the default kernel configuration.

 

Alsa developers are somewhat against about adding new base sampling frequencies if not used by many DACs (there are some posts about this in kernel mailing lists) and suggest to add support for extra frequencies in codecs.

 

Since one user asked me, the last 2 days I have been working on a patch.

 

I can even post here, but I fear is too technical for this thread.

 

 

[hifi25nl]

See for example:

https://www.spinics.net/lists/alsa-devel/msg125576.html

and

https://www.spinics.net/lists/alsa-devel/msg125577.html

[jabbr]

1 hour ago, hifi25nl said:

See for example:

https://www.spinics.net/lists/alsa-devel/msg125576.html

and

https://www.spinics.net/lists/alsa-devel/msg125577.html

Exactly! Terrific.

 

Its great to see open source, and not much effort for people to learn from eachother.

[wisechoice]

So I've really been enjoying HQPlayer with DSD512 now that I can get my DACs working in native mode via a RPi 4 NAA. This is a very cool possibilty for someone who is mostly on a Mac and therefore would otherwise be limited to DoP & DSD256.

 

Recently, I also started experimenting with WiFi and, at Jussi's suggestion, setup the wlan0 interface with wpa_supplicant, systemd & networkd. This is mainly so I can walk around my place while powering the Pi via a power bank/battery pack using a portable DAC/AMP dongle (I have both the THX Onyx & Hidizs S9 Pro). In case anyone else is interested in this configuration, I followed the instructions here.

 

This works great, except that I need to plug in the ethernet connection in order for HQPlayer to recognize the NAA. Then I can select the DAC, start playing, and unplug from ethernet. Amazingly, it switches over to wireless seamlessly most of the time. It's a bit awkward, but it's worth it for a listening session that may last several hours, while moving from room to room and not bothering anyone else with my music.

 

I've also recently purchased the new Pi Zero 2 W, which I'm thinking should be able to handle the same duties in a much smaller and less power-hungry package. It has roughly the same processing abilities as the RPi 3, albeit with less RAM. However, there is no ethernet, and only two micro USB ports, and one is for power. I can therefore only have the DAC or a USB ethernet adapter plugged in, not both. That means there is no way to bootstrap the WiFi streaming via Ethernet and then unplug the network adapter while leaving the DAC connected (unless I use a hub and carry it with me, too—or perhaps add a hat to the Zero, either of which would cancel much of the size advantage of the Zero).

 

Furthermore, it seems like the stripped-down image of Arch Linux that Jussi created doesn't (yet) include support for the new RPi Zero 2 W hardware. And I can't easily update the installation because there isn't a package manager on the image. The RPi 3 image works, but it doesn't see the wireless chip on the new Zero. And the RPi 4 image hangs at the rainbow boot screen. (see the discussion of similar issues, which seem to be resolved with updates, here).

 

The final wrinkle is that my new Hidizs S9 Pro (which I bought for portable DSD512 capability) doesn't have native support on the RPi image.

 

I understand that what I'm doing is not all officially supported, and these are not complaints so much as a field report from someone who is experimenting on the cutting edge (I think?)… but it would be great to know which of these problems are fixable, and which ones may not be.

 

My ideal setup, in case it isn't clear from everything I've written, would be to have the RPi Zero 2 W recognized by HQPlayer over WiFi, and stream audio to the Hidizs S9 Pro in native DSD mode at DSD512. It may be a pipe dream, but it would make a very compact and excellent-sounding package.

 

Thanks in advance to anyone who can help!

 

 

[Outlaw]

Trying NAA on a Rasberry PI3.All I can get is PCM which plays slow and crackling.No DSD at all ? Any ideas

[The Computer Audiophile]

8 minutes ago, Outlaw said:

Trying NAA on a Rasberry PI3.All I can get is PCM which plays slow and crackling.No DSD at all ? Any ideas

Are you using an NAA image? Which DAC?

[Outlaw]

2 minutes ago, The Computer Audiophile said:

Are you using an NAA image? Which DAC?

Yes NAA image.Dac is a Moon 280D

[bibo01]

1 hour ago, Outlaw said:

Dac is a Moon 280D

Connected through USB?

[Outlaw]

1 hour ago, bibo01 said:

Connected through USB?

Yes through USB.

[Miska]

11 hours ago, Outlaw said:

Trying NAA on a Rasberry PI3.All I can get is PCM which plays slow and crackling.No DSD at all ? Any ideas

 

Forget using USB on RPi3. They cut a bit too many corners on the hardware design and USB is losing packets because ethernet shares the same USB bus as the Type-A connectors and the CPU doesn't manage.

 

RPi4 is first RasPi with usable USB when Ethernet is in use.