Same bug in some control points apps : how to get it corrected ?

[lyapounov]

Hello

 

I am using Minimserver on a Synology, and I have now all my SACDs collection ripped in dsf format.

I have two renderers : one (Oppo) reads dsf, the other (Linn) does not.

 

As I do not want to duplicate all my dsf into flac, I use the minimserver trick, which is to transcode dsf to wave only if the renderer cannot read dsf (the exact syntax of stream.transcode is dsf:-/wav24;176 which means "if the renderer can read dsf, send him dsf; if not, convert to wav24 @ 176kHz").

 

This means that the control point must be able to read the information published by the renderer. If it can't, then the app scrolls through all files, and plays none. This is what unfortunatly happens on most renderers.

 

I have tested a few control point apps :

- Lumin app does not work

- Linn Kazoo does not work

- PlugPlayer : does not work

- Kinsky : yeah, does work ! (yes, the good old Kinsky does work)

- Creation 5 : does work partially (it is the reverse of the others : it converts perfectly dsf to wave24 for the Linn, but when sending to the oppo, nothing happens)

 

I have not tested any other.

 

It would be nice if all control points now would correct their app to make them working properly !

 

Thx

[lyapounov]

Well, Kinsky recognizes the Oppo, but not the Linn :-(

[Cebolla]

As I do not want to duplicate all my dsf into flac, I use the minimserver trick, which is to transcode dsf to wave only if the renderer cannot read dsf (the exact syntax of stream.transcode is dsf:-/wav24;176 which means "if the renderer can read dsf, send him dsf; if not, convert to wav24 @ 176kHz").

 

This means that the control point must be able to read the information published by the renderer. If it can't, then the app scrolls through all files, and plays none. This is what unfortunatly happens on most renderers.

 

I have tested a few control point apps :

- Lumin app does not work

- Linn Kazoo does not work

- PlugPlayer : does not work

- Kinsky : yeah, does work ! (yes, the good old Kinsky does work)

- Creation 5 : does work partially (it is the reverse of the others : it converts perfectly dsf to wave24 for the Linn, but when sending to the oppo, nothing happens)

Let's be clear, it's the control point that is making the decision as to which of the two audio file streams the renderer gets to play. So it's probably more accurate to say that the MinimServer media server's stream.transcode property setting of dsf:-/wav24;176 means "two audio file streams are available for the control point to choose from for a dsf file track: stream #1 is the original dsf file; stream #2 is a 24/176.4kHz wav file transcoded from the dsf file".

 

The 'information published by the renderer' includes all the audio file types that the renderer is capable of playing, so is quite funadamental information and I would expect all control points to read this basic information from the renderer. Therefore, when the control point fails to get the renderer to play when presented with these multiple audio file streams for each playlist file track by the media server, it's unlikely that it's because the control point hasn't read the 'published information' from the renderer. What's more likely is that that control point doesn't support receiving the multiple file stream URLs for each playlist file track from the media server; the control point is only able to receive a single file stream URL for each playlist file track.

 

This would mean that in your test findings the Linn Kazoo, Lumin & PlugPlayer control point apps can only read the first stream (stream #1 - original dsf file) in the information supplied by MinimServer. So these control points allow the Oppo to play as they know that the Oppo supports dsf (from the Oppo's published info), but don't allow the Linn to play & skip to the next file track as they know the Linn doesn't support dsf (from the Linn's published info).

 

For some reason, the Creation C5 app does the opposite to the other 'failing' control point apps you tested and is only able to read the last stream (stream #2 - the 24/176.4kHz wav file transcoded from the original dsf file) in the information from MinimServer. Presumably, both the Linn & the Oppo are supposed to be able to play hi-res wav files, so I'm not certain why the Oppo couldn't play the 24/176.4kHz wav file stream, when controlled by the C5 app. It would certainly be worth testing further with all the control point apps (so not just the C5 app), by setting MinimServer to produce just the single transcoded wav stream (ie, set stream.transcode to dsf:wav24;176) and seeing if the Oppo still has a problem playing the transcoded wav stream.

 

BTW, I tried your same tests using the same controller apps except PlugPlayer, on an iPad, though I had to use different renderers (but with the same issue with dsf files: one renderer can stream and play them, the other can't) as I don't have Oppo nor Linn devices. You didn't mention which controller device you used, but I assumed iOS (and I therefore used an iPad), because the Creation C5 is only available on iOS. I found exactly the same as you did, except both my renderers were able to play the transcoded 24/176.4kHz wav file stream when controlled with the C5 app.

 

I then tested the reverse stream order, with the 24/176.4kHz wav file stream first and the original dsf file stream last, by setting MinimServer's stream.transcode property to dsf:wav24;176/-

Sure enough, I got the expected results:

- Both renderers playing 24/176.4kHz wav with the Lumin & Linn Kazoo apps

- The DSD capable renderer playing the dsf file & PCM only renderer playing 24/176.4kHz wav with the Kinsky app

- The DSD capable renderer playing the dsf file, but the PCM only renderer failing to play (including a warning message about not supporting the audio type) with the C5 app.

 

 

Well, Kinsky recognizes the Oppo, but not the Linn :-(

That's ironic seeing as the Kinsky app is supposed to be the original controller for Linn devices! I certainly have no such problem with my non-Linn renderers.

 

Incidentally, if you can use an Android device instead of iPad/iPhone, try the excellent BubbleUPnP Android controller app, as that does work with multiple audio file streams available for the same file track, from the UPnP/DLNA media server. Similarly, so does the BubbleDS Next Android app, but it only supports OpenHome renderers (like the Linn Kazoo & Lumin apps).

[lyapounov]

Let's be clear, it's the control point that is making the decision as to which of the two audio file streams the renderer gets to play. So it's probably more accurate to say that the MinimServer media server's stream.transcode property setting of dsf:-/wav24;176 means "two audio file streams are available for the control point to choose from for a dsf file track: stream #1 is the original dsf file; stream #2 is a 24/176.4kHz wav file transcoded from the dsf file".

 

The 'information published by the renderer' includes all the audio file types that the renderer is capable of playing, so is quite funadamental information and I would expect all control points to read this basic information from the renderer. Therefore, when the control point fails to get the renderer to play when presented with these multiple audio file streams for each playlist file track by the media server, it's unlikely that it's because the control point hasn't read the 'published information' from the renderer. What's more likely is that that control point doesn't support receiving the multiple file stream URLs for each playlist file track from the media server; the control point is only able to receive a single file stream URL for each playlist file track.

 

This would mean that in your test findings the Linn Kazoo, Lumin & PlugPlayer control point apps can only read the first stream (stream #1 - original dsf file) in the information supplied by MinimServer. So these control points allow the Oppo to play as they know that the Oppo supports dsf (from the Oppo's published info), but don't allow the Linn to play & skip to the next file track as they know the Linn doesn't support dsf (from the Linn's published info).

 

For some reason, the Creation C5 app does the opposite to the other 'failing' control point apps you tested and is only able to read the last stream (stream #2 - the 24/176.4kHz wav file transcoded from the original dsf file) in the information from MinimServer. Presumably, both the Linn & the Oppo are supposed to be able to play hi-res wav files, so I'm not certain why the Oppo couldn't play the 24/176.4kHz wav file stream, when controlled by the C5 app. It would certainly be worth testing further with all the control point apps (so not just the C5 app), by setting MinimServer to produce just the single transcoded wav stream (ie, set stream.transcode to dsf:wav24;176) and seeing if the Oppo still has a problem playing the transcoded wav stream.

 

 

I have tried dsf:wav24;176 : both oppo and Linn read this perfectly, as it is all transcoded.

 

Now, I had made more test (yes, on an iPad) :

 

- Lumin & Kazoo don't recognize that Linn cannot read dsf, and therefore send it through without any transcoding.

- Lumin & Kazoo recognize that Oppo can read dsf, and send it through

- Kinsky does recognize and transcode for the Linn

- Kinsky does not recognize that Oppo can read dsf, and therefore transcode

 

So, basically, Kazoo & Lumin never transcode, and Kinsky always transcode !

 

Will try the reverse order which you did as well.

 

I don't have an Android device :-(

 

And as for the Oppo, I use BubbleUPnP server on my synology to create an openHome renderer.

 

Thx for your detailed contribution !!