Jump to content
IGNORED

Sonore Signature Series Rendu does not report MIME DSD


Recommended Posts

Hello,

I have a Sonore Signature Rendu that is used for streaming music files from my NAS based music server via BubbleUPnP to my PS Audio DirectStream DAC via I2S.

 

My Control point is BubbleUPnP version 2.8.3.1 running on a Samsung Galaxy Tab S2 tablet.

My NAS is a QNAP TVS-463 with 16GB memory.

My music server is MinimServer 0.8.4 update 88 with MinimStreamer 0.5.25 and both are running on the NAS.

I also have Bubble UPnP Server Version 0.9-update21 running on my NAS.

In MinimStreamer>Properties>System>stream.transcode I have set the value to "dsf:-/wav24;176"

According to Simon, MinimServer/MinimStreamer developer, this should allow native DSD if the renderer reports it is supported or wav is the renderer does not report it supports DSD.

I need the wav support for other playback devices in my house that do not support native DSD. The DSD files are being sent to the other non-DSD playback devices as wav and play.

 

From my Windows 10 laptop I can access the Sonore device web page which shows the MR-MOD device web page and reports:

device highlights

HD Audio Digital Media Renderer

2-channel asynchronous endpoint for jitter-free stereo playback

bit-perfect data transmission

PCM resolution up to 32-bit at 384kHz

support for native DSD64 and DSD128

UPnP AV 2.0 / DLNA

Firmware in use : V1.48 000 000 DD74519A (Tue Sep 1 10:22:13 2015)

 

When I check the Info of the renderer (Sonore with MR-MOD board) in BubbleUPnP it reports back that it supports:

Audio AAC, AIFF, FLAC, M4A, MP3, WAV

The Sonore Signature Rendu does not tell BubbleUPnP that it supports the MIME extension for DSD.

I have checked both the normal Sonore info and the Open Home Sonore info (from BubbleUPnP Server) and get the same results.

 

So far it is working very good for flac, wav and m4a but now I have purchased some DSF files and would like to play them in native DSD64 or DSD128 which the device page says is supported.

Since my Sonore Signature Rendu does not tell BubbleUPnP that it supports DSD the files are being transcoded to wav for playback.

They do playback in wav format but I want to have them playback in native DSD format.

 

Is it a known problem that the MR-MOD board does not report the DSD MIME format capability properly?

Can this be corrected?

Can you help me?

 

Thank you,

Chip Headrick

The Netherlands

Link to comment
Hello,

I have a Sonore Signature Rendu that is used for streaming music files from my NAS based music server via BubbleUPnP to my PS Audio DirectStream DAC via I2S.

 

My Control point is BubbleUPnP version 2.8.3.1 running on a Samsung Galaxy Tab S2 tablet.

My NAS is a QNAP TVS-463 with 16GB memory.

My music server is MinimServer 0.8.4 update 88 with MinimStreamer 0.5.25 and both are running on the NAS.

I also have Bubble UPnP Server Version 0.9-update21 running on my NAS.

In MinimStreamer>Properties>System>stream.transcode I have set the value to "dsf:-/wav24;176"

According to Simon, MinimServer/MinimStreamer developer, this should allow native DSD if the renderer reports it is supported or wav is the renderer does not report it supports DSD.

I need the wav support for other playback devices in my house that do not support native DSD. The DSD files are being sent to the other non-DSD playback devices as wav and play.

 

From my Windows 10 laptop I can access the Sonore device web page which shows the MR-MOD device web page and reports:

device highlights

HD Audio Digital Media Renderer

2-channel asynchronous endpoint for jitter-free stereo playback

bit-perfect data transmission

PCM resolution up to 32-bit at 384kHz

support for native DSD64 and DSD128

UPnP AV 2.0 / DLNA

Firmware in use : V1.48 000 000 DD74519A (Tue Sep 1 10:22:13 2015)

 

When I check the Info of the renderer (Sonore with MR-MOD board) in BubbleUPnP it reports back that it supports:

Audio AAC, AIFF, FLAC, M4A, MP3, WAV

The Sonore Signature Rendu does not tell BubbleUPnP that it supports the MIME extension for DSD.

I have checked both the normal Sonore info and the Open Home Sonore info (from BubbleUPnP Server) and get the same results.

 

So far it is working very good for flac, wav and m4a but now I have purchased some DSF files and would like to play them in native DSD64 or DSD128 which the device page says is supported.

