Print

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

[maciekb]

Hi,

OPPO BDP-103/105 has ability to play DSD stream via DLNA network. It works on Twonky DLNA server, after editing mime types to following:

For DFF files - audio/x-dff
For DSF files - audio/x-dsf

OPPO doesn't have ability to receive stream in DoPE format (white noise static is present). Is it possible to add following mime types for DLNA server for Oppo's?


Best regards,
Maciek

[JimH]

In MC, you can set the conversion to anything that the Oppo will play.  It's in the Media Network settings under "Add or Configure DLNA Servers".  Try PCM.

[maciekb]

Hi Jim,

In MC, you can set the conversion to anything that the Oppo will play.  It's in the Media Network settings under "Add or Configure DLNA Servers".  Try PCM.

Yes, I know that MC can convert anything to PCM, but I don't want to do that for DSD. I want to stream DSD audio natively and bypass any PCM conversion in audio chain.


Best regards,
Maciej

[JimH]

You can also set MC not to convert.

[maciekb]

Hi Jim,

You can also set MC not to convert.

Yes, I know that too. :-) But without conversion DSD is unplayable. DLNA server has option to stream DSD in DoPE format, but as I wrote earlier, only white noise static is audible. When I "uncheck" DoPE format and turn off any conversion format all i've got is "There was a problem controlling selected DLNA device..." and "Something went wrong with playback".

OPPO can handle native DSD stream with DLNA, but only whet it got's proper mime types with audio.


Best regards,
Maciej

[JimH]

OPPO can handle native DSD stream with DLNA ....

From what you have described, that may not be the case.

[maciekb]

Hi Jim,

From what you have described, that may not be the case.

It works just fine with Twonky Server (without conversion or transcoding).


Best regards,
Maciej

[maciekb]

Hi Jim,

It works just fine with Twonky Server (without conversion or transcoding).


Best regards,
Maciej

Here is link to thread on Twonky forum: http://community.twonky.com/twonky/topics/is_twonky_going_to_support_dsd_audio_streaming

I have tested it with my setup and it works.


Best regards,
Maciej

[maciekb]

Hi Jim,

From what you have described, that may not be the case.

OPPO can play DSF and DFF files natively from SMB share or USB HDD/FLASH drive. It can play DSF and DFF files also over DLNA (DMP - pull from server) only when server sets correct mime types for those files.

Best regards,
Maciek

[Arindelle]

Hi -

I ran across this post recently -- it appears that the Oppo does not allow USB streaming via thrid party controllers/renderers only USB from external drives and SMB ... caveat - I may have misunderstood as I did not read all 15 pages of this post on Computer Audiophile => oppo-103-105-does-stereo-multi-channel-direct-stream-digital

maybe this would help you for work arounds or feature requests ??

[maciekb]

Hi Arindelle,

Hi -

I ran across this post recently -- it appears that the Oppo does not allow USB streaming via thrid party controllers/renderers only USB from external drives and SMB ... caveat - I may have misunderstood as I did not read all 15 pages of this post on Computer Audiophile => oppo-103-105-does-stereo-multi-channel-direct-stream-digital

maybe this would help you for work arounds or feature requests ??

Exactly. DSD (DFF and DSF files) is supported only from local USB/HDD storage, and DLNA (as DMP). DSD is not supported as DoPE (DLNA) or as DoP (USB ASYNC DAC - BDP-105 model). As I said earlier, all I ask is possibility to add correct mime types for DSF and DFF files served from MC when using OPPO as client (pull - DMP).

Best regards,
Maciek

[AndrewFG]

^

In my opinion, the guys at JRiver should not try to solve your issue by kludging in a few additional hard coded mime types. Instead, I would like to request that MC shall do a proper implementation of the UPnP GetProtocolInfo method.

Note: the GetProtocolInfo method allows source devices (SourceProtocolInfo) and sink devices (SinkProtocolInfo) to exchange exactly between each other which transport mechanisms (e.g. HTTP Get) that they support, which mime types (e.g. audio/l16) they support, plus information flags about the supported transport mechanism (e.g. transcoded, seekable, etc.).

