HQPlayer Linux Desktop and HQplayer embedded

[shadowlight]

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.

[shadowlight]

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.

[shadowlight]

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

[shadowlight]

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.

[shadowlight]

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]

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

[shadowlight]

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

[shadowlight]

I will take screen shots of my settings tonight. I only tested dsd last night and wI'll test pcm also tonight.

[shadowlight]

I also need to check the settings for minimserver to see why dff files are not playing for me. I was able to play them using hqp-control command just fine.

[shadowlight]

The mime config is default from what HQPe includes in the example file. I had no problem when I removed those lines.

[shadowlight]

JRiver Configuration which works both for PCM (tested only redbook and 96K files) and DSD64 (dsf files only). HQPe config file was the auto and sdm version uploaded couple of days ago.

 

 

 

I can confirm that if you stop playing DSD in middle you get the 5/6 second of crackled. I am also seeing similar behavior with BubbleUPnP playing from Minimserver.

@Miska, what could I look for in the logs to identify the reason behind dff files not playing when sent using http uri? I tried playing dff files using both JRiver and BubbleUPnP setup and both fail to play, while adding the same file using hqp-control command everything works correctly.

[shadowlight]

Logs generated during playback of dff files. The first one was issued with hqp-control using the Minimserver location URI, the 2nd section was generated why playing back the same file using locally mount URI which worked and the 3rd was sent via BubbleUPnP.

logs4dff_playback.txt

The crackle sound that you get when you stop DSD playback can also be replicated using the hqp-control localhost --stop command.

 

For me personally the issue of fixing crackle is higher priority over addressing the issue of not being able to play dff files. The only dff files that I have are the sample files that I had downloaded from 2l.no website but for other folks it might be a big issue.

[shadowlight]

I will build lts tonight to test. Is your modified kernel available for download? Also, just to make sure can you let me know how to install and what changes I need to make to grub file to leverage that. Could be he issue that both Ted and I have be related to us streaming to NAA. I am using win10 version and I believe Ted is using uRendu. Is a modified kernel available for stretch?

[shadowlight]

Strange that I don't get such at all... DAC I use on my desktop for testing this is iFi iDSD Micro BL with closed Shure SRH1540 headphones. Ubuntu 16.04 LTS with my slightly customized kernel build.

 

Sorry, I am still getting the crackle when I stop playing DSD files with base Ubuntu Server Xenial install with kernel 4.8.0-39. I have not tested with your kernel but that should not make any difference correct. I am streaming to Win10 based NAA which I do not believe is something that you are doing. Could the issue that I am having be related to communication between embedded version and NAA?

[shadowlight]

Ahh, OK, then the OS where HQPlayer runs doesn't matter, only the OS/driver where NAA runs. I have Win10 based NAA connected to a T+A DAC8 DSD, that one doesn't crackle though.

 

Strange I do not get the crackle if I use Linux version of the desktop HQP on the same server that I am running embedded on. Any recommendation on how to troubleshoot the issue with the embedded version? My crackle is similar to what Ted described. I believe Ted is using XMOS based DAC, while I am using Amanero similar to your T+A.

[shadowlight]

NAA 3.4.2 with Amanero based Lampizator B7 on my end.

[shadowlight]

Just tried to run NAA on both Debian and rpi3 with Miska image and NAA reports back "ALSA DSD not supported" on a DAC with Amanero. Is there any specific settings that needs to be enabled for Linux NAA. I do not remember setting anything like that before.

 

Edit: I tested with DoP setting on and off.

[shadowlight]

That means the driver doesn't support raw DSD for this device and DoP is not selected, so there's no DSD support available.

Ran some more tests tonight.

 

Hooked up the dac directly to HQPlayer Embedded server and in the logs I see "ALSA output DSD using DoP" in the hqplayerd.log file and I am able to play DSD files no issues. Than I hooked up the DAC to the Linux NAA with exact same kernel and alsa libraries and it is back to reporting DSD not supported messages. The only change that I made to the hqplayerd.xml file was output type from alsa to network.

 

I also got the crackle when I stopped DSD playback mid stream while directly hooked up to HQPe server.

[shadowlight]

Note that the "sdm_pack" setting is per backend, so it is separate for "network" and "alsa"...

OK, but in this case you should try with my kernel so that the environment is comparable... Anyway, I need to be able to reproduce it somehow to do something about it... But it may be related to DoP. So far I haven't been using DoP...

 

I will double check the settings tonight. Here is another data point in case that makes a difference. I was getting the same "ALSA DSD not supported" message with desktop version of HQP both under Linux and Windows. I even went back to couple of versions back on the Windows desktop version to just confirm. The one thing that I am not able to test/confirm is rolling back Linux NAA to version from about year ago when I switched over to the Windows due to the loud pop that I used to get with Linux.

 

So Miska if you could point me to a location on your site where older version of Linux NAA might be held, I can test and report back to see if NAA switch helps.

[shadowlight]

Shooting in the dark, but I made some small fixes to the only place in the code that is different between Desktop and Embedded. Now there's a13 version out...

Ok, will download and test a13 but I am getting the same message with HQP Desktop both on Linux and Windows version 3.15.1.

Let me know if my settings is wrong for DoP in desktop and the log entry from Linux NAA. I am also unable to find the older version of NAA - https://www.signalyst.eu/bins/naa/linux/xenial/. The only version I see there is 3.4.2-33.

 

naa.txt

[shadowlight]

Settings are correct, but the NAA seems to be completely nuts, the listed DSD rates don't make any sense. Are you running NAA on Xenial?

 

Yes, running on Xenial with 4.8.0-39-lowlatency kernel. I am going to install your modified kernel and see how it goes.

[shadowlight]

@Miska,

 

No luck with a13 or your custom kernel running on naa. I still get ALSA DSD not supported and the crazy DSD supported format.

[shadowlight]

A13 still has the crackle issue when stopping dsd playback

[shadowlight]

Yes, the "ALSA DSD not supported" is normal message you will see as long as you don't have Amanero firmware version that would be supported by the kernel for non-DoP DSD.

Here's my output for Amanero, but my Amanero has the 1099 firmware...

I fully understand that I will see ALSA DSD not supported if I am trying to stream native DSD, but I had the DoP settings in place for HQP Desktop and I am still getting that. As for the crackle is there anything on my end that I can do that would potential help you narrow down the issue?

[shadowlight]

That is normal for NAA system. I have released networkaudiod 3.5.0 with a fix that will hopefully clean up the bogus DSD rates too.

With 3.5.0 the crazy DSD rates are gone but the "ALSA DSD not supported" message still exists even if I have DoP set, along with setting that says up convert everything to SDM it seems to be streaming PCM