HQPlayer Linux Desktop and HQplayer embedded

I am a long time user (and BIG proponent) of HQPlayer. I find it to be the best upsampling engine going.

 

I have been saying for some time that a combination of using JRemote as a control point or remote, into HQPlayer, would be the best of both worlds, as I spent quite a bit of time getting JRIver to be a very friendly GUI. Since Jussi's Linux product called HQplayer embedded (or hqplayerd for short) can be a renderer, I thought I would begin a new thread about how this new world seems to me. I am a Linux idiot. (Note: CA forum member shadowlight is not a Linux idiot; he has generously helped me try to get acquainted with Linux and hqplayerd. I huge thanks to him).

 

One thing about Linux: it is many things. Some use Debian, some Ubuntu, and others a host of different forms of Linux. Before I settle on one version I thought I would take up shadowlight's recommednation to install a full plug-n-play version called Audiolinux. It resides on a 32GB bootable USB stick, plugged into a USB2 port on my HQP server (Windows 10, i7 6700k, 32GB, Nvidia cuda support, etc). Simply reboot the machine with USB inserted....Audiolinux comes up. Remove and reboot and I get Winwods 10 back. Pretty simple first step into the world of Linux audio.

 

The "regular" HQplayer that many of us use is called HQPlayer Desktop, and Audiolinux has one of those too (as well as MPD, JRIver, Roon, and many other audio products). So this thread's beginnings is to unclutter the normal HQPlayer thread and focus on hqplayerd and how, as a lInux newbie, I see it differing from the HQP desktop. The two products are never run together.

 

I am running HQPlayer desktop version 3.15 and running hqplayerd at version 4.0.a8; version alpha 9 and 10 have been tested but we were having NAA problems so I downgraded to A8. Now A11 is out there and Piero, the owner of AudioLinux, has graciously put it up, but I am using generous shadowlight's offer to play guinea pig first

 

OK, first off hqplayerd does not yet support cuda offloading, so I turned that off in Linux desktop too, to try and compare results (smooth playback and sq differences, if needed). Also, hqplayerd is command line driven so I am using cheat sheets from shadowlight to start, stop and change settings, and I admit ALL of my issues could be user error. Additionally, hqplayerd A8 does not support "auto" format switching (SDM vs PCM) so I edit the config XML and restart hqplayerd to accommodate (again, this is all in testing..I can't live this way).

 

On first tests I am finding that HQPlayer desktop on Linux acts and sounds virtually identical to my Windows 10 version, and seems to have the same limitations (i.e virtually none, although have not tested with multichannel yet, and I will assume that cuda offloading will need to be turned on then).

 

HQplayerd is being played from a Minimserver server and a couple of control points, BubbleUPnP and Kinsky (Kazoo requires OpenHome, and although I have created an OpneHome version of hqplayerd renderer Kazoo sees it but doesn't play. No big deal). As long as I play PCM in PCM (to 352.8k) or DSD in DSD (DSD512) the playback is fine. However, hqplayerd hiccups pretty significantly when trying to play PCM in DSD512 (haven't changed bitrates yet), regardless of the filter I think I am using (I say "I think" cuz I am not fluent yet in understanding the filter numbering in the XML files).

 

Note: I've tried using jRIver and JRemote (from my home office Windows desktop setup) but gotten poor and unusable results (best case horrible hiccuping, worst case silence), but shadowlight reports it does work, so that, my ultimate goal, is still on hold.

 

Here is my Linux desktop settings window, and then the XML driving hqplayerd (with upsampling filter set to 11, which I think is poly-sinc-mp-2s, set in order to reduce hiccupping but to no avail yet)

 

These screenshots are from a desktop remote called NoMachine, which is pretty good!

 

Thx Ted for starting the thread.

 

I installed HQP Desktop on the same system last night so I can compare settings between desktop and embedded and playback functionality and will not be comparing the sound quality between various settings. I will leave that up to folks who have better hearing than me :-). I will report back my findings (hopefully I will get a chance to do that tonight). I will also install JRiver on the same system to use so I can send music over to embedded version using JRemote/eOS.

 