The current version of MC does not take into account a renderer's SinkProtocolInfo at all (indeed I am not even sure if MC actually calls the GetProtocolInfo method ??); instead it just offers a fixed choice of a) don't convert (serve file in original format), or b) convert to MP3/PCM L16/24

Nowadays pretty much every renderer gives very explicit information about what formats it can play (SinkProtocolInfo), so I would strongly recommend that MC shall call GetProtocolInfo on each renderer and use the information received as a basis to choose which format it shall deliver to the renderer concerned.

In other words, in future MC should instead of having just "don't convert" and "always convert" settings, it should have a third "auto" option that chooses the best format based on the SinkProtocolInfo of the renderer concerned.

And furthermore, in future when MC offers tracks in response to ContentDirectory:Browse or ContentDirectory:Search requests, it should include in its offer a wider choice of ProtocolInfo formats and respective Urls that the server is able to transcode to. And it should set the ProtocolInfo attribute flags in those offers to indicate what it is offering (transcoded, seekable etc.) -- (for audio, the proposed minimum offer set would include original, pcm, flac and mp3...) And this offer set should be made known (or knowable) to the control point by means of MCs SinkProtocolInfo response to an incomimg GetProtocolInfo call.

PS bob, if you want further advice on this, then I shall be delighted to help out...

[connersw]

If I am reading that correctly, this would also allow WDTV Live to play flac w/o conversion? 

If so, make that +1 and +1.

Would love the ability to play DSD via DLNA to my new Oppo 105 and not have to convert flac to the WDTV Live upstairs. 

[AndrewFG]

If I am reading that correctly, this would also allow WDTV Live to play flac w/o conversion?  

I guess so.

In the UPnP standard, the correct "auto" format negotiation process is (should be) as follows:

• The renderer provides a list of all the music and video formats that it is able to play
• The server (in this case MC) provides a list of all the music and video formats that it is able to provide (either native or transcoded)
• The control point (MC in the case of "push", or the player in the case of "pull") chooses the highest quality format common to both lists
• The control point gives the renderer a url on the server where it can Get the chosen track in the chosen format

In the early days most servers, control points and renderers could only handle 2ch mp3, or 2ch 16bit 48000/44100Hz linear pcm, so early implementers (including JRiver) did not bother with the above auto negotiation process, but instead just pushed out one or the other of these formats (assuming that one or other would work). Note: to be strictly fair, MC can also push the native format (whatever it may be), but this is a dumb choice, preset in MC's settings, that has no bearing on, and no knowledge about, whether the renderer can actually understand any of the native formats that might be being pushed.

If MC would implement the above process, then it could easily determine that your Oppo supports flac (say), and it could therefore push flac to that player. Although (to be honest) in this particular case, if both units supported both flac and pcm at equally high resolution, they could just as likely end up talking pcm as talking flac. Probably in such a case of two possible formats being equally high resolution, a smart application like MC would make a casting vote for whichever format also required less CPU power (the format that does not need transcoding), and/or less network bandwidth (e.g. favoring flac over pcm).


EDIT: Just to pick up on the OP's earlier posts about editing mime types: If MC did properly follow the above negotiation process, it would also be able to see if the renderer declares support for (say) "audio/x-flac" rather than for (say) "audio/flac" (two different mime types meaning exactly the same thing), then it could be sure to give the renderer the exact mime type that the renderer has already declared itself to support. So (in other words) it would eliminate inter unit compatibility issues caused by such trivia...

[bob]

If I am reading that correctly, this would also allow WDTV Live to play flac w/o conversion? 

If so, make that +1 and +1.

Would love the ability to play DSD via DLNA to my new Oppo 105 and not have to convert flac to the WDTV Live upstairs. 

If you take a look at the actual sinkprotocolinfo the WD provides you wouldn't be very happy.

[bob]

Andrew, I agree a "auto" mode could be useful with some devices at this point.
The drawbacks are:

