HQPlayer Linux Desktop and HQplayer embedded

[Cebolla]

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.

[Cebolla]

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.

[Cebolla]

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!

[Cebolla]

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!

[Cebolla]

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.

[Cebolla]

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.

[Cebolla]

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.

[Cebolla]

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?

[Cebolla]

On 10/23/2017 at 9:43 PM, shadowlight said:

 

Right now the Max Cache Size is set for 500MB and I am assuming that is the default since I have not changed that.  Can you let me know what benefit changing setting will have, and should I change it to higher or lower?

 

On 10/23/2017 at 9:52 PM, hifi25nl said:

The first time I used Bubble UPnP some time ago, I had to make the cache higher, otherwise I had a lot of dropouts and interruptions. I don't remember the exact value.

 

Isn't this setting for caching a connected UPnP/DLNA media server's files for the BubbleUPnP Android app's own internal/local player?

 

So has nothing to do with controlling a UPnP renderer on the network, let alone proxying a stream for it.

[Cebolla]

No point complicating matters with a high bit rate 320k BBC HLS AAC stream that isn't available outside the UK! Having said that, HLS AAC streams are actually supported by MinimServer and it should be able to transcode them to a 'normal' AAC stream (or WAV, etc) if required.

[Cebolla]

23 hours ago, cat6man said:

On 12/26/2017 at 7:35 PM, cat6man said:

Can anyone send me a working example of a *.m3u file that works to stream radio?

 

I use minimserver and have just added minimstreamer.

I created a file, wnyc.m3u that contains the following:

 

#EXTM3U
#EXTINF:-1,[WNYC-FM] WNYC-FM
http://www.wnyc.org/stream/wnyc-fm939/mp3.pls

 

when i click on this file on the ubuntu pc, it opens vlc and plays the stream.

i thought this was the proper file format but when i browse and select this in bubbleupnp, nothing plays?

 

anyone have this working or know what i missed?

not looking for anything hi-rez or complex (yet)

 

running config:

bubbleupnp client on android phone

minimserver, minimstreamer,  hqplayerd 4beta12 on ubuntu xenial

wired LAN

ultraRendu(NAA) to DAC

 

thanks

 

forgot to add that i set file format conversion in minimstreamer 

mp3:wav24

 

i'm guessing that there may be a rate conversion needed as well as a format conversion for hqp to be happy?

 

There's certainly no problem with that internet radio stream nor the way you've configured it for MinimServer as a radio station playlist file and its stream.transcode property set to mp3:wav24.

I can only comment about UPnP renderers in general, so not about Rygel -> MPRIS -> hqplayerd combo directly,  as I don't have them installed.

 

Given that, the most common issue would be for some UPnP renderers to require the audio file type to appear in the stream's URL as a suffix, otherwise it can't recognise it as a specific audio file type and therefore won't play it.

 

With your current settings, the radio stream is proxied by MinimServer/MinimStreamer to:

http://<MinimServer's host IP>:9790/minimstreamer/*/WNYC-FM

note: this is regardless as to whether you set all MP3 streams to transcode to WAV24 or not

 

To explicitly add the audio file type to the URL, you need to add the required audio file type as additional audio info in the radio station's playlist file. So as the WNYC-FM stream's format is mp3, the following audio info is required (in bold):

#EXTM3U
#EXTINF:-1,[WNYC-FM,mp3] WNYC-FM
http://www.wnyc.org/stream/wnyc-fm939/mp3.pls

 

This will proxy the stream to:

either http://<MinimServer's host IP>:9790/minimstreamer/*/WNYC-FM/$!stream.mp3

or http://<MinimServer's host IP>:9790/minimstreamer/*/WNYC-FM/$!transcode-24.wav

depending on whether the stream is in its native format or transcoded.

 

 

The other issue might be as you have suggested, the renderer requires the sample rate to be set to a known value, so that it is within a supported range. Your current stream.transcode property will use the sample rate of the original stream, which is 32kHz for the WNYC-FM mp3 stream. You can get the transcoder to resample this, to say a whole multiple, eg, 96kHz by adding the samplerate to the stream.transcode property (in bold):

mp3:wav24;96

 

This proxies the stream to:

http://<MinimServer's host IP>:9790/minimstreamer/*/WNYC-FM/$!transcode-24,96.wav

[Cebolla]

14 hours ago, Miska said:

HQPlayer primarily relies on MIME-type header and secondarily on suffix. But exactly is "wav24" supposed to output?

 

Is this supposed to be RIFF file?

 

Generally, for streaming, best lossless container is FLAC in OGG container...

 