I did run couple of tests last night with a11 and can confirm that a11 can communicate with NAA the same way that a8 is able to do.

 

My setup for the test is going to be -

 

Debian Stretch - Updated to the latest patches/kernel

Mount Music from Windows 2008 R2 Share under Debian

MinimServer - pointing to the Windows share mount point

JRiver 20.x - leveraging the same Windows share mount point and setup to stream via DLNA/UPnP

BubbleUPnP - To stream music from MinimServer

eos / JRemote- To control JRiver setup

 

I will use 1 of each format redbook, pcm 48, pcm96, dsd64 and dsd128 to run the test. The PCM96/DSD64/DSD128 ones will be the from 2nl free download sites. HQP will be configured to most likely to poly-sinc-mp for PCM conversion to 384000 and SDM DSD256 with SDM modulator set to ASDM7 in desktop, with initial test using auto settings and next everything converted to DSD256 which is all my DAC can support right now.

 

The plan is to get everything working with Desktop and use the same file with modification for embedded to send output to network and mode either set to auto or SDM. My normal listening is everything converted to SDM.

Network on a11 working fine for me. I don't use auto so not sure on that note. But no more "no suitable output for 44100" errors. I have some other issues with embedded I'm trying to run down (Roon playlists stall on sample rate changes) so if anyone else happens to experience that, I would be keen to hear about it.

Thanks. Keep the embedded comments coming, whether you are comparing to another setup or not.

 

I'm keen on knowing whether A11

1) supports NAA. We have 2 yeses and one no.

2) supports "auto" format changes

3) works with JRIver UPnP (no idea why my JRiver does not work and therefore whether it is at all related to hqplayerd versioning).

Regarding filters it looks like you've perhaps conflated the variables "oversampling" (applies to SDM) and "filter" (applies to PCM). I did the same getting set up.

 

/usr/share/doc/hqplayerd/readme.txt.gz should explain all.

 

Basically, according to the screenshot you've set SDM oversampling to Extended Polyphase (oversampling="11") and PCM filter to "Fast roll-off minimum-phase polyphase" (filter="7"). Setting oversampling to 7 would be poly-sinc-mp-2s for SDM.

 

BTW my issues with track advance aside, Auto SDM works a treat in a11.

 

Looking forward to the results of the tests, @shadowlight !

Thanks!! Where in the XML is the mode attribute for auto? Simply should I, if using a11, enter "auto" for mode value, as opposed to sdm or pcm?

 

BTW, changing upsampling filter to what I intended, which is now 7 (doh!) resolved the PCM to DSD512 issues. No more hiccups. Thx

For some context, in the short time I've been playing with HQPlayer Embedded I've experimented with the following setups:

 

1) Local playback using minimserver and UPPlay (a bare bones UPNP/OpenHome control point for the linux desktop) .. Doesn't really have a big advantage over running HQPlayer Desktop... but it proved the possibility so I kept trying various approaches

 

2) Emulating OpenHome with BubbleUp Server on Linux (+ minimserver, Embedded and Rygel) . This worked beautifully upsampling Tidal with the Lumin app. I should have stopped there but I can't help myself. Local playback was too glitchy.

 

3) HQPlayer Embedded + Rygel with BubbleUPnP control point. Besides Roon, this was the closest thing to a truly workable setup ... but I cheaped out on the Android tablet and it wasn't up to the task. I may revisit this one. With the cost of Roon I could have justified a much bigger expenditure on the tablet, but the fancy interface and metadata seduced me. (And I already own an Air 2 which makes for a quite slick experience in Roon.)

 

4) Roon + HQPlayer Embedded. This is what I'm using now and is the closest to the perfcet combination of a polished UI + pure audio nerdery that HQPlayer offers.

 

I also did a bit of experimentation with JRiver because their remote is still one of the best thought out offerings, and I include Roon in that. I got as far as being able to trigger playback of HQPlayer embedded through JRiver's DLNA system, but any further interaction was impossible. Based on some of the leads I'm seeing here I may revisit that too.