1) Lot's of devices only publish a small subset of what they are capable of playing. The WD is a perfect example. Most audiophile DAC's SinkProtocolInfo are extremely abbreviated.
2) The SinkProtocolInfo resource is limited in what it can tell you. For example, if you are looking at PCM you need a description for every separate combination of bit depth, channels and sample rates that you could play. Another example, most devices that play flac say simply audio/x-flac. Pretty close to useless. Same problems with wav, etc.
3) It gets even worse with video, sigh.

This IMO is why you see other servers implement an auto mode (for simple devices I believe) and a bunch of specific profiles for most devices.

[bob]

Finally, I wasn't aware of ANY renderers which played DSD without DoPE when I put in the mimetype for that so if you have one that specifies a mimetype that may actually be meaningful we could drop a test version to try it out.

[AndrewFG]

1) Lot's of devices only publish a small subset of what they are capable of playing. The WD is a perfect example. Most audiophile DAC's SinkProtocolInfo are extremely abbreviated.
2) The SinkProtocolInfo resource is limited in what it can tell you. For example, if you are looking at PCM you need a description for every separate combination of bit depth, channels and sample rates that you could play. Another example, most devices that play flac say simply audio/x-flac. Pretty close to useless. Same problems with wav, etc.

I hear where you are coming from. My attitude is that if you don't enforce the rules, then one should not be surprised if people break them. SourceProtocolInfo and SinkProtocolInfo are the proper way to negotiate matching media formats.

As you say, many mime types do require additional parameters (such as L16's rate and channels parameters); and in those cases you do indeed need to supply all the combinations that you are capable of supporting. This is actually why I am a great supporter of streaming in L16 or L24 since they are indeed one of the few mime types where everything is clearly specified up front.

BTW (IMHO) there are two suppliers who deserve special praise for the breadth and quality of the information they supply in SourceProtocolInfo and SinkProtocolInfo -- nameley JRiver and Microsoft in its WMP 12.

And BTW if WD doesn't provide the right information, then their product is broken and its developers must be forced to get their act together and fix it, rather than expecting you guys to develop a work around. It should not be your task to endlessly be developing work-arounds for other supplier's bad or lazy code.

Finally, I wasn't aware of ANY renderers which played DSD without DoPE when I put in the mimetype for that so if you have one that specifies a mimetype that may actually be meaningful we could drop a test version to try it out.

Actually no...  But isn't it the OP's hypothesis that the Oppo can play these (??). => So I will check SinkProtocolInfo on my own Oppo to see if that claim could be true or not...

[bob]

...
And BTW if WD doesn't provide the right information, then their product is broken and its developers must be forced to get their act together and fix it, rather than expecting you guys to develop a work around. It should not be your task to endlessly be developing work-arounds for other supplier's bad or lazy code.

Unfortunately they aren't interested in updating firmware, this is why you see servers with dozens of profiles. e.g. Sony TV 2010, 2011, 2012; Samsung BD a, b, c, etc.
There is no incentive for them to do this, they simply move on to the next model.

Bruce Schneier's post on embedded devices firmware security troubles has reasoning which also applies to DLNA device firmware. There's no incentive to fix the stuff.
https://www.schneier.com/blog/archives/2014/01/security_risks_9.html

Actually no...  But isn't it the OP's hypothesis that the Oppo can play these (??). => So I will check SinkProtocolInfo on my own Oppo to see if that claim could be true or not...

Cool, thanks!

[AndrewFG]

Unfortunately they aren't interested in updating firmware

You have probably got  point there...

I will check SinkProtocolInfo on my own Oppo to see if that claim could be true or not...

I did a GetProtocolInfo on all the renderer types in my home (attachments), and indeed it is clear that some manufacturers are more rigorous than others. (Well done to JRiver! And boo to Yamaha!)

As you can see from the attached, the Oppo advertises a lot of capabilities; but it does not mention DSF among them. As you imply, this does not mean that they don't actually support it. So now if you were to do a drop that proved it could support DSF then I would be willing to ask Oppo to update their SinkProtocolInfo accordingly. You might want to take this to the Beta group...

[bob]

Thanks for the dumps. Very interesting...
The current build uses the following mimetypes
dsf = audio/dsf
dsd = audio/dsd
dff = audio/dff
sacd = audio/sacd
Each has a DLNA.ORG_PN that I made up based on the mimetype. It appears that only some devices pay attention to the DLNA.ORG_PN.

It's possible that the mimetypes above need to be added to the audio section of the fileassociations.xml file in Data/Default Resources.

If the audio output is set to "original" and the DoPE option is turned off, these files will be sent to the renderer as-is.

[AndrewFG]

^

I tried pushing a DFF file to my Oppo 103 using MC build 111.

When the advanced option bitstream DSD (Dope) is disabled the push fails (problem controlling device, playback failed etc.).

But when Dope is enabled the push "succeeds" insofar as MC shows no error, and the Oppo displays its now playing progress bar. However no sound comes out. Presumably because the Oppo does not support Dope payloads.

Are you sending a different mime type when Dope is turned on versus off?

PS adding the file types to FileAssociations.xml did not make any difference...

[bob]

The push failure is likely the device simply rejecting the file (probably based on the mimetype). Doesn't sound to me like it does dsd.

The format for DoPE is encoded in PCM with the following:
BitDepth = 24;
MimeType = audio/wav
SampleRate = 176400
Multichannel is NOT downmixed.

This is what devices like the Mytek require.

[AndrewFG]

The push failure is likely the device simply rejecting the file (probably based on the mimetype). Doesn't sound to me like it does dsd.

Indeed. That is what the ProtocolInfo said after all  

However, referring back to the OP, he asserts that if you would offer content type audio/x-dff rather than audio/dff it might work ??

MimeType = audio/wav
SampleRate = 176400

Ok understood. The Oppo can of course play WAV which explains why the download works. And the "silence" is just because the payload is Dope rather than PCM; i.e. the "silence" isn't really silence but rather low level chatter.

[bob]

Hi Andrew, PM'd you..

[AndrewFG]

Hi Andrew, PM'd you..

Got it!

[maciekb]

Hi,

After editing fileassociations.xml I'm able to pull DFF files from JRiver DLNA server without any problems. Media are recognized as DFF files (icon with DFF media type on OPPO interface).

Thank You. :-)


