Print

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

[gulp]

Sorry, you’re right, wrong reading from my side, the new Mk II supports DoP256 now and therefore DoP could be remained checked up to 256 without the SQ problem.

[blgentry]

I don’t view a separate streamer feeding a dedicated DAC that complicated or unusual.  There are dozens of dedicated streamers available.

It is "extremely complex" because:

*  DSD is a niche format with special considerations in MC
*  DLNA uses a different way of sending DSD and has several options.  One of those options has a very confusing name (bitstream DSD) which causes everyone who reads "bitstream" to think that this is an option from the NORMAL audio section.  That option does not apply at all to DLNA.  But the DNLA option, with a nearly identical name, *does* apply.
*  DSD 256 is extra niche.  The equivalent PCM sample rate is so high that most DACs can not handle it at all.  Some streamers do, some streamers don't.
*  It's not bad enough that we have all of this, but now we are also concerned with what the streamer does when it sends the audio data to the DAC.  Does it keep it as DoPe ?  Does it convert it to regular DSD?  Is it making a decision that the DAC can not handle the format and internally converting it to PCM?  There are many variables and choices.
*  How is PCM handled in this case?  Is MC actually converting PCM to DSD due to a combination of selected options?

Thus my statement that this is extremely complicated.

Brian.

[bob]

It is "extremely complex" because:

*  DSD is a niche format with special considerations in MC
*  DLNA uses a different way of sending DSD and has several options.  One of those options has a very confusing name (bitstream DSD) which causes everyone who reads "bitstream" to think that this is an option from the NORMAL audio section.  That option does not apply at all to DLNA.  But the DNLA option, with a nearly identical name, *does* apply.
*  DSD 256 is extra niche.  The equivalent PCM sample rate is so high that most DACs can not handle it at all.  Some streamers do, some streamers don't.
*  It's not bad enough that we have all of this, but now we are also concerned with what the streamer does when it sends the audio data to the DAC.  Does it keep it as DoPe ?  Does it convert it to regular DSD?  Is it making a decision that the DAC can not handle the format and internally converting it to PCM?  There are many variables and choices.
*  How is PCM handled in this case?  Is MC actually converting PCM to DSD due to a combination of selected options?

Thus my statement that this is extremely complicated.

Brian.

That seems accurate to me except your second point about "bitstream DSD".
There's one in the audio settings, which you can't get to if you are in a remote zone anyway (the options page when you select a DLNA zone says that they don't apply) and the other in the DLNA server advanced settings (it's different because it says DoPE) which is the only one that does apply.

You have a point about the device chain. It is unknown what a DLNA renderer will do before it feeds the DAC.
An easy comparison with this is simply using an Id. You can send DSD to it but unless it has a DSD capable DAC connected and configured properly it will eventually be converted to and played as PCM.

Kind of a interesting aside, there is firmware for the iFi Nano iDSD LE DAC I'm using that enables it to receive DSD256 but the firmware explicitly says it doesn't support that sample rate (it down samples it to DSD128 transparently).

[gulp]

Investigate Zones and Zoneswitch on our wiki.

Do I see it right, that I could define profiles for DoPE or not which I could let JRiver automatically select depending on what DSD sample rate is played?

[thecrow]

That seems accurate to me except your second point about "bitstream DSD".
There's one in the audio settings, which you can't get to if you are in a remote zone anyway (the options page when you select a DLNA zone says that they don't apply) and the other in the DLNA server advanced settings (it's different because it says DoPE) which is the only one that does apply.

I have to agree with Brian, using the term "Bitstreaming" when using DLNA makes no sense to me.
Especially when used to describe DoPE which in my mind has nothing to do with bitstreaming.

[dtc]

I have to agree with Brian, using the term "Bitstreaming" when using DLNA makes no sense to me.
Especially when used to describe DoPE which in my mind has nothing to do with bitstreaming.