Since my Sonore Signature Rendu does not tell BubbleUPnP that it supports DSD the files are being transcoded to wav for playback.

They do playback in wav format but I want to have them playback in native DSD format.

 

Is it a known problem that the MR-MOD board does not report the DSD MIME format capability properly?

Can this be corrected?

Can you help me?

 

Thank you,

Chip Headrick

The Netherlands

 

Can you provide a screen shot of what you are seeing in BubbleUPnP?

Link to comment
Hello,

This is what I see for the normal SSR.

 

And this with OpenHome.

 

Does this help?

How can I get my SSR to report it can process DSD files?

Chip

It may not show up on that list, but it has to report the format it supports or you would not be able to play DSD files. Can you send DoP instead?

Link to comment

Hi,

 

I have tried my system using the following parameters in MinimServer and using BubbleUPnP as the control point.

stream.transcode results

"dsf:-/dopwav" plays DSD64 files as PCM24/176.4 and DSD128 files as DSD128

"dsf:-/wav24;176" plays DSD64 files as PCM24/176.4 and DSD128 files as DSD128

<empty, no values> plays DSD64 files as DSD64 and DSD128 files as DSD128

 

The results are shown on the display of my PS Audio DirectStream DAC.

BubbleUPnP shows WAV in place of PCM and DSF in place of DSD but since is really saying the same thing I think it is OK.

If I do not use any transcoding options I can playback native DSD64 and DSD128.

If I use the either transcode option I end up with PCM24/176.4 for DSD64 and native DSD128.

 

Now this seems even more confusing since my SSR can send native DSD64 and DSD128 if I do not use a value but when I setup MinimServer to send the format based on the renderer it will not send DSD64.

 

Any ideas?

Chip

Link to comment

Hi,

I have been debugging this problem with the developer of MinimServer this evening and we have come to the following conclusion.

The SSR is responding with the wrong MIME types for DSD audio.

 

We issued a "GetProtocolInfo" command to the SSR and it responded with the following capabilities.

http-get:*:audio/flac:*,http-get:*:audio/x-flac:*,http-get:*:audio/wav:*,http-get:*:audio/x-wav:*,http-get:*:audio/mpeg3:*,http-get:*:audio/mp3:*,http-get:*:audio/x-aiff:*,http-get:*:audio/aiff:*,http-get:*:audio/aac:*,http-get:*:audio/mp4:*,http-get:*:audio/m4a:*,http-get:*:audio/dsd,http-get:*:audio/dsf,http-get:*:audio/dff

 

The last three protocols relate to DSD:

http-get:*:audio/dsd

http-get:*:audio/dsf

http-get:*:audio/dff

But these are not officially supported MIME Type responses for DSD files.

 

The SSR should respond with:

http-get:*:audio/x-dsd

http-get:*:audio/x-dsf

http-get:*:audio/x-dff

 

Does this make sense to you?

 

Do you think it is possible to get a firmware update for the board to correct this?

 

Chip

Link to comment
"dsf:-/dopwav" plays DSD64 files as PCM24/176.4 and DSD128 files as DSD128

try dsf:dopwav

"dsf:-/wav24;176" plays DSD64 files as PCM24/176.4 and DSD128 files as DSD128

try dsf:wav24;176

<empty, no values> plays DSD64 files as DSD64 and DSD128 files as DSD128

correct

Link to comment
Hi,

I have been debugging this problem with the developer of MinimServer this evening and we have come to the following conclusion.

The SSR is responding with the wrong MIME types for DSD audio.

 

We issued a "GetProtocolInfo" command to the SSR and it responded with the following capabilities.

http-get:*:audio/flac:*,http-get:*:audio/x-flac:*,http-get:*:audio/wav:*,http-get:*:audio/x-wav:*,http-get:*:audio/mpeg3:*,http-get:*:audio/mp3:*,http-get:*:audio/x-aiff:*,http-get:*:audio/aiff:*,http-get:*:audio/aac:*,http-get:*:audio/mp4:*,http-get:*:audio/m4a:*,http-get:*:audio/dsd,http-get:*:audio/dsf,http-get:*:audio/dff

 

The last three protocols relate to DSD:

http-get:*:audio/dsd

http-get:*:audio/dsf

http-get:*:audio/dff

But these are not officially supported MIME Type responses for DSD files.

 

The SSR should respond with:

http-get:*:audio/x-dsd

http-get:*:audio/x-dsf

http-get:*:audio/x-dff

 

Does this make sense to you?

 

