HQPlayer Linux Desktop and HQplayer embedded

[Miska]

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.

[Miska]

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?

[Miska]

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

[Miska]

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.

[Miska]

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.

[Miska]

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

 

Yes, there's a built-in set of supported/advertised mime types and then there can be additional ones described in the config. In most cases those additionals ones don't have effect else except maybe the audio/ogg one (for FLAC-in-Ogg-container).

[Miska]

Jussi, can you educate those of us who don't know exactly what mimes do, esp those you included?

 

MIME types specify different kinds of media types, explained here:

https://en.wikipedia.org/wiki/Media_type

 

UPnP devices and generally everything based on HTTP use these to describe content types being supported or transferred. For example a web server can tell that "this data is now going to be a JPEG image" when it starts sending an image file as response to GET-request from a browser. Similarly UPnP devices advertise that they support certain media formats using MIME types as well as servers describe the content they are going to send (in response to GET request from a renderer) using the same.

 

So how it roughly works in simplified way when you want to play a track:

1) Control point figures out what content Servers have and what Renderers there are and what each party supports

2) Control Point tells Renderer to start playing URI "http://myserver/sometrack.flac" where "myserver" refers to a certain Server

3) Renderer asks server to send "http://myserver/sometrack.flac"

4) Server tells the content is going to be of type "audio/flac" and starts sending the sometrack.flac file

5) Renderer happily plays content from the server, reporting playback status/position back to the Control Point

 

Note that the ".flac" suffix could be omitted, because the MIME type already describes the content type, so in some cases instead of "sometrack.flac" there's just random generated long hex number.

[Miska]

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

 

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.

[Miska]

Is your modified kernel available for download?

 

Yes, at the usual place:

https://www.sonarnerd.net/src/xenial/

[Miska]

One thing that appears to have been overlooked so far in this excercise is gapless support.

 

Doesn't really matter whether there is SetNextAVTransportURI or not, hqplayerd tries to be gapless in all cases...

 

However, of course, in most cases when source format changes it however won't be gapless, because the DSP engine needs to be reinitialized.

[Miska]

Sure, but in the specific case using hqplayerd with JRiver via UPnP/DLNA as outlined by the OP, it's a slave to the interaction between JRiver's control point and Rygel, which can only deal with individual file tracks.

 

Yeah, but it doesn't matter...

 

hqplayerd doesn't need SetNextAVTransportURI to be gapless.

[Miska]

How does that work, gven that Rigel can't provide hqplayerd with the entire playlist via MPRIS, only individual file track URIs one after the other (so the next track to play URI only after the last track has been played, in the case of no SetNextAVTransportURI support), when controlled by a standard UPnP/DLNA control point such as JRiver's?

 

It just works!

 

MPRIS itself has a full playlist/tracklist control capability. But I could of course create a separate hqplayerd-specific plugin for Rygel too, one that would use the "native" HQPlayer control API now with HQPlayer Embedded 4.x. This is quite nice and easy, because Rygel itself doesn't really have any media playback engine of it's own. It can use various external ones, like gstreamer playbin, or any other MPRIS compliant player (VLC, etc). From practical point of view it wouldn't make any difference though, apart from being able to run Rygel and HQPlayer in different computers and possibility to use HQPlayer Desktop too for UPnP and not just HQPlayer Embedded. So one could run Rygel on Linux and HQPlayer Desktop on Windows and have UPnP Renderer capability still. Maybe I'll do it just for the sake of doing it for fun.

[Miska]

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?

 

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.

[Miska]

Strange that the Win 10 NAA and the Linux microRendu both are involved in the craclking at stop. My crackling is a unique sound in that it is left, right, left, right. left then stops (or basically that). It's not like a dropout or format thump..

 

Just to make sure, do you have networkaudiod-3.4.2 on all these, or something else? What DACs are used in these cases?

[Miska]

NAA reports back "ALSA DSD not supported"

 

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

[Miska]

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.

 

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

 

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

 

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

[Miska]

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.

 

Well, that message can only come from Linux based NAA or Linux based HQPlayer Desktop because it is from the ALSA backend. And it is printed out if the driver reports that there is no native DSD support and you don't have DoP enabled for the backend in question. Completely normal for PCM-only output case.

 

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.

 

All versions are in the same place...

[Miska]

I never use DoP, so the crackle is not related to that. BTW, I ran with my Windows NAA yesterday (Holo ASIO driver) and the stop-crackles still exist. When I rebooted out of Linux back to my Win 10 server (and no UPnP, etc) of course the stop-crackles stopped.

 

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

[Miska]

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.

 

Yes, of course you get it as long as you use NAA and NAA is Linux-based... What matters is where the audio drivers are.

 

Let me know if my settings is wrong for DoP in desktop and the log entry from Linux NAA.

 

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?

 

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.

 

Older versions are under Trusty. But 3.4.0 is oldest because my server's HDD broke down at that point...

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

 

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

[Miska]

A13 still has the crackle issue when stopping dsd playback

 

OK, then I cannot do anything until I can somehow reproduce it. I've tried it with all kinds of different setups and I don't get anything strange. I also tested with microRendu + iFi iDSD Nano and it works perfectly fine.

[Miska]

Are you getting DSD512 with T+A in Linux, like microRendu?

 

No, that's why I have a fanless Win10 machine as a NAA...

[Miska]

Jussi, not to be redundant but the stop-crackle is only with hqplayerd acting as renderer. I don't get it when simple desktop to mRendu NAA.

 

Yes, I understood, but I don't manage to get it with anything I've tested so far...

[Miska]

Then what is the significance of your screenshot showing Amanero rates when referencing ALSA?

 

That is from my DSC1 DAC which works up to DSD256 with this firmware (beta), without DoP. DSD512 is not proper yet that firmware version.

 

T+A DAC8 DSD doesn't have plain Amanero Combo384 board, but instead it has T+A's board design that sit right on the same board with the other stuff...

[Miska]

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.

 

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.