Print

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

[depechefan]

Hi,

I've been searching this forum and it seems that some people have been able to send DSF files to a Sony STR-DN1080 receiver using DLNA. I haven't been able to so I hope someone can help. I've installed newest version of JRiver. I can send MP3 files to my receiver but when I try with DSF files I get the error "There was a problem controlling the selected DLNA device. Please double-check your device, servers and network settings". Not sure how to proceed. I can play DSF files via USB directly plugged into the receiver.

Thanks in advance for any help.

/M

[Awesome Donkey]

Did you enable DSD-over-DLNA (DoPE)?

https://wiki.jriver.com/index.php/DSD#DSD_Over_DLNA

[depechefan]

Hi,

Thanks for the reply. I must be doing something wrong because I can't find that setting. I have the options you can see in the attached file. I must admit that I find the interface difficult to navigate so I'm most likely missing something.

Thanks again
/M

[depechefan]

Hi again,

So I managed to find that setting you mentioned. Now I'm actually able to start playback without an error. However it looks like it's sending PCM to the receiver rather than the original DSF file. And I hear only a faint hissing sound. See attached picture. Also the metadata seems to be mostly missing - not a huge deal. I've tried to choose to send PCM as well but the result seems to be the same.

So all in all still a bit confused...  ?

P.S. I have just tried to install Serviio because I read that someone had better luck with that server. That worked with the default settings. All files I've tried so far are playing at the native quality...

/M

[dtc]

DSD over DoPE (DSD over PCM Ethernet) is an alternative way to send DSD data. It is meant for systems that do not handle DSD's high sample  rates, including Apple systems.  Some receivers understand it and some do not.  Sounds like your Sony may not.

DoP packs the 0s and 1s of a DSD file into a PCM form and then the receiver unpacks the bits into the DSD form. It uses 16 bits of each sample for the 0s and 1s and 8 bits to identify the stream as DSD.  The 8 bit identifier is set so that if the receiver does not recognize the DoPE format and plays it as PCM rather than unpacking it then you hear a low hiss.  It sounds like that is what is happening when you use DoPE. Your receiver does not seem to recognize the format.

Your picture shows 176K PCM, which corresponds to 2.8 MHz DSD (2,822,400/16 - since there are 16 bits of DSD data in each PCM sample).

Sorry, I cannot help with the rest of the problem.

[Awesome Donkey]

A total shot in the dark, but one thing you could try (if you're not already doing it) is set MC's internal volume (and maybe even system volume) to 100%, as that's required in some cases to get DSD playback working when bitstreaming, otherwise you could just hear faint sound like you are.

[depechefan]

Hi,

Thanks a lot for the replies. Very helpful. Feels like sticking with Serviio is probably the easiest. Only thing I'm missing in that application is a way to shuffle songs in my playlists and that's definitely less important to me than the sound quality :-)

Thanks again!
/M

[AndrewFG]

Please download the DMRA from my sig; run the test; and post the renderer report here..

[depechefan]

Hi,

Report attached.

/M

[AndrewFG]

Ok. The report confirms your receiver can play DSD media. However it does not give any information about the “flavours” of DSD that it supports (i.e. DSF, DFF or DOPE). So it does not really help us solve your problem (sorry for that).

You tried pushing DOPE and apparently that did not work. And apparently neither did 2x DSF work. So I would suggest trying a) 1x DSF (rather than 2x or 4x DSF), or b) DFF formats to see which of those, if any, do actually work.

Otherwise you may have to set MC DLNA server to convert your tracks to PCM (with header) aka WAV on the fly.

[depechefan]

Hi,

Thanks for checking. Serviio works out of the box so will probably stick with that. Just would be great to have a nicer controller for sending music to the receiver. The built-in browser/player in the receiver isn't very sexy :-)

/M

[AndrewFG]

If you could figure out what Servio is actually pushing, then we might figure out how to get MC to do the same..

..but you would need to do a trace on your network. Do you know Wireshark? If so then a Wireshark trace of the traffic between Servio and the renderer at the time you start to push play a track would help.

[depechefan]

Hi,

Sure, I will give it a go. Haven't used WS in ages so might take me a little while :-)

/M