I also did a bit of experimentation with JRiver because their remote is still one of the best thought out offerings, and I include Roon in that. I got as far as being able to trigger playback of HQPlayer embedded through JRiver's DLNA system, but any further interaction was impossible. Based on some of the leads I'm seeing here I may revisit that too.

 

What was the issue that you ran into with JRiver DLNA setup so I can be on the look out for the same issues.

What was the issue that you ran into with JRiver DLNA setup so I can be on the look out for the same issues.

I don't currently have Rygel and the associated stuff set up as I'm using Roon, but I may revisit and report back in more detail.

 

Basically with minimserver as my library in JRiver and a generic UpNP / DLNA setup, I was able to trigger playback in HQPlayer Embedded (I think t his was a5 or a6 mind you) but it would freeze the Media Center interface. JRiver was throwing an error saying what I was trying to do was not possible, and yet it was happening in the background If you clicked "OK" to the error, playback would stop.

 

Sorry this isn't of much help. Honestly, I got frustrated with the JRiver approach to linux (and audiophile playback in general) after having to ask a simple yes/no question about DoP playback multiple times over a month+ just to get a simple "no".

Ted, I am very glad that you opened this thread where we can gather various information regarding Embedded.

 

At the moment I am not running NAA, but Piero of AudioLinux (hifi25nl) has confirmed me that A11 works with it. Hopefully, he will intervene here too.

 

Furthermore, we at NextHardware are going to start integrating Logitech Media Server (LMS) with HQP Desktop/Embedded. Work has started alrady, but SoX integration has taken priority.

It will be an alternative to Roon and MinimServer and it will have an interface to change HQP setting.

Thanks!! Where in the XML is the mode attribute for auto? Simply should I, if using a11, enter "auto" for mode value, as opposed to sdm or pcm?

 

Note, the "defaults" element defines default values and the rate settings there are the upper limits, exactly same stuff that is shown in the HQPlayer Settings -dialog. For 48x512 DSD rate, you can set the limit to 24.576 MHz and possibly have auto_family="1".

 

There are for example two additional lines that are missing from your configuration file that essentially control what can be found from HQPlayer main window:

<pcm filter="9" dither="5" samplerate="0"/>
<sdm oversampling="9" modulator="6" bitrate="0"/>

These define the settings for PCM and SDM output modes. Note the "0" rate here means "Auto". The mode itself is controlled by the "mode" element.

 

In a11/a12 I have included a new example configuration file, installed as /etc/hqplayer/hqplayerd.xml if the original one is not modified, and if it has been then the package installation will ask what to do about the file. It is almost direct copy of the configuration I have in one of my servers with iFi iDAC2 connected.

Results from my testing session tonight with alpha 12.

Now for the Good News:

1) Connectivity to NAA functions the same way as it works with desktop version and alpha8.

 

2) Auto rate worked perfectly for me and it switched with out any issues between DSD64, PCM96 and redbook. Both redbook and PCM96 was upconverted to 384K, while DSD64 was upconverted to 11289600.

 

3) I was able to play PCM files using JRemote/EOS

4) Using BubbleUPnP I was able to play all files the same files with out any issues.

Now for the bad news:

1) I could not get JRiver to work with DSD files with the bitstream setting in place. All I got was hiss, if I disabled the bitstream setting I was able to play the files but I think they might have been converted to PCM before being sent to HQPE. The problem was that I got crackle and pop when I stopped playing the DSD file. I will have to revisit this over the weekend.

2) This one is for @Miska. I had problems playing dff files with embedded but no issues playing the same file using Linux 3.15 latest beta on the same system. I tried both 64 and 128 DSD files with same results. I even went back all the way to 3.14 version of embedded and that had similar issues. It would crackel and pop going from speaker to speaker for about 10 seconds or so and than it will be silent.

 

I also, created two files using the desktop versions one which was setup for everything to play based on auto mode, while the second was configured to upconvert everything to DSD256. To test what I would do was change the pointer for hqplayerd.xml file to point to the configuration that I wanted to test. The command that I used was "ln" in the user's .hqplayer directory. Attaching copy of the two files that I used for testing. If you see anything that can be optimized please let me know.

 

