dsf to wav : what CPU power ?

[chip]

(08-12-2016 13:56)bubbleguuum Wrote:  BubbleUPnP when playing to an OpenHome renderer will always send the first stream resource to the OH renderer without doing
any mime-type check (this is an anomaly that I should fix).
Thus if the Sonore OH renderer advertises "audio/dsd", "audio/dsf", "audio/dff" but MinimServer uses the correct "x-" versions of these mime-types, then theoretically the Sonore should still play the DSD version of the stream if it comes as first res in the DIDL-Lite sent by MinimServer (and the Sonore renderer doesn't trip on the x- mime-type).

Now if you play that same track to the Sonore UPnP AV renderer and mime-type check is enabled, BubbleUPnP will play the wav stream as the mime-type cannot be matched between MinimServer and Sonore for DSD. For some mime-types, BubbleUPnP add missing aliases (eg if a renderer advertises audio/flac, BubbleUPnP will add audio/x-flac. But not for DSD mime-types where BubbleUPnP only recognizes the x- versions. I could probably add the non x- versions as aliases as I don't think it would cause any problems.

Hi bubbleguuum,
Do you have a plan to fix the anomaly you describe in the first sentence of your post about OH playback?

If I do not use a stream.transcode entry the Sonore OH will play DSD64 and DSD128 files as expected.

What is the DIDL-Lite message you refer to? Is this unique to OH renderers? Is there a way to see the response is from my Sonore OH renderer?

I have MIME check enabled on BubbleUPnP CP but from your post I think this only applies for UPnP AV renderers.
Is this correct?

If I do not have any entries in MinmStreamer stream.transcode and use the Sonore UPnP AV renderer should it still play the DSD files?

I read in a later post that you have included the aliases in your DEV version of BubbleUPnP. A BIG THANK YOU from me.

I really appreciate your involvement and finding a solution for this mismatch.

Chip