Best regards,
Maciej

[bob]

Hi,

After editing fileassociations.xml I'm able to pull DFF files from JRiver DLNA server without any problems. Media are recognized as DFF files (icon with DFF media type on OPPO interface).

Thank You. :-)


Best regards,
Maciej

If you don't mind, what were the exact changes you made and what model do you have? I'm asking because that didn't work for Andrew.

[maciekb]

If you don't mind, what were the exact changes you made and what model do you have? I'm asking because that didn't work for Andrew.

Sure.

I've just added two lines to FileAssociations.xml in <Audio></Audio> section:

<Item Name="dff">audio/x-dff</Item>
<Item Name="dsf">audio/x-dsf</Item>

Without them, when I browsing JRiver DLNA server from my OPPO (BDP-105EU) DFF files are not visible. After adding MIME type definitions, DFF files are recognized and played correctly. My settings are shown in attachment.



Best regards,
Maciej

[AndrewFG]

^

Interesting. Maciekb is using pull (Browse) whereas I was using push (SetAvTransportUri). Also he put audio/x-dff in the file associations XML file whereas I tried audio/dff only. It seems that the Oppo or MC have slightly different behaviors depending on the push/pull code path..

PS maciekb has an Oppo 105 whereas mine is a 103. The manufacturer says that these both have the same digital parts and firmware, and the only difference is that the 105 has much better analog parts.

[maciekb]

Hi Andrew,

^

Interesting. Maciekb is using pull (Browse) whereas I was using push (SetAvTransportUri). Also he put audio/x-dff in the file associations XML file whereas I tried audio/dff only. It seems that the Oppo or MC have slightly different behaviors depending on the push/pull code path..

PS maciekb has an Oppo 105 whereas mine is a 103. The manufacturer says that these both have the same digital parts and firmware, and the only difference is that the 105 has much better analog parts.