I guess it depends on what "bitstreaming" means for an audio file. For me, it means that no changes are made, including no DSP Studio changes. With DLNA, DSD Studio can covert a DSD file to PCM or even to another DSD sample rate. So, bitstreaming in this case means no DSP Studio and no conversion to another sample rate/format, other than DoPE.

In addition, there are countless references that you have to bitstreaming on to send DSD without conversion to PCM. So, the reference here simply reinforces that bitstreaming is also necessary for DSD in DLNA, indepedent of what is set in the Audio option for DSD.

For me, the confusing part is that there is no option for native DSD.  It works with the DoPE box unchecked, but that is not obvious and not documented except in a few forum threads.  And, unchecking it implies that bitreaming (no conversions) is not being used for native DSD. I'd like to see a Native DSD option under DLNA options along with the DoPE option.

[thecrow]

Does selecting "Bitstream DSD" i.e. convert to DoPE preclude any previous DSP or conversion?
Could I not play a mp3 file and set Specified Output to DSF to transcode it to DSD then convert it to DoPE with "Bitstream DSD", would this still be "bitstreaming"?

[dtc]

Does selecting "Bitstream DSD" i.e. convert to DoPE preclude any previous DSP or conversion?
Could I not play a mp3 file and set Specified Output to DSF to transcode it to DSD then convert it to DoPE with "Bitstream DSD", would this still be "bitstreaming"?

Quite frankly, I am not sure exactly what bitstreaming does in this case.  Yes, transcoding to DSD by DSP Studio - Audio prior to sending should be allowed but volume leveling, for example, should not be applied. Presumably, DLNA bitstreaming should handle conversions the same way as non-DLNA bitstreaming does.

[gulp]

Investigate Zones and Zoneswitch on our wiki.

I did investigate and try and the result is:
- manually adding a dynamic zone (which is needed to add a second instance of the renderer under the same IP) doesn’t seem to work generally (with whatever IP)
- DLNA renderers just seem to be added automatically during DLNA server configuration

So can I finally use Zones to switch between 2 configurations for the same DLNA device? Or does this just work for direct connected devices and no one ever tried the „add dynamic zone“ function?

[gulp]

Investigate Zones and Zoneswitch on our wiki.

Could you please tell me if a second DLNA related dynamic zone can be realized at all and why it doesn't work with the IP address of the renderer (or doesn't accept any IP)? The add dynamic zone doesn't seem to work generally in my case...

[gulp]

Thanks but I use the Mk I, which just supports DSD256 direct, not DoP..

[bob]

As far as I know you can't zone switch on remote zones.

[gulp]

As far as I know you can't zone switch on remote zones.

With remote zones you mean DLNA based renderers? So then there’s no solution in JRiver to automatically switch between a DoP and DSD direct DLNA configuration, based on different DSD sample rates? (play DSD direct config for DSD256 and DoP for all other files)

[bob]

With remote zones you mean DLNA based renderers? So then there’s no solution in JRiver to automatically switch between a DoP and DSD direct DLNA configuration, based on different DSD sample rates? (play DSD direct config for DSD256 and DoP for all other files)

That appears to be the case. There are no individual bitrate options for DoP wrapping.
If your renderer is operating properly you shouldn't able to hear any difference between the 2 since there is no encoding going on.

[gulp]

I thought I could manage this over Zone switching. And it seems the only reason that this doesn’t work is that two different DLNA server configurations can’t be linked to one renderer configuration (dynamic zone).

All that although theoretically an additional dynamic zone can be created for an IP address…it just doesn’t seem to work (as nothing happens when an IP is used as instructed). Is this a bug or how should that work?

[JimH]

You've  had so much trouble getting going with what you're trying to do that I'm reluctant to try to help. 

Did you read the Zoneswitch section of the wiki topic on Zones?
https://wiki.jriver.com/index.php/Zones

and the link there?
https://yabb.jriver.com/interact/index.php?topic=76605.0

[bob]

