HQPlayer Linux Desktop and HQplayer embedded

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

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.

So am currently running a12 embedded, with microRendu as NAA, JRiver using Minimserver as library, JRemote as my control point. Auto family is on, as is auto mode. 352k max. So all PCM should be either 352k for 44k based stuff or 192k for 48k based stuff. Nope. I played 24/192 source material and it came out 96k!!? I played 96k or 48k stuff and it came out 192k! Almost like it wouldn't play 192k at 192k cuz it had to do somethin! Kidding, but weird. I turned off auto family and same occurred, which is even weirder (expected it to go to 352k).

 

I went to 384k as my max PCM output, back to engine auto family enabled and now everything plays fine (44k to 352.8k, 48k to 384k).

 

P.S. I still have the mime stuff left in there from shadowlight's template above; I may delete that and see what happens.

 

<mime>

<type value="audio/ogg"/>

<type value="audio/vnd.wave"/>

<type value="audio/L24"/>

</mime>

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

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

Yes, sorry. I forgot that when Rygel is used as a 'UPnP/DLNA renderer', it can be used just as a UPnP renderer front end/interface to an external player, so shouldn't have implied any actual streaming involvement. Looks like you are using Rygel's MPRIS plugin to get it to control HQPlayer Embedded, looking back on your previous posts on the subject.

 

Indeed, MinimServer first requires its optional MinimStreamer transcoder component to be installed & then configured with the appropriate settings in its stream.transcode property, for any transcoding (so including DSD files to dopwav) to occour.

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

Having mentioned in my last post how obvious it is to tell whether MinimServer's transcoder is being used or not, JRiver is a bit more cryptic to say the least!

 

If you don't want any transcoding to occour, you must set the relevant DLNA Server's Audio Mode to "Original". Any setting in Audio Format (the transcode to headerless LPCM or WAV or MP3 setting) is then ignored as it's irrelevant. Also, make sure the "Bitstream DSD (requires DoPE compliant renderer)" tick box in Advanced isn't set - otherwise the DSD file transcoding to DoP in WAV will engage.

 

Setting the DLNA Server's Audio Mode to "Specified output format" will always transcode all audio files (so including DSD files) to either a headerless LPCM stream or a WAV file or an MP3 file, depending on the format that's been set in Audio Format.

 

I believe the "Specified output format only when necessary" Audio Mode is supposed to use the original file if the device advertises support for the format and transcode otherwise. Probably wise to stay clear of this, unless you've tested it thoroughly with the renderer(s), control point(s) and file formats you want to use it with!

So far, with JRIver as the DLNA server, Minimserver as JRIver's library, no Minimstreamer installed, and hqplayerd auto family and auto mode on (384k and DSD512 max) I ran, with JRemote as control point, all four different combinations (JRiver DLNA mode "original" or "specified output format" and DLNA Advanced->bitstream on or off) the results were identical. In all four scenarios PCM and DSD played properly and at the correct max family rate, and in all four scenarios upon hitting "stop" on JRemote any DSD crackled in each channel (back and forth) for 5 seconds as the stream stopped.

 

So I concur that no Dop-as-wav is happening, whether DLNA bitstreaming is set or not, as Jussi says embedded will not like that and likely provide hiss or nothing. It's almost like Minimserver is more than the library, but also the DLNA server.

 

I will try same as above except JRiver's own library loaded. But it's 74 degrees here in N. Ohio, and sunny, so going to hit some balls at the range first.

Ted

 

Using MinimServer as JRiver's library on JRiver's user interface (or remote controlling the UI via JRemote) IS using MinimServer as the UPnP/DLNA media server - JRiver's own DLNA server settings don't get involved in the mix, hence why there's no difference in adjusting those settings.

 

All you are doing with JRiver in this case as far as UPnP/DLNA is concerned is using its built-in (hidden) UPnP/DLNA controller (and not any of its DLNA servers) to control the UPnP renderer, streaming files from MinimServer!

Thanks, make sense but JRiver does not make that very clear at all!

 

End result is good, though, as it allows me to use my fave remote with my fave upsampling engine. Even custom views are allowed and saved to JRemote (a nice feature).

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

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

 

 

Sent from my iPhone using Computer Audiophile

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.

That was great, thanks. So what are these that you decided to include in the example config file (I assume ogg is an ogg vorbis container). What is vnd or L24 that they made the short list:

<mime>

<type value="audio/ogg"/>

<type value="audio/vnd.wave"/>

<type value="audio/L24"/>

</mime>

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.

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.

Yeah just use Jussi"s dff2dsf utility. Mostly header info changed; takes seconds.

 

 

Sent from my iPad using Computer Audiophile

Thanks, make sense but JRiver does not make that very clear at all!

 

End result is good, though, as it allows me to use my fave remote with my fave upsampling engine. Even custom views are allowed and saved to JRemote (a nice feature).

True, it is difficult to see what's going on with UPnP/DLNA in JRiver. Just to prove a point, the MinimServer as the Music Library setup should still work if you deselect the "DLNA Server" & "DLNA Renderer" tick boxes (keeping the "DLNA controller" selected) in Media Network>Advanced.

 

Thinking about it, the UPnP/DLNA controller is the user interface, so is supposed to be the place to access playlists, custom views, etc. Excellent that JRiver have allowed most of their UI features to be used with their UPnP/DLNA controller engaged.

 

However, must stress again that none of the JRiver's audio output settings will be used (ie, including upsampling) for the UPnP renderer, unless you select the appropriate JRiver DLNA Server (set with whatever transcoding feature you require, so engaging JRiver's audio output engine for upsampling, DSP, etc), as the Music Library.

Got it thanks. And yes, when selecting JRIver's own library (and therefore JRiver's DLNA server settings) it now plays fine with shadowlight's screen shot settings, as also per your comments. Not sure the sq is affected (I do not have JRiver ever touch upsampling, DSP, etc) with either. That will take more a/b'ing, likely a moot point with embedded and NAA being isolating steps.

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.

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?

Is your modified kernel available for download?

 

Yes, at the usual place:

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

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

 

JRiver's built-in UPnP/DLNA controller, in common with other gapless supporting UPnP control points, uses the SetNextAVTransportURI action with gapless supporting UPnP renderers. A quick google search suggests that Rygel has some support for SetNextAVTransportURI, but I'm not sure if that implementation extends to the MPRIS plugin which controls hqplayerd.

 

If it doesn't work, then you are going to have to rely on speed of the JRiver UPnP/DLNA control point telling Rygel to play the next track after it detects the current track has finished playing, thus making 'pseudo gapless' a bit of a gamble.

 

Incidentally, if Rygel does indeed report to the JRiver's UPnP/DLNA controller that it supports the SetNextAVTransportURI action, but you find that gapless is not working with it, you should set the renderer's "Disable SetNext Support (for broken renderers)" in its "DLNA Controller Options", to disable SetNextAVTransportURI and give the pseudo gapless scenario a chance to work.

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.

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.

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.