Do you think it is possible to get a firmware update for the board to correct this?

 

Chip

 

I'll chat with Simon to see what can be done.

Link to comment

I received some additional information from Simon this morning that could be interesting, it certainly is to me.

 

------------- start of update from Simon -------------

There is a list of registered MIME types on this page. For streams that match one of these types, the registered type should be used.

 

Many of the audio streams in common use don't match any registered type. In this case, the convention has been that a type starting with 'x-' should be used to indicate that the type is not one of the official ones. There is no list of the 'x-' types and these become "standard" by accepted usage rather than by inclusion in a formal list. This approach was recommended by the MIME type specification for many years (see section 2.1 of this document) but the recommendation has now been changed (see this document), so I should not have described Sonore's choice as "not correct" in my previous post.

 

Unfortunately, the water has become quite muddy over the years with different type names used by different products for the same stream, including an apparently random mixture of types with and without the 'x-' prefix. This has caused compatibility problems between streamers and renderers and is a generally unsatisfactory situation.

 

Each stream advertised by the server has a single MIME type. However, the renderer can advertise compatibility with multiple MIME types for the same stream type. Sonore is already doing this for some streams (e.g., audio/flac and audio/x-flac). The fix for Sonore is therefore not to change the existing DSD types such as audio/dsf but to add new types such as audio/x-dsf alongside existing types such as audio/dsf.

 

------------- end of update from Simon --------------

 

This both clarifies the issue for me and helps me understand the confusion many of us have about a standard that is not really a standard.

 

At this time it seems like the most foolproof way to go forward is to add both variants of the audio MIME type to insure compatibility.

 

I hope we can find a solution that allows everything to work together.

 

Thanks for all your attention and ideas, please let me know the outcome of your discussions.

 

Thanks,

Chip

 

PS: I will try the test you identified in your past when I get home this evening.

Link to comment

Hi,

Music Library

MinimServer 0.8.4 update 88

MinimStreamer 0.5.2

stream.converter ffmpeg314

Bubble UPnP Server Version 0.9-update21

 

Control Point

Samsung Galaxy Tab S2 tablet

BubbleUPnP version 2.8.3.1

 

Renderer

Sonore Signature Rendu shown as Audio Render-143 (OpenHome)

 

DAC

PS Audio DirectStream DAC

 

NativeDSD downloads used for testing

Sarah Vaughn - Live at Rosy's

DSD64 - 09 A-Tisket, A-Tasket.dsf

DSD128 - 09 A-Tisket, A-Tasket.dsf

 

MinimStreamer stream.transcode values and results from 2016-12-08 testing requested by Sonore

 

MinmStreamer stream.transcode value <empty, no values> and restart server

DSD64 file

PS Audio displays - Input: DSD Rate: DSD64 1 bit

BubbleUPnP displays - DSF | 2822.4 kHz | 1 bit

DSD128 file - small spike before playback

PS Audio displays - Input: DSD Rate: DSD128 1 bit

BubbleUPnP displays - DSF | 5644.8 kHz | 1 bit

This plays back as expected with only a small spike when changing from DSD64 to DSD128.

 

Clear BubbleUPnP playlist

MinmStreamer stream.transcode value "dsf:dopwav" and restart server

DSD64 file - small spike before playback, switching from DSD128 to DSD64

PS Audio displays - Input: DOP Rate: DSD64 1 bit

BubbleUPnP displays - WAV | 176.4 kHz | 24 bits

DSD128 file - small spike before playback, switching from DSD64 to DSD128

PS Audio displays - Input: DOP Rate: DSD64 1 bit

BubbleUPnP displays - WAV | 352.8 kHz | 24 bits

Playback of this track sounds like it is at half speed

The PS Audio does not playback 352.8 kHz files

The time slider on BubbleUPnP moves to 100% but timer keeps counting until 3:39 but the track is only 1:49 long

The DSD64 file plays back as expected but the DSD128 file does not playback properly

 

Clear BubbleUPnP playlist

MinmStreamer stream.transcode value "dsf:wav24;176" and restart server

DSD64 file

PS Audio displays - Input: PCM Rate: 176.4k 24 Bits

BubbleUPnP displays - WAV | 176.4 kHz | 24 bits

DSD128 file

PS Audio displays - Input: PCM Rate: 176.4k 24 Bits

BubbleUPnP displays - WAV | 176.4 kHz | 24 bits

Both playback as expected without spikes

 

 

Is this the test you wanted me to perform?