ln HQPlayer-Auto-20170222.xml hqplayerd.xml

 

HQPlayer-SDM-20170222.xml.txt

HQPlayer-Auto-20170222.xml.txt

1) I could not get JRiver to work with DSD files with the bitstream setting in place. All I got was hiss, if I disabled the bitstream setting I was able to play the files but I think they might have been converted to PCM before being sent to HQPE. The problem was that I got crackle and pop when I stopped playing the DSD file. I will have to revisit this over the weekend.

 

It would be good to know what MIME type it is trying to send. Last time I tried it worked from MinimServer.

 

These are the advertised types: audio/x-dff, audio/x-dsdiff, application/x-dff

IIRC, MinimServer sends this: application/octet-stream

 

With MinimServer it works because the URI contains filename that ends with .dff which is also detected.

 

2) This one is for @Miska. I had problems playing dff files with embedded but no issues playing the same file using Linux 3.15 latest beta on the same system. I tried both 64 and 128 DSD files with same results. I even went back all the way to 3.14 version of embedded and that had similar issues. It would crackel and pop going from speaker to speaker for about 10 seconds or so and than it will be silent.

 

How do you test this? Log file could help, because it is working fine for me, for with direct_sdm="0" and direct_sdm="1". I just use hqp-control to add a .dff file and then start playback.

 

It is especially strange because all the player code for 3.14 is the same between desktop and embedded versions. Are you running both versions the same way as same userid?

I will generate the logs needed when I get home tonight for both the JRiver issue and dff file issue.

 

I am also going to recheck all the DSD settings in JRiver to make sure that I did not miss any settings based on JRiver DSD Wiki. I am not sure if I need to enable bitstreaming settings under audio to send the stream to HQPe. For DSD to DLNA render JRiver sends the stream as DoPE (DSD over DLNA) and requires a compliant renderer. Not sure if rygel is such support for that.

Jussi, you use Minimserver rather than JRIver's own library? I might try that too.

 

I ran a12 this morning and report back that auto format changes (mode=auto) working fine, as is DirectSDM. Note: I tried Direct SDM only because I was worried about Minimserver sending PCM instead of DSD. Why? Cuz the only times I've ever used Minimserver was with my former Signature Rendu, and it required Minimstreamer and setting DFF:dopwav, dsf:dopwav. Therefore I was worried that Minimserver does not really serve up direct non-DoP DSD files, and setting auto for everything in hqplaerd does not give me enough information about what is being sent to the dac (although upon further thinking I guess it would have shown a PCM playback or garbage if my theory was right). I now know that this Minimstreamer setting stuff was just for renderers that only do DoP.

 

I will try JRIver and its library, through JRemote, next.

 

By the way, using Minimserver and BubbleUPnP I get crackles when transitioning from one DSDtrack to another, even the same bitrate, (unless within the same album brought over to the playlist togther) and then crackles for 5 seconds once I hit the stop button in the control point.

Dusted off JRemote and tried it once again, using hqplayerd. As shadowlight reported the PCM playback was fine but once I went to DSD the dac showed PCM rates and played hiss or warbly garbage, I tried various JRiver DLNA settings to no avail.

 

I then switched libraries to Minimserver, and although was working with a small subset (since it takes awhile to load and I was in a hurry to test) any sample DSD file played just fine. ??

 

