Print

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

[mimizone]

I've seen this past thread started by @afalout on the topic of playing SACD ISO over DLNA.
https://yabb.jriver.com/interact/index.php/topic,118098.0.html

The thread is closed since it was not going anywhere useful I guess.
Let me state I don't want to start any debate on what the DLNA standard allows and what MC does to read ISO when played locally.

I am also playing SACD ISO sometimes and so far was using Audirvana only for that purpose mostly (and the iOS app working on iOS 9/iPad 2 but I digress).
It works out of the box with it, without having to configure DLNA servers/encoder/encapsulation etc...

But there is a way to do it with MC and get the same experience.

So for whoever is interested in playing SACD ISO with JRiver MC 24 on a Mac (and I assume it works on other versions) and not have to use Audirvana and pay for an additional license.

1. Create a DLNA server for your renderer.
2. Media Network>DLNA Servers>Audio>Mode : Specified output format only when necessary
3. Media Network>DLNA Servers>Audio>Format: I use either PCM 24-bit or PCM L24 No header
4. Media Network>DLNA Servers>Audio>Advanced>DSP Studio: Output Encoding "None"
5. Media Network>DLNA Servers>Audio>Advanced>Audio Formats to convert: check "sacd"
6. Media Network>DLNA Servers>Video>Advanced>Bitstream DSD: check the box    (why it's in video, not sure...)
7. Assign the DLNA Server to your DLNA renderer. (right click on the renderer that shows up in the "playing now" section)


I hope it helps somebody and save them some money.


Now maybe the MC developers can clarify if there is a PCM conversion happening in the process.
And then if there is another way to not have the conversion, and if not, if there is a way to configure the conversion.
But for what I can see in the audio path window, there is no conversion happening. But maybe it's under the hood when reading the iso file and hidden from the user?

Anyway, it sounds good on my DAC/headphones, so I am a happy camper.

[Scobie]

That's interesting, what renderer do you have?

[mimizone]

I use two.
A Sony str dn1050 receiver
And MoOde audio running on a raspberry pi 2 plugged to a usb DAC.

[mimizone]

So somehow, the Sony receiver doesn't play the music anymore with that setup.
MoOde still plays fine and the DAC shows DSD as expected.

I'll confirm if I can make it work again with the Receiver. I was not crazy... I hope...
 

[mimizone]

I am still trying to figure out what's the reason it works via DLNA to MoOde audio and not to the Sony Receiver.

So far, I believe that some metadata is missing or wrong and the Sony receiver may be relying on for instance only the Content type metadata to decide if it's a DSD or PCM.
MoOde must be using a different heuristic/technique.
It's pure assumption but it's based on the following.

All the following is when playing a SACD ISO from either JRiver or Audirvana.

----
Sniffing network traffic
----

When playing from JRiver MC, I sniffed the TCP packets and I see that the content type is set to WAV when playing a DSD with a DoP frame.
The renderer does a HTTP Get on the file (JRiver creates a file named .WAV but it could be anything I guess inside).
Then a few packets later, the DLNA server of JRiver responds with a message that contains a bunch of header/metadata, including the Content Type set to audio/wav.

When playing with Audirvana, the content type is set to audio/x-dsd.

I didn't dig more in the Wireshark capture of the traffic yet.
I was looking for the x05 and xFA value I believe for the first byte of the DoP Frame that shows it's DoP and not a regular PCM. I wonder if MoOde uses more that hint to decide it's DoP/DSD instead of regular PCM, ignoring the Content Type maybe?
But the Sony is more particular and picky?

-----
Another perspective from the DLNA renderer point of view:
-----

When playing via DLNA from Audirvana, MoOde audio reports that the input data is properly a DSD64. (MoOde as a Audio Information screen showing all that)
When playing with JRiver MC, the "Encoded At" Audio info in MoOde says unknown.
The Sony doesn't offer any debugging menu unfortunately.

though I want to repeat that MoOde plays fine the signal.

So the following path works fine for me.
SACD ISO->MC-> DLNA > MoOde > DAC > DSD64 > music
but not on the Sony Receiver

With Audirvana, it works with both DLNA renderers (MoOde and Sony).
Always showing DSD64 or higher as expected.

My main concern is that I just paid the $79 for a license of MC.
And I am not sure the issue will be ever fixed based on the explanation of the developers in the older thread.

Any chance it will be looked at?
Is JRiver MC not fully DLNA compliant? I am sure it's not easy to implement and most of all verify that it works with so many DLNA software/hardware.

Again not trying to create flamewar here but I believe sincerely it's either a bug or a lack of feature.

[mimizone]

So the trick for the Sony renderer is the following
https://audiophilestyle.com/forums/topic/31046-audirvana-plus-3-official-thread/?page=100&tab=comments#comment-922410

In DLNA, DSD signal is sent as an uncompressed DFF file to the network player.
Thus for a SACD ISO, Audirvana Plus uncompresses the DST compressed signal to then send the raw DSD data.
No conversion to PCM at all.
And no need for a DSD over PCM trick that eats 50% additional bandwidth for its markers, as the Core Audio PCM-only issue is no more.
The DSD compatible network players accept directly raw DSD (in DFF format).

[mimizone]

I’ve been talking with myself too much in this thread

Any chance it is something that would be implemented as an option in the DLnA server?
- Read the iso as if they were locallly played
- keep the extracted/uncompressed dff as-is
- not packaged in a DoP frame
- send it as audio/dff or something like that that some renderers like the Sony accept

Did I understand right?
Is that something complex that requires lot of development in MC?

I would be willing to try an alpha version with my Sony receiver If it helps.

[Scobie]

What you've outlined there is essentially the required setup that was outlined in the thread you linked to earlier; and I believe it is explained there why implementing it would be problematic.

Good thought though, be nice if it could do it but I think its a bridge too far.

[mimizone]

I guess you are right.