[depechefan]

Hi,

I've made an attempt. Not sure if it means anything to you - I couldn't see much (other than a few lines mentioning audio/dsd). But this is the receiver grabbing the file because I can't figure out how to get Serviio to playback on the receiver...

And it seems that I can't post it. The attachment is too big. See attached screenshot with the most relevant info.

/M

[AndrewFG]

Thanks for trying the tests. Several things..

1) You said that Servio cannot push to the Sony: So are you saying really that Servio is NOT performing any better than MC? If that is the case, then there is not much benefit in getting MC to behave like Servio. Or??

2) But you said that the Sony CAN pull from Servio: So did you try having the Sony pull from MC? (there is no point comparing apples with bananas..)

Notwithstanding the above, we may be able to make some progress with the Wireshark traces. BUT your trace is unfortunately not enough; it shows a GET for an xml file followed by an HTTP response for the DSD media track. So we will need to see the GET for the media track, and also the respective HTTP response. You will need to locate the GET visually by hand, and then you can right click on it and select to follow the TCP or HTTP session. This will open a window which shows the full content of the GET including the HTTP headers, plus also the full content of the HTTP response with its headers too.

[depechefan]

Hi,

What is working is scenario 2. My receiver can pull. Just tried using BubbleUpnp as a remote to push content to the receiver via Serviio and it works like a charm. Receiver shows "Native DSD".

I'll have a look at the trace again and see if I can figure it out.

For my use case Serviio definitely works much better (actually perfect) than JRiver.

/M

[dtc]

Just an FYI - "Native DSD" has two separate meanings. One, it means the the content is in fact DSD, not DSD converted to PCM. Second, it means that the transport is native DSD speed - that is sample rates like 2.8/5.6 MHz, rather than the corresponding DoP sample rates of 176/352 KHz.  Hard to know which it is using on your receiver, without comparing it to other displays.  If the comparable display says things like PCM or MP3, it is probably case 1. If the comparable display is the same rate, it could be the second, although you would think it would then say the sample rate in MHz.

Anyway, just a caution.  But, in any case, it seems you are clearly getting DSD from Bubble and Serviio.

[AndrewFG]

What is working is scenario 2. My receiver can pull.

So did you try pulling from MC?

[RoderickGI]

Poor old Sony. No wonder they struggle to compete. They just can't keep up. (BTW I have a 1999 Sony Receiver and a 2015 Sony 65" TV).

From their very poor manual:

================================================
Formats compatible with home networks
Supported music formats (*1)
MP3 (MPEG 1 Audio Layer-3):
.mp3
AAC/HE-AAC (*2):
.m4a, .aac
WMA9 Standard (*2):
.wma
LPCM:
.wav
FLAC:
.flac, .fla
DSF (*2):
.dsf
DSDIFF (*2)(*3):
.dff
AIFF (*2):
.aiff, .aif
ALAC:
.m4a
Vorbis
.ogg
Monkey’s Audio
.ape
*1Compatibility with all encoding/writing software, recording devices and recording media cannot be guaranteed.

*2The receiver may not play this file format on the home network server.

*3The receiver does not play DST encoded files.

Note
Some files may not play depending on the file format, the file encoding, the recording condition, or home network server condition.
Some files that have been edited on a computer may not play.
Fast forward or fast reverse functions may not be available for some files.
The receiver does not play coded files such as DRM and Lossless.
The receiver can recognize the following files or folders stored in the home network server:
up to folders in the 19th layer
up to 999 files/folders in a single layer
================================================


I would be very surprised if Serviio can push DSF files to the receiver, which can then play them, and MC can't. Either Serviio is sending LPCM, which has been reported previously, or there is some incorrect setting in MC.

Please test each option using exactly the same files, given what the receiver manual has to say about DSF files.

[depechefan]

Hi,

So in my case using Serviio definitely works like a charm so the above doesn't really apply but I can see why it's difficult to guarantee that DLNA & DSD will work... I'm certain that Serviio sends the raw DSD file to the receiver. Funny thing is that the receiver sees the DSD file from JRiver as WAV even though settings are configured to send the original.

I've compiled some information in the attached files. Good luck :-)

/M

[dtc]