Another nice by-product is there are no track transition clicks or bumps during auto DSD512, except the pop when starting the first DSD track after PCM. And since, during this test I also tried DirectSDM I know that JRIver is not converting to PCM, otherwise hqplayerd would send PCM to my dac (unless it's then converted to DSD but that would assume DSD64, not also DSD128 and 256 per file origin).

For DSD to DLNA render JRiver sends the stream as DoPE (DSD over DLNA) and requires a compliant renderer. Not sure if rygel is such support for that.

DoPE is a term coined by JRiver and has nothing officially to do with DLNA. DoPE was originally used by JRiver to mean "DSD over PCM Ethernet", ie, "DoP Ethernet". JRiver's DoPE is actually a 24-bit WAV file containing DoP, so is exactly the same as MinimServer's dopwav. For some odd reason, JRiver seem to have dropped their old "DoP Ethernet" definition in favour of "DSD over DLNA", so adding to the confusion IMO.

 

If rygel is able to stream MinimServer's dopwav files, there should be no reason why it shouldn't stream JRiver's DoPE files.

DoPE is a term coined by JRiver and has nothing officially to do with DLNA. DoPE was originally used by JRiver to mean "DSD over PCM Ethernet", ie, "DoP Ethernet". JRiver's DoPE is actually a 24-bit WAV file containing DoP, so is exactly the same as MinimServer's dopwav. For some odd reason, JRiver seem to have dropped their old "DoP Ethernet" definition in favour of "DSD over DLNA", so adding to the confusion IMO.

If rygel is able to stream MinimServer's dopwav files, there should be no reason why it shouldn't stream JRiver's DoPE files.

 

Thanks for the information Cebolla. That helps and hopefully I can collect some logs most likely tomorrow and send it along for review. I think my current JRiver configuration is setup to send headers to DLNA, I will see what happens if I change it to not send headers next time when I test.

Shadowlight, your dac requires DoP, right? So we are testing different results then. I do not have Minimserver creating dopwav files and I still get DSD fine.

Nope, I have the R2R board in the Lampi DAC so do not need DoP.

If rygel is able to stream MinimServer's dopwav files, there should be no reason why it shouldn't stream JRiver's DoPE files.

 

Rygel is not involved in streaming at all, it just handles control.

 

HQPlayer wants plain DSD files, either DSF or DSDIFF (or plain raw in HQPlayer specific way). Not any DoP stuff. Any DSD hidden in DoP ends up treated as PCM and of course results in hiss when it goes through the DSP engine as "PCM".

 

MinimServer however by default sends DSD files as-is, not as DoP. At least the version I've been using...

Shadowlight, your dac requires DoP, right? So we are testing different results then. I do not have Minimserver creating dopwav files and I still get DSD fine.

 

HQPlayer will handle DoP at the output side if/when necessary. There shouldn't be any DoP stuff involved at input side, only plain PCM or plain DSD.

Jussi, you use Minimserver rather than JRIver's own library?

 

I've never touched JRiver. I have MinimServer and control playback from BubbleUPnP Android-app. I have also Rygel based media server, but it doesn't recognize DSD files and I haven't bothered to investigate how much work it would take to add that support. Although I could do that work if I manage to find time for it. This is nice in a way because same Rygel instance running on the same hardware can be both media server and also renderer with HQPlayer at the same time. It has quite OK content monitoring system, so you can copy files to the server over network and it'll automatically pick it up.

 

although upon further thinking I guess it would have shown a PCM playback or garbage if my theory was right

 

Yes, for DoP stuff you get just quiet hiss...

 

By the way, using Minimserver and BubbleUPnP I get crackles when transitioning from one DSDtrack to another, even the same bitrate, (unless within the same album brought over to the playlist togther) and then crackles for 5 seconds once I hit the stop button in the control point.

 

Hmmh, I need to check this, but shouldn't happen. I'm mostly testing with iFi DACs and those tend to be sensitive to crackling.

hqplayerd_jriver_dff.txt

 

As promised here are the logs with issues with JRiver and dff files played via BubbleUPnP.

 

I think I got DSD working with JRiver with out any crackle/hiss. I changed the DLNA setting to send the data without any headers and also disabled DoPE settings. Ted, can you try that and see if it works for you.

hqplayerd_dff.txt

OK, I went back to JRiver library. If I change DLNA setting to "L24 PCM no header" JRIver blows up. No DLNA whatsoever, even PCM. And no DSD. Again, with Minimserver as the library, all previous settings are fine, but with JRIver library as library, the no-header settings make things worse (i.e unusable).

 

If I set DLNA setting back to 24 bit PCM and simply turn off bitstream (requires DOPE capable renderer) then PCM plays ok but DSD plays back as PCM, poorly.

 

What, exactly, were your setting changes?