Do my results help you identify the issue?

 

Please advise,

Chip

Link to comment

Hello,

I just went over to the PS Audio website and it says the DirectStream DAC will play:

Sample Rates

I2S,S/PDIF, and USB -- 44.1kHz to 352.8kHz 16bit, 24bit, DSD 64, DSD 128

TOSLINK – 44.1kHz to 96kHz 16bit, 24bit

XLR (AES/EBU) -- 44.1kHz to 192kHz 16bit, 24bit, DSD 64

I am using the I2S interface from my SSR to the DS DAC so my statement in the previous post:

The PS Audio does not playback 352.8 kHz files

is wrong!

 

Now I am more confused about why the DSD128 file did not playback correctly.

I then tried the file again and had the same results.

 

Sorry about my confusion,

Chip

Link to comment
MinmStreamer stream.transcode value <empty, no values> and restart server

DSD64 file

PS Audio displays - Input: DSD Rate: DSD64 1 bit

BubbleUPnP displays - DSF | 2822.4 kHz | 1 bit

DSD128 file - small spike before playback

PS Audio displays - Input: DSD Rate: DSD128 1 bit

BubbleUPnP displays - DSF | 5644.8 kHz | 1 bit

This plays back as expected with only a small spike when changing from DSD64 to DSD128.

Correct and as expected

 

Clear BubbleUPnP playlist

MinmStreamer stream.transcode value "dsf:dopwav" and restart server

DSD64 file - small spike before playback, switching from DSD128 to DSD64

PS Audio displays - Input: DOP Rate: DSD64 1 bit

BubbleUPnP displays - WAV | 176.4 kHz | 24 bits

DSD128 file - small spike before playback, switching from DSD64 to DSD128

PS Audio displays - Input: DOP Rate: DSD64 1 bit

BubbleUPnP displays - WAV | 352.8 kHz | 24 bits

Playback of this track sounds like it is at half speed

The PS Audio does not playback 352.8 kHz files

The time slider on BubbleUPnP moves to 100% but timer keeps counting until 3:39 but the track is only 1:49 long

The DSD64 file plays back as expected but the DSD128 file does not playback properly

For DSD128 to stream via DoP you need 352.8 kHz support. The SSR does not currently support 352.8 kHz or 384 kHz. It is possible to update it to support up to 384 kHz, but it's expensive and we have not offered the update. The PS audio DAC supports 352.8 kHz, but not 384 kHz.

 

Clear BubbleUPnP playlist

MinmStreamer stream.transcode value "dsf:wav24;176" and restart server

DSD64 file

PS Audio displays - Input: PCM Rate: 176.4k 24 Bits

BubbleUPnP displays - WAV | 176.4 kHz | 24 bits

DSD128 file

PS Audio displays - Input: PCM Rate: 176.4k 24 Bits

BubbleUPnP displays - WAV | 176.4 kHz | 24 bits

Both playback as expected without spikes

Correct and as expected

Link to comment

Hello,

OK, I understand why the problem with DSD128 to dopwav does not work.

 

Now I am back to the original reason for my post - MIME types.

 

Is it possible to update the firmware in the SSR to advertise the audio/x- MIME types so MinmServer and BubbleUPnP can recognize the stream type to send?

 

So it will advertise:

audio/dsd

audio/dsf

audio/dff

and

audio/x-dsd

audio/x-dsf

audio/x-dff

like it already does for audio/flac and audio/x-flac?

 

I think this would make the SSR more compatible with different systems.

 

Thank you,

Chip

Link to comment
Hello,

OK, I understand why the problem with DSD128 to dopwav does not work.

 

Now I am back to the original reason for my post - MIME types.

 

Is it possible to update the firmware in the SSR to advertise the audio/x- MIME types so MinmServer and BubbleUPnP can recognize the stream type to send?

 

So it will advertise:

audio/dsd

audio/dsf

audio/dff

and

audio/x-dsd

audio/x-dsf

audio/x-dff

like it already does for audio/flac and audio/x-flac?

 

I think this would make the SSR more compatible with different systems.

 

Thank you,

Chip

 

It might be possible, but I have to look into it.

Link to comment
  • 4 months later...
On 12/13/2016 at 9:42 PM, chip said:

 

Hi,

Please let me know what you decide. I am very interested in having this capability to make my systems work together.

Thank you,

Chip

Since it has been just over 4 months do I need to assume that you will not be looking into correcting this problem with the SSR?

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...