Hi,

 Funny thing is that the receiver sees the DSD file from JRiver as WAV even though settings are configured to send the original.
)

JRiver is sending DoP which the receiver seems as PCM but it is actually the DSD bitstream packaged in a PCM format, as I explained above.  It appears your receiver is not decoding the DoPE format. If you want to send the native DSD file at native DSD sample rates, you uncheck the DoPE box.

Details on DoP here

https://dsd-guide.com/dop-open-standard

[depechefan]

Hi,

I think I've tried all possible settings to get the DSD file to the receiver. Whether I use DoPE or not makes no difference. (Look at reply #3 in this thread).

/M

[AndrewFG]

You showed a screenshot of your MC server settings concerning DOPE, but can you please also post the screenshot showing the MC server settings for AUDIO Conversion?

Also I don’t recall exactly, but I think somewhere in the MC server settings there is a setting called MimeType (or something like that), can you please send a screenshot of that part too?

Finally thanks for the Wireshark captures concerning the Pull from Servio. But can you please show me the upper part of that capture that includes the GET request? (Your picture shows only the HTTP 206 response but not the GET request).

And can you then please try a Pull from MC and also show the respective GET and HTTP 20x responses as well?

EDIT: the fact that you have the MC server profile “Audiophile 24bit DAC” selected, makes me think that you might have the MC server set to Always Convert Audio to L24 (PCM no header), and if that is the case, then a) the Sony would almost certainly display “LPCM” on your playing now screen, and b) it would almost certainly fail to actually play anything (regardless of what DOPE settings you may have)..

[depechefan]

Hi Andrew,

I'll try to get you that info. Probably not tonight though... The WS captures are for a pull request.

/M

[AndrewFG]

I added some additional text in RED in my prior post above.

And yes I know that the captures are for a Pull..

[dtc]

If MC were converting DSD to PCM it would convert 1x DSD (2.8Mhz) to 352 KHz PCM. The screen shot shows 176 KHz, which is consistent with DoP. A DSD to PCM conversion of 1x DSD would only get to 176 KHz PCM if there is a conversion set in DSP - Outut format to convert 352 KHz to 176 KHz.

[depechefan]

Hi,

The extra settings you asked to see. I can't fine mime types anywhere.

I tried to locate other http requests but all I see is 206. I might have filtered something out in my capture because I specified that I only wanted traffic going to a specific port. So might have to try again I guess...

/M

[AndrewFG]

If MC were converting DSD to PCM it would convert 1x DSD (2.8Mhz) to 352 KHz PCM. The screen shot shows 176 KHz, which is consistent with DoP. A DSD to PCM conversion of 1x DSD would only get to 176 KHz PCM if there is a conversion set in DSP - Outut format to convert 352 KHz to 176 KHz.

The screen shot says “LPCM / 24 bit” which IMHO is NOT consistent with DOPE over L16 or WAV L16..

[AndrewFG]

The extra settings you asked to see.

Could you also expand the “Advanced” tab please?

[dtc]

The screen shot says “LPCM / 24 bit” which IMHO is NOT consistent with DOPE over L16 or WAV L16..

DoPE is, by definition, 24 bit. It cannot be 16 bit.

The DoPE setting may override the Format setting, but that is speculation. I have not tried it. But with DoPE set, it should not send 16 bit data.

[dtc]

Could you also expand the “Advanced” tab please?

With Original set, there should be no options available under Advanced.

[Scobie]

With Original set, there should be no options available under Advanced.

Think Andrew is referring to the Advanced tab at the bottom of the frame, not the one under Audio. The one at the bottom has the DSD bitstream checkbox and other DLNA options.

[RoderickGI]

This is very strange. BubbleUPnP can push Native DSD from the Serviio server to the STR-DN1080, which proves the STR-DN1080 capability.

MC should have "Bitstream DSD (requires DoPE compliant renderer)" turned off, which was Depechefan's original setting, and it should have just worked, as long as Audio was set to "Original".