BDP-105 differs not only by better analog parts, it has different DAC. For example, in BDP-105 is possible to adjust volume of DSD stream, BDP-103 can't do that.


Best regards,
Maciej

[bob]

^

Interesting. Maciekb is using pull (Browse) whereas I was using push (SetAvTransportUri). Also he put audio/x-dff in the file associations XML file whereas I tried audio/dff only. It seems that the Oppo or MC have slightly different behaviors depending on the push/pull code path..

PS maciekb has an Oppo 105 whereas mine is a 103. The manufacturer says that these both have the same digital parts and firmware, and the only difference is that the 105 has much better analog parts.

I'll check to see if the pull vs push produces different DIDL, I wouldn't think that it does.

[AndrewFG]

BDP-105 differs not only by better analog parts, it has different DAC.

IMHO a DAC is an analog part.

[maciekb]

IMHO a DAC is an analog part.

It could be analog or digital, everything depends on the point of view. :-)


Best regards,
Maciej

[AndrewFG]

I'll check to see if the pull vs push produces different DIDL, I wouldn't think that it does.

That's what I would have thought too. But actually I don't understand where the File Associations file comes into it. Do you look up in file associations to decide what protocol info to put in the DIDL? And/or do you look up in file associations to decide what mime type to put in the ContentType? And if indeed file associations is what determines both data, then why did your test drop work and the regular build not (for push)? i.e. is there something still hard coded that you are not looking up through the file associations file?

[bob]

That's what I would have thought too. But actually I don't understand where the File Associations file comes into it. Do you look up in file associations to decide what protocol info to put in the DIDL? And/or do you look up in file associations to decide what mime type to put in the ContentType? And if indeed file associations is what determines both data, then why did your test drop work and the regular build not (for push)? i.e. is there something still hard coded that you are not looking up through the file associations file?

Just checked and it goes through the same logic on both pull and push.
The file associations table is parsed to get the original mimetype and modified for some devices that we do specific tailoring for.
At some point I'm probably going to rework that all so that it uses the filetype in the database for everything, it's using the mimetype from file associations now because of the way the DLNA services were originally configured as a standalone service.
 

[AndrewFG]

Just checked and it goes through the same logic on both pull and push.
The file associations table is parsed to get the original mimetype and modified for some devices that we do specific tailoring for.

If everything goes through file associations, then how do you explain that the normal build did not work, but your special drop did? What was different between the regular build and the special drop?

[bob]

If everything goes through file associations, then how do you explain that the normal build did not work, but your special drop did? What was different between the regular build and the special drop?

I modified it in the special drop when the file associations were set to audio/dsf not audio/x-dsf.

[AndrewFG]

I modified it in the special drop when the file associations set to audio/dsf not audio/x-dsf.

So basically you did the same as the OP did?

set to audio/dsf not audio/x-dsf

PS If I am not wrong, surely you meant it the other way round?

PPS You also mentioned somewhere that in the ProtocolInfo you added a PN attribute that you had to make up yourself. I assume that the PN is still hardcoded in the exe even though the mime type is soft coded in the file associations xml file. IMHO obviously such a mix of hard and soft coding should be avoided if possible..

[greynolds]

Sure.

I've just added two lines to FileAssociations.xml in <Audio></Audio> section:

<Item Name="dff">audio/x-dff</Item>
<Item Name="dsf">audio/x-dsf</Item>

Without them, when I browsing JRiver DLNA server from my OPPO (BDP-105EU) DFF files are not visible. After adding MIME type definitions, DFF files are recognized and played correctly. My settings are shown in attachment.

I tried this change with my Oppo BDP-105D and it works fine when using the player's UI to browse through the DLNA server.  I confirmed that the player was receiving DSD and that my Denon AVP-A1HDCI surround sound processor was receiving DSD.

It does not work when using J Remote to push file selections to the player to play, however.  In that case, JRemote shows the files playing very briefly then stopping, going to the next file and doing the same thing.  In this case, no sound comes out of the speakers and there's no indication that anything is making it to the Oppo.

[AndrewFG]

^

Summary (for bob)..