You've  had so much trouble getting going with what you're trying to do that I'm reluctant to try to help. 

Did you read the Zoneswitch section of the wiki topic on Zones?
https://wiki.jriver.com/index.php/Zones

and the link there?
https://yabb.jriver.com/interact/index.php?topic=76605.0

Pretty sure you can't zoneswitch on remote zones.

[gulp]

You've  had so much trouble getting going with what you're trying to do that I'm reluctant to try to help. 

Did you read the Zoneswitch section of the wiki topic on Zones?
https://wiki.jriver.com/index.php/Zones

and the link there?
https://yabb.jriver.com/interact/index.php?topic=76605.0

Thanks Jim that you try to help anyway!

Actually I think the main discussion giving the impression I have lots of problems,  was just the confusion about the Bitstreaming meaning and naming of the checkbox, which even was confusing to some of the admins.

Now I have a problem which again might be interesting for the admins.

I really have read all those threads and what’s described there is about topics before or after my problem.

Mine is not discussed anywhere and hardly described in the wiki. It’s if and how I can add a second (dynamic) zone for the same DLNA based renderer that was automatically added during DLNA server config, to later zone-switch between both. Did anyone try this before? If this is not possible, the whole zone-switch scenario you recommended is no solution in case of a DLNA connected renderer unfortunately.

[bob]

...
Mine is not discussed anywhere and hardly described in the wiki. It’s if and how I can add a second (dynamic) zone for the same DLNA based renderer that was automatically added during DLNA server config, to later zone-switch between both. Did anyone try this before? If this is not possible, the whole zone-switch scenario you recommended is no solution in case of a DLNA connected renderer unfortunately.

You cannot. Zone switch isn't for remote (DLNA) zones.

[gulp]

You cannot. Zone switch isn't for remote (DLNA zones).

Thanks Bob, so I guess there’s also no solution for a half-automated activation/deactivation of the DoP checkbox in DLNA server settings, right?
So finally I will have to manually change this setting every time I play a DSD256 file.

[bob]

Thanks Bob, so I guess there’s also no solution for a half-automated activation/deactivation of the DoP checkbox in DLNA server settings, right?
So finally I will have to manually change this setting every time I play a DSD256 file.

You should probably spend your time trying to find out why your renderer plays DoP files and DSD files which are exactly the same, differently.

[gulp]

You should probably spend your time trying to find out why your renderer plays DoP files and DSD files which are exactly the same, differently.

More so the difference between PCM files with these settings (of which they shouldn’t be affected at all). Confusing. I guess I’ll never find out because both sides say it csn’t have to do with their part.

[gulp]

A solution would be if there’d be an option of a rule based switch between 2 different DLNA library server links to a DLNA renderer. I now have to select that manually. It’s the best way instead of going into DLNA settings menu each time.

[blgentry]

Speaking for myself only:  I don't think you actually hear a difference in PCM files.  I think that you think you do.  If you do some blind testing, controlled by someone else, I think you'll find that you can't tell the difference.  There's no logical reason that anyone here can come up with for a difference in PCM playback by using different DSD options. 

I humbly suggest that you hear a difference because you want to hear a difference.  Be honest with yourself.  Do a test.  Let us know.

Brian.

[gulp]

I did and still do, really. I just found out because I wondered about a sound difference and didn’t know where it suddenly came from. There’s no reason to want this.
If I would have had any guess, then that it’s the other way around…that direct sounds better than DoP.

[gulp]

For those interested, one of the best DAC developers told me what I probably hear when hearing sound quality differences between DOP and direct DSD. It’s the completely different processing, clock frequency, sample rate and noise pattern. What we didn’t solve is, why I also hear differences with PCM files when DOP is or is not chosen.

[dtc]

For those interested, one of the best DAC developers told me what I probably hear when hearing sound quality differences between DOP and direct DSD. It’s the completely different processing, clock frequency, sample rate and noise pattern. What we didn’t solve is, why I also hear differences with PCM files when DOP is or is not chosen.