If you turn on "Bitstream DSD (requires DoPE compliant renderer)" then you are sending the DSD file in DoPE format, and you must have the MC volume set to 100%, or else you will just get a hiss or white noise. But I'm not sure that the STR-DN1080 supports DSD over DoPE anyway, so that may not work. Note that normal audio devices have a setting of "Maximize device volume during playback", but DLNA servers do not, so you must manually maximise the volume in MC. Maybe that could be improved in future?



Andrew the Mime Type Override at the bottom of the "Advanced" settings group only applies to video by the look of it. Hopefully, there is no spillover into audio.

I have experienced some issues with DLNA settings changes not seeming to take effect, particularly if I haven't set them and then OK'd my way completely out of the dialogue. The obvious example in the "Display name" of the DLNA server, which doesn't change in the top list until the DLNA configuration dialogue has been closed and reopened. Maybe try turning off "Bitstream DSD (requires DoPE compliant renderer)", setting Audio to any "Specified Output Format", saving that by OKing out of the dialogue, then reopen the dialogue and set it to "Original", OK out again and test DSD Push playback to the STR-DN1080.

Also Depechefan, do you have a OneDrive, Google Drive, DropBox or other account that you could put a Wireshark log on, so that Andrew could see the whole thing? (Sorry to dob you in Andrew ) It seems a waste of time to keep requesting screenshots.


I would appreciate knowing if the Sony STR-DN1080 is capable of Native DSD playback from MC, as that may well be one of my options in the future. I tend to buy Sony gear, though I can't think why really, and their manuals are just awful so it is hard to know what they are really capable of.




JRiver: It would be great if the DLNA Server dialogue was resizable, at least vertically, so that a user could expand all sections and the dialogue, and hence post a screenshot of all settings in one go. It would help with this sort of user support a lot. It has been a problem in lots of past threads. There seems to be no reason not to allow dialogues to be resizable. Thanks.

[RoderickGI]

Okay, the STR-DN1080 seems to be a bit quirky. This problem was actually solved a couple of years ago. See https://yabb.jriver.com/interact/index.php?topic=111822.0

The "C:\Program Files\J River\Media Center 25\Data\Default Resources\FileAssociations.xml" file now contains these three lines:

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

I think that should have fixed the issue in that thread above. But maybe not. So try this if nothing above works.

1. Make a copy of the "FileAssociations.xml" file so that you can revert to the original if required.
2. Shut down MC and the MC Media Server if it is running. Also, make sure Serviio and any of its services aren't running. As a separate issue, you shouldn't have an DLNA server running on a NAS, if you use one. We haven't even confirmed you are running MC on Windows, where your files are, how you imported them and so on. Maybe if this doesn't work we should do all that. But later.
3. Edit the "FileAssociations.xml" and change the above three lines to:

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

4. Restart MC and test again sending Native DSD (not DSD over DoPE) and see if that works.
5. If 4. didn't work, close MC and Media Server, edit the "FileAssociations.xml" and change the above three lines to:

      <Item Name="dff">audio/dff</Item>
      <Item Name="dsf">audio/dsf</Item>
      <Item Name="dsd">audio/dsd</Item>

6. Restart MC and test again sending Native DSD (not DSD over DoPE) and see if that works.


Report back what happened.

[Matt]

JRiver: It would be great if the DLNA Server dialogue was resizable, at least vertically, so that a user could expand all sections and the dialogue, and hence post a screenshot of all settings in one go. It would help with this sort of user support a lot. It has been a problem in lots of past threads. There seems to be no reason not to allow dialogues to be resizable. Thanks.

Good idea.

Coming next build:
Changed: Made the DLNA servers dialog larger and made it sizable.

[RoderickGI]

Thanks Matt!

[depechefan]

Hi,

I've tried to change the mime types to match the above-mentioned suggestions. restarted the JRiver service and disabled DoPE. in the Advanced section of the Media Network settings. The basic setting is "Mode: Original". When I browse to the folder containing the DSF files I get a message saying that there are no playable files in that location. I'm happy to do some more troubleshooting but it seems to be very complicated to make this work. I'm using Windows 10 as my OS. The files are stored locally on the PC.

I'll try to make a new capture and upload to Onedrive. Thanks for that suggestion.

P.S. This is mostly because it's an interesting mystery. Tbh. I'm happy with Serviio so...

/M

[depechefan]

Hi,