1. Adding the x- form mime types to FileAssociations.xml seems to fix the problem with pull.
2. The special drop that you sent me seems to fix the problem with push.

Bob I suggest you integrate these two in the next beta, and I will give that one a try. (Otherwise there seem to be too many balls in the air at the same time...)

[AndrewFG]

^

Ok, I think I can now say here that there is definitely a fix in the pipeline for this issue that works for both push and for pull.

[bob]

^

Ok, I think I can now say here that there is definitely a fix in the pipeline for this issue that works for both push and for pull.

Thanks for checking it!

[maciekb]

^

Ok, I think I can now say here that there is definitely a fix in the pipeline for this issue that works for both push and for pull.

Great news, thanks! :-)

Best regards,
Maciek

[oldzorki]

According to release notes, issue is fixed - however I still cannot stream DSD to OPPO BDP-105. Well, it streams, but I can hear only hiss, even as oppo shows progress of the song.. (I use "push", have not tried "pull" yet). Running latest JRiver and OPPO software.
Correction - just tried use "pull" (OPPO as DLNA client), same result. It shows DFF songs as WAV. Plays the same files fine from attached or networked storage,

[AndrewFG]

^

Can you please be specific about what kind of track are you trying to play? Is it DSD, DSF, DFF or something else?

[oldzorki]

^

Can you please be specific about what kind of track are you trying to play? Is it DSD, DSF, DFF or something else?

Andrew,
I was trying to play DSF files (from Opus3 DSD Showcase collection) and from SACD ISO file (DS, Love Over Gold).
Result was the same - no sound (however I could see a "progress bar" of playing on TV screen). Sound was missing from HDMI out and from analog outs.
When DSF files were on a network drive or on USB tumb drive - OPPO BDP-105 played them just fine. (We know that OPPO by itself now will not play SACD-R image.)
When I look at list of songs via JRiver - sign for music was "wav".
When they were on USB drive - "dsf".

All other files (various video formats, hi-rez flac, mp3, etc.) are playing on OPPO via JRiver just fine.

I am running JRiver version 19.0.117
Oppo software version BDP10X-70-0218

And while we here - may I have a suggestion? When converting songs from SACD ISO files to separate DSF files JRiver write everything in one file (with the same name as original ISO file). So if you converting 2 songs from the same album, second overwrites the first. There should be a way to name output based on track name - or at least distinguish them as (file)-1.dsf, etc. Otherwise conversion of more then one track from SACD ISO file is not usable at all.

[bob]

You probably have the DoPE box checked in the DLNA server advanced audio configuration (uncheck it) or the output format isn't set to "original format".

[AndrewFG]

You probably have the DoPE box checked in the DLNA server advanced audio configuration (uncheck it) or the output format isn't set to "original format".

I concur with bob's analysis. I know for a fact that MC can push DSF to the Oppo. And indeed if you send DSD over PCM (aka DoPE) this does indeed usually result in low level white noise on a renderer.

[oldzorki]

I concur with bob's analysis. I know for a fact that MC can push DSF to the Oppo. And indeed if you send DSD over PCM (aka DoPE) this does indeed usually result in low level white noise on a renderer.

Thank you, Bob and Andrew, greatly appreciated!
You are absolutely correct - I can now play DSF files. However, tracks from SACD ISO are still not playable on OPPO and attempts to play results in error "something wrong".

I can play them in mode "Specified output format only when necessary" -and it plays indeed music, converted to 24/176 PCM (however, I feel a little degradation of the sound, but it may be psychological). But it converts DSF as well (I checked stream to external decoder from OPPO - it becomes in this case of this option PCM ), even if in "Original" mode DSF plays as DSD. How JRiver identifies that it is necessary to convert?

One solution will be converting SACD to DSF, but as I wrote before  - When converting songs from SACD ISO files to separate DSF files JRiver write everything in one file (with the same name as original ISO file). So if you converting 2 songs from the same album, second overwrites the first. There should be a way to name output based on track name - or at least distinguish them as (file)-1.dsf, etc. Otherwise conversion of more then one track from SACD ISO file is not usable at all.

So we are very close... but still some hurdles remains.