Once a DAC receives a packed DoP signal it needs to unpack it and make it back into a high sample rate, single bit DSD format. That is done before the D to A process is done.Once unpacked is should go through the same D to A conversion process as a native signal. So, if there is any difference in noise, etc. in DoP versus Native sound, it seems like it is introduced in the unpacking of the bits, not in the DSD D to A process.  Incidentally, native format also needs to be unpacked, just from a different packed format. Native is not sent as a single bit 2.844 Mhz (multiple of that signal).

So

Different processing - only in the unpacking of the bits.

Clock Frequency and Sample Rate - only in the front end. The D to A conversion should be the same.

Noise pattern - only in possible electrical noise in the front end. The D to A conversion should be the same.

So, I am not sure what he is saying.

[gulp]

I cite him here, I just can't and don't want to argument for/against him:

"The noise created in the PC is certainly different for DoP and Native DSD. They process at fundamentally different frequencies and that noise can be radiated from the PC, put on the AC mains by the PC or conducted or radiated by the interconnect from the PC to the DAC. All of that has a lot more to do with the PC or interconnects than the DAC or the source software.

In general DoP causes less noise in the PC and AC mains because the sample rate thruogh most of the player software is 16 times slower. But the bit clock for DoP is running 50% faster than the Native DSD bit clock so the noise or RFI might be higher over the interconnect. With DLNA in the circuit the packet noise could go either way."

[JimH]

Nobody wants to argue, but I don't buy the "noisy PC process" theory.

[gulp]

ok. I just meant I can't discuss it due to lacking deeper knowledge...no reason to argue indeed ;-)

[Awesome Donkey]

Nobody wants to argue, but I don't buy the "noisy PC process" theory.

Me neither. Pretty sure this kind of audiophile myth has been long debunked, especially with modern PCs and components. In fact, here's a recent video about a "noise power filter" audiophile scam getting tested and debunked: https://www.youtube.com/watch?v=Bc422iIvCcY

[gulp]

To be honest, I‘d rather say in high performance audio there meanwhile were more true side effects found than we previously ever imagined.

Nobody thought of jitter when digital began, nobody about the importance of power supplies, nobody of the influence of EMI, RFI and all that…and even today’s PC‘s and stuff is not protected against it.

But all that certainly isn’t revealed by every kind of audio equipment. Lucky who doesn’t hear it ;-)

[dtc]

Ah, so he is talking about electric noise in the PC (not in the DAC) and speculating that that electric noise is passed to the DAC and that effects the sound.  That is an old discussion with people on both sides of the issue, although most people think the effect is too small to be significant for a well-designed DAC.  Galvanic isolation in now pretty standard on lots of DACs. That should eliminate any electrical noise on the interconnects. As to passing the noise via the mains, that can happen but it is a very small effect. Noise in the DAC caused by RF from the PC is also a very small effect. And, if the DLNA is wireless connected and in a different room, mains noise is probably extremely small if it even exists and the interconnect noise should not exist.

This electrical noise from a PC has been measured on the ground plane of a DAC (although the case I know of was several years ago and was probably not done with galvanic isolation) but I don't know that anyone has ever really shown how that effects the sound. Different DACs would react to that noise differently, so if you hear the same difference between DoP and native on different DACs (especially wireless DLNA), that strongly suggests that this electrical noise is not the source of the difference.

So, honestly, I doubt the effects he is describing has any significant effect on the sound difference you are reporting.

[gulp]

I’m open for any reason why I hear the differences and I agree, the fact that I also hear them from PCM is weird and difficult to reason.

The more relevant point for here is, that because I hear it and because I have to use direct for DSD256 and want to use DOP for everything below, I need to switch „association with DLNA server“ from JRemote for convenience reasons, not only from JRiver.

With MConnect this is possible, but not with JRemote. I hope someone of the development team has mercy and can integrate it!