Here is a complete capture of a pull request for a DSF file from the Sony receiver to Serviio:

https://1drv.ms/u/s!Aly2HCHRkhMrjIJ0Xaj4sNaaIU2koQ?e=LtHvlb

/M

[AndrewFG]

DoPE is, by definition, 24 bit. It cannot be 16 bit.

The DoPE setting may override the Format setting, but that is speculation. I have not tried it. But with DoPE set, it should not send 16 bit data.

Look. One thing is clear from the DMRA renderer report: the Sony will NOT play L24 audio. So if the OP is trying to push anything in an L24 wrapper (be it PCM or DOPE) it will simply NOT play. It’s got nothing to do with the DOPE setting in MC; it is about the lack of L24 capability of the renderer...

[RoderickGI]

That's okay Andrew, because the STR-DN1080 doesn't support DSD using DoPE, only Native DSD. So, no 24 bit processing required.

The STR-DN1050/70/80 range seems to need a specific mime type to work. The internet is full of discussions about the STR-DN1050/70/80 and how to make them play DSD. The Minimserver DLNA solved the issue back in 2010 from memory, and Serviio solved it sometime after that, after a bit of a rocky period. Hence my suggestion above.

JRiver seem to have added the right mime types to the FileAssociations.xml file, but both audio/x-dsf and audio/dsf are included, which the STR-DN1080 may not handle correctly. Hence my suggestion above.

Depechefan, you say you tried changing the mime type. Did you try both versions I documented? Completely restart MC between changes?

[depechefan]

Morning,

Yes, I tried both options for the mine types. It's weird that it didn't fix it. I restarted the service and I even tried restarting the PC.

A question about 24 bit because I can play 24 bit flac files but maybe that's different?

/M

[Scobie]

Not from the manual but from the website https://www.sony.com.au/electronics/av-receivers/str-dn1080/specifications:

Decoding Format for USB/Network Client
HI-RES FORMAT
DSDIFF (DSD): Up to 5.6MHz 5.1ch , DSF: Up to 5.6MHz 5.1ch , WAV(LCPM): Up to 192kHz/24 bit 7.1ch,AIFF(LCPM): Up to 192kHz/24 bit 5.1ch, FLAC: Up to 192kHz / 24 bit 5.1ch , ALAC: Up to 192kHz / 24 bit 5.1ch

[RoderickGI]

A question about 24 bit because I can play 24 bit flac files but maybe that's different?

Yep, that's different, because you are sending the FLAC files themselves to the STR-DN1080 and it is doing the decoding, hence it handles the 24 bit issue. That is because you have the DLNA Audio Mode set to "Original", which means MC doesn't do anything to the media it is sending, and just sends the FLAC file. DLNA is a file-based protocol. There is no 24 bit PCM involved in the transfer from MC to the STR-DN1080.

You can simply test or confirm this by changing the DLNA audio settings to "Specified Output Format" and trying to play a 24 bit FLAC file using the formats "PCM L24 No Header" and "PCM 24-bit". MC will then decode the FLAC file to 24 bit PCM and send that to the STR-DN1080. Neither should play correctly.

WAV(LCPM): Up to 192kHz/24 bit 7.1ch

That bit is interesting. Although again for DLNA, a WAV file would be sent to the STR-DN1080, which would then do the decoding. This is different to MC sending 24 bit LPCM, which is what DSD using DoPE requires. According to the DMRA report the STR-DN1080 only supports L16, which is 16 bit LPCM without a header, I believe. WAV files are LPCM with a header anyway I believe, so a slightly different format.

If you run the DRMA against MC, you will see it support various versions of "L24", or 24 bit LPCM. For example, it declares support for the following formats and more;

http-get:*:audio/L24;rate=192000;channels=8:DLNA.ORG_PN=LPCM
http-get:*:audio/L24:*
file:*:audio/L24:*

MC is evaluated to support those formats as well.


Andrew, feel free to correct any of the above, because I'm no expert on this stuff.


I think the only way forward is to work out what mime type Serviio is sending to the STR-DN1080, and make MC do the same. I haven't looked at the Wireshark log, and may not be able to make sense of it anyway.

[AndrewFG]

