Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[philippe_44]

Hi - Can JRiver renderer part accept DSD through DLNA? Currently, when looking at protocolInfo returned, whatever option I try to set, there is no audio/dsd or audio/dsf or audio/dff which means that no DLNA controller can send DSD to it

Thanks

[JimH]

Try setting "No conversion" on the server (MC).

[AndrewFG]

Hi - Can JRiver renderer part accept DSD through DLNA? Currently, when looking at protocolInfo returned, whatever option I try to set, there is no audio/dsd or audio/dsf or audio/dff which means that no DLNA controller can send DSD to it

Thanks

The MC renderer probably CAN play DSD etc. if you push that format to it. Just try it anyway, as Jim suggests.

You may be right that MC might not report its capabilities in its GetProtocolInfo response (I did not check). The people at JRiver have always been disdainful about checking the ProtocolInfo of other renderers, so it would come as no surprise to me if they didn’t care too much about sending a correct response themselves

As mentioned, I haven’t recently run my DMRA against MC, but if you download it from my sig, you can run the test yourself, and you will see the ProtocolInfo in the renderer report..

[bob]

It can always play DSD as a renderer one way or the other. Natively if the output device supports it.
We do try to keep our SinkProtocolInfo up to date. I'll see if those need to be added...

[philippe_44]

Try setting "No conversion" on the server (MC).

The problem is not at the MC, but my MC (it's something I wrote so I have full control of it) is reading ProtocolInfo to decide what format to send or not. I can force audio/dsf (or variants), but I think that respecting ProtocolInfo's directives is a good thing to do, no?

[bob]

The problem is not at the MC, but my MC (it's something I wrote so I have full control of it) is reading ProtocolInfo to decide what format to send or not. I can force audio/dsf (or variants), but I think that respecting ProtocolInfo's directives is a good thing to do, no?

The next builds will have additions for those both in the Sink and Source.

We do NOT pay attention to other devices SINKPROTOCOLINFO because we've found it to be unreliable in many devices and incomplete in ALL devices since for anything other than LPCM you can't determine supported sample rates or bitdepths from SINKPROTOCOLINFO.

[philippe_44]

Thanks

[AndrewFG]

We do NOT pay attention to other devices SINKPROTOCOLINFO because we've found it to be unreliable in many devices and incomplete in ALL devices since for anything other than LPCM you can't determine supported sample rates or bitdepths from SINKPROTOCOLINFO.

I have for a long time proposed that MC’s DLNA server settings should have a 3-way Switch rather than a 2-way. So instead of offering just Original/Convert you should offer Auto/Original/Convert. Where the Auto setting cause the server to select the most common denominator between the native media format, the SourceProtocolInfo of MC, and the SinkProtocolInfo of the renderer.

In fact MC “kind of” offers such a third Switch option “Convert when necessary” already. However the current implementation of that switch is rather half hearted, and not consistently implemented across all media formats. So essentially my proposal is that JRiver should do some work to clean up “Convert when necessary” to make it applicable to all media formats (audio, video, and possibly even images), and implemented according to a clear logic based on ProtocolInfo.

Indeed I think the Auto setting should be the default on new installs.

I do take bob’s point about lack of bit rates and bit depths in the non DLNA ProtocolInfo entries. However I would suggest that if a renderer advises (say) audio/flac or audio/x-flac, then under the Auto setting the MC should indeed push flac (in this example) for all bit depths and bit rates; and if the user finds that their renderer doesn’t actually support the respective rate or depth, they can always fall back to changing from Auto to one of the two manual modes (i.e. Original or Convert).

[philippe_44]

BTW, I have that working now if I force sending DSD regardeless of protocol info, but just FYI if mimetype is audio/dsf (which is the verified format I'm sending, it's not dff) then it does not work, JRiver rejects it. If mimetype is audio/dsd it works.

[AndrewFG]

Try x-dff instead of plain dff..

[bob]

Try x-dff instead of plain dff..

I'll check on that as well in the renderer code.

I do understand your point about the auto-conversion. I might play around with that in MC25 if time allows...