The content type (with appropriate MIME-type) should be on all MinimServer/MinimStreamer's HTTP stream headers. Does the Rygel UPnP renderer (being used by hqplayerd as a front end), primarily rely on MIME-type and secondly on suffix, like HQPlayer?

 

According to the MinimStreamer user guide, wav24 is supposed to output:

"PCM audio encoded in 24-bit WAV format. For lossless 16-bit input streams (FLAC and ALAC), the audio samples are extended to 24 bits by padding each sample with zeros. For lossy input streams (AAC and MP3), a floating-point conversion is performed with full 24-bit precision."

"The original sample rate is preserved unchanged by default. For example, using the wav setting to transcode a FLAC file with a bit depth and sample rate combination of 16/44100 will produce a WAV audio format of 16/44100. Using the wav24 setting to transcode this file will produce a WAV audio format of 24/44100."

http://minimstreamer.com/userguide.html#Transcoding

 

 

Yes, that file is RIFF WAVE. Unfortunately, Ogg FLAC is not supported by many UPnP streamers, so I assume that's the reason for MinimServer's lowest common denominator WAV file output.

 

Incidentally, MinimServer/MinimStreamer can be used for the couple of handful of Ogg FLAC internet radio streams that are out there, though lossless output is WAV only. Most interestingly, the latest BBC radio MPEG-DASH experimental MP4 FLAC (as per FLAC v1.3.2) streams are fully supported and with this the output can be 'normal' FLAC as well as WAV.

[Cebolla]

No idea why you are fretting about the the UPnP control point app's volume control setting. As long as you haven't changed it on the UPnP control point app, it should just be reflecting the UPnP renderer volume's original position when the renderer first connects with control point.

 

May be it's due to some misunderstanding as to what a UPnP control point, like the one contained in the BubbleUPnP Android app, does:

3 hours ago, Em2016 said:

Also, I have Bubble UPnP (Tidal) on Android playing to HQP Embedded - but what does the volume in Bubble UPnP app mean in relation to HQP volume? What is the equivalent to HQP = -3dB?

 

UPnP control points do not play anything -  ie, it's HQP Embedded that does the playing!.

 

So if HQP Embedded is at -3dB on first connection, the BubbleUPnP Android app's  volume control position is also at -3dB.

 

If you are worried about accidentally moving the BubbleUPnP Android app's volume control, you can hide it in the app's settings.

 

[Cebolla]

On 9/28/2018 at 9:48 PM, cat6man said:

 

i only use a local NAS.  what is a reasonable gap size to expect with bubbleupnp?

would it be a function of track size or the time for the DAC to empty its buffer of the previous track?

 

is there a full featured client other than bubbleupnp that does a better job and is faster to trigger the next track?

 

The BubbleUPnP Android app should trigger the UPnP renderer to prepare the next track within a second or so of the start of the current track being played. This assumes the UPnP renderer it's controlling supports gapless playback, ie, via the SetNextAVTransportURI UPnP AVTransport Service action.

 

If gapless playback is not supported by the UPnP renderer, BubbleUPnP triggers the UPnP renderer to play the next track after the current track has finished playing.

[Cebolla]

8 hours ago, Em2016 said:

But I'm not 100% sure if shairport-sync may be doing anything dodgy with Airplay along the way.

 

Unlikely, unless you've synchronised another Airplay device or have a particularly dodgy WiFi connection. Shairport-sync's developer is quite clear as to when "stuffing" (audio frame insertion/deletion or even resampling) can occour:

https://github.com/mikebrady/shairport-sync

 

Wish Apple were just as transparent!

[Cebolla]

3 hours ago, Em2016 said:

To my ears, I found the RPi3 as a Spotify Connect device (on Moode Audio - see below) is significantly better than Chromecast Audio, maybe because it is being transcoded and downsampled from 320kbit/s to 256kbit/s.

 

Indeed, or worse - who knows what the Spotify app is doing when using Google Cast. You could try using the Logitech Media Server as the go between (via the Spotty & Chromecast bridge LMS plugins), as that would certainly be able to get 320kbps Spotify out to the Chromecast Audio. Transcoding does occour, but bit perfectly with the audio received by the CCA either as a WAV or a FLAC file stream.

[Cebolla]

1 hour ago, Miska said:

 

Well, you still don't know what transcoding Spotify is doing at their side...

 

True, but the assumption (going by what Spotify themseves advertise) is that the Spotify Connect routines used by the Spotty LMS plugin (so same as @Em2016's Spotify Connect in Moode Audio) should be being supplied with the OGG/Vorbis 320kbps streams from Spotify's online server, ie:

Spotify server -> Spotty LMS Plugin (receiving Spotify Connect 320kbps stream) ->  Chromecast bridge LMS plugin (WAV or FLAC) -> Chromecast Audio