I think the only way forward is to work out what mime type Serviio is sending to the STR-DN1080, and make MC do the same. I haven't looked at the Wireshark log, and may not be able to make sense of it anyway.

Indeed. I am planning to look at the Wireshark capture later today.

[AndrewFG]

Here is a complete capture of a pull request for a DSF file from the Sony receiver to Serviio:

https://1drv.ms/u/s!Aly2HCHRkhMrjIJ0Xaj4sNaaIU2koQ?e=LtHvlb

Sorry but this is not a complete capture. It only shows half of the dialog — namely it only shows messages sent from the pc (192.168.1.30) to the renderer (192.168.1.233). But it does not show any messages sent from the renderer to the pc.

In order to diagnose your problem, I need to see both sides of the dialog — specifically to see what file the renderer is requesting (the GET) and the respective matching response from the Servio server.

I guess that you made your capture with a capture filter like src=192.168.1.xxx or dst=192.168.1.xxx and both those filters will only capture one side of the dialog (either from the source or to the destination). Instead you need to set a capture filter like host=192.168.1.xxx which will capture the traffic in both directions to/from the given device. (So I suggest host=192.168.1.233 should get everything to and from the Sony).

[depechefan]

Hi,

OK, that could well be. I'll make a new one when I get home :-)

/M

[depechefan]

Hi Andrew

This one looks better, I think:

https://1drv.ms/u/s!Aly2HCHRkhMrjIJ1lv75FG2r2xnROg?e=Qftb9E

/M

[RoderickGI]

I had a look at the Wireshark log just to see if I could work out what was going on. Just curious. Learning.

It looks like the STR-DN1080 requests a DSF file, but Serviio sends back a mime type of DSD. See attached image with highlights.

So maybe the FileAssociations.xml file needs to read;

      <Item Name="dsf">audio/dsd</Item>

Or perhaps even more fully;

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


In other words, the mime type for Native DSD needs to be set to audio/dsd, regardless of the file container it is in.

Maybe the references to x-dsd could be dropped as well. Guessing a lot here. But Serviio is just using a mime type of audio/dsd.


What do you think Andrew?

[depechefan]

Hi Roderick

Yeah, I had the same thought when I looked at the capture. Just tried to change the mime types to audio/dsd for dsf files. And it actually works :-)

So if anyone is interested or has the problem I have attached my fileassociations.xml file. (If you want to use this then change file type from .txt to .xml)

Thanks for the great assistance!

/M

[AndrewFG]

Thanks for posting the capture. I can confirm your findings. The essential part is below. The renderer does a GET for the file, and it says it will accept any mime-type “Accept: */*”. And the Servio server responds with “Content-Type: audio/dsd”. And this seems to work.

I suppose MC is returning another Content-Type; that the renderer does not accept; even though the Sony says it would accept */* (!!). This means that the Sony is at fault, because if it cannot Accept: */* then it should say so — for example by saying Accept: audio/dsd. If the renderer was explicit then server could respond explicitly too. Otherwise the server has to make a best guess at what it should send. In this case Servio made a lucky guess, and MC did not.

You should inform Sony about this..

Code: [Select]

GET /resource/3225/MEDIA_ITEM/DSF-0/ORIGINAL HTTP/1.1
Host: 192.168.1.30:8895
Accept: */*
Range: bytes=0-15
X-AV-Physical-Unit-Info: pa="STR-DN1080"
X-AV-Client-Info: av=5.0; cn="Sony Corporation"; mn="STR-DN1080"; mv="2.0"
getcontentFeatures.dlna.org: 1
transferMode.dlna.org: Streaming
 
HTTP/1.1 206 Partial Content
Content-Length: 16
Content-Type: audio/dsd
Cache-control: no-cache
Connection: close
Content-Range: bytes 0-15/253534447
contentFeatures.dlna.org: DLNA.ORG_PN=DSF;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000
Date: Thu, 26 Sep 2019 17:25:26 GMT
realTimeInfo.dlna.org: DLNA.ORG_TLAG=*
Server: Windows_10 UPnP/1.0 DLNADOC/1.50 Serviio/2.0
transferMode.dlna.org: Streaming
 
DSD ............