INTERACT FORUM
More => Old Versions => JRiver Media Center 31 for Windows => Topic started by: gulp on October 16, 2023, 05:22:01 pm
-
When I check bitstreaming within DLNA settings, only up to DSD128 can be played flawlessly. When I play DSD256, there's mainly hiss and very faint music playing. My streamer/DAC does support DSD256.
Any idea what happens or has to be configured? Unchecking bitstreaming works then for DSD256, but all kinds of files sound much worse then as they are processed via JRiver, not the DAC, so that's no solution unfortunately.
-
DAC's don't always play what they claim to play. It may also be different for DLNA vs a direct connection. Did you try the manual or the manufacturer?
Concerning other files, make sure the server isn't converting to MP3.
-
Thanks, I ensured, the server isn’t converting.
The Streamer and DAC play DSD256 over Roon/DLNA.
So there’s no limitation in JRiver to DSD128 when using DLNA and checking the bitstreaming/DOPe box, right?
-
If you use DLNA, don't use bitstreaming.
-
Ok, but (at least for a high end system) this means unusably bad sound quality.
So is it really a limitation in JRiver to DSD128 by bitstreaming, so that for DSD256 in appropriate sound quality a different SW has to be used? Or is there a way to fix this in future?
-
It's not a limit of JRiver. Other devices work up to 512.
-
Ok you mean other devices work up to DSD512 as DLNA source and with Bitstreaming checked? If so, then it in fact seems, the device has the problem (at least with JRiver).
-
Did you try a USB connection?
-
The PS Audio Airlens is a HDMI/I2S and coaxial only unit (towards DAC) and network DLNA/uPnP only (towards the server/PC). I use I2S connection towards the PS Audio DAC, which supports DSD256 native.
-
Thanks, I ensured, the server isn’t converting.
The Streamer and DAC play DSD256 over Roon/DLNA.
Roon isn't using DLNA. It doesn't support DLNA.
-
DAC's don't always play what they claim to play. It may also be different for DLNA vs a direct connection. Did you try the manual or the manufacturer?
?
-
Roon isn't using DLNA. It doesn't support DLNA.
Sorry, my wrong assumption then.
-
?
Yes, the streamer can only be connected via DLNA/uPnP, not directly. It’s based on a Converse module CDM4140.
https://cdn.shopify.com/s/files/1/0672/2283/1394/files/AirLens_Manual_A-5.pdf?v=1693598741
http://conversdigital.com/kor/product/product01.php
-
The faint music and hiss is an indication that your DAC is not recognizing the DSD signal that is being sent. That is part of the DoP design. However, you should not be using DoP for DSD512. You need to use native DSD at that sample rate.
For DLNA, uncheck the Bitstream DSD (DoPE required) box in Media Server - Add or configure DLNA Servers- Advanced for the DLNA server you are using.
If you are using a direct connection to the DAC, you need an ASIO driver to do native DSD. WASAPI only works with DoP. Bitstreaming for DSD needs to be checked.
EDIT: It looks like the Airlens supports DSD256, but not DSD512. And, it looks like the Airlens supports DLNA but not a direct connection from JRiver or Roon.
EDIT: Sorry, you are only doing DSD256, not DSD512. My mistake.
-
I already configured DLNA server, that’s the only way I can connect. There I checked Bitstreaming and it gives the noise for DSD256 with faint music signal, but plays up to DSD128 flawlessly. As soon as I uncheck Bitstreaming within the DLNA configuration, DSD256 works, but sound quality is much worse (I don’t use any down or upmconversion).
I can only use DOP up to DSD128, up to DSD256 direct.
Do you finally say that from JRiver side, DSD256 by DLNA with Bitstreaming checked is possible with other HW? Or just direct connected?
-
EDIT: It looks like the Airlens supports DSD256, but not DSD512. And, it looks like the Airlens supports DLNA but not a direct connection from JRiver or Roon.
EDIT: Sorry, you are only doing DSD256, not DSD512. My mistake.
Exactly.
That’s why I try to find out if the limitation over DLNA+Bitstreamimg comes from JRiver or any other reason.
-
DSD256 with DoPE requires a PCM sample rate of 705 KHz per second, which the Airlens does not support. DSD128 with DoPE uses a sample rate of 352 KHz per second which the Airles does support. So, by the checking the DopE box, you are limited to DSD128. If you uncheck that box, MC will send native DSD, which the Airlens should support.
Not sure why DSD256 native does not stream well. How is your WiFi speed? I am pretty sure others have used DSD256 with DLNA successfully, but would have to check. I don't think it is a MC issue, but possible a WiFI issue.
-
I thought checking the Bitstreaming box means the JRiver engine is not used and it’s sent directly and when unchecked, JRiver engine is used to decode…at least that was my explanation why unchecked sounded worse.
I use LAN connection, so it shouldn’t be an issue.
-
Actually, I believe unchecked sends the DSD in native mode, where checked it is converted to DoP.
Direct means it is not converted either to PCM or DoPE, but rather sent as native DSD.
If by LAN you mean hard wired Ethernet, then I do not know why it sounds worse.
-
Do you have Mode set to Original in the DLNA server setup. If it is converting DSD to PCM that could cause the high sample rate problem.
-
Yes I have…what should it be with Bitstreaming unchecked?
-
It should be original, so I am not sure what the problem is. Does you DAC report what format it is getting?
-
Yes I have…what should it be with Bitstreaming unchecked?
Audio Settings->Bitstreaming is meaningless when sending to a DLNA device.
Only the DLNA server settings are used.
-
It should be original, so I am not sure what the problem is. Does you DAC report what format it is getting?
Thanks for your support guys, that's great!
It took some time until I verified my findings, so here we go:
1. When checking Bitstreaming under DLNA options and chosing "original" as format, the DAC shows it get's DOP as DSD64 or DSD128. When playing DSD256 files it shows it get's PCM384 and plays white noise with faint music signal.
2. When unchecking Bitstreaming under DLNA options and chosing "original" as format, the DAC shows it get's DSD as DSD64, 128 or 256 an plays the latter properly as DSD.
PCM from 2. sounds much worse than from 1. (a lot of ambient information is lost, bass is muddier etc.). I have no DSP or conversion activated.
Also DSD in general as far as playable from 1. sounds a bit better than from 2.is my perception.
I have no clue why this is the case, but my only solution is to play PCM (and maybe DSD under 256) with Bitstreaming checked (for sound quality reasons) and DSD256 with Bitstreaming unchecked.
If you have an idea what's going on, please advise...
By the way:
Situation 2. means, JRiver reacts fast on clicks from JRemote
Situation 1. means, JRiver reacts mostly very slow and partly not at all to clicks on tracks from JRemote. Just as with a bad network connection.
Any idea why?
-
1. When checking Bitstreaming under DLNA options and chosing "original" as format, the DAC shows it get's DOP as DSD64 or DSD128. When playing DSD256 files it shows it get's PCM384 and plays white noise with faint music signal.
2. When unchecking Bitstreaming under DLNA options and chosing "original" as format, the DAC shows it get's DSD as DSD64, 128 or 256 an plays the latter properly as DSD.
This makes sense, except for option 1 at DSD256. That should be PCM 705 KHz although it clearly is getting downsampled somewhere. It may be a setting for 705K in DSP Study, but it may just be something about the fact that the lens does not support 705 KHz. But, it does not seem to matter since the Airlens does not support 705 KHz.
Option 2 seems to be sending the expected native DSD.
I do not understand why you hear the difference in option 2.
PCM from 2. sounds much worse than from 1.
Option 2 does not send PCM, it sends native DSD, so I am not sure about this statement.
Not sure where to go for DSD256.
-
Option 2 does not send PCM, it sends native DSD, so I am not sure about this statement.
I thik I wasn’t clear enough here:
This has nothing to do with DSD files. What I meant is, that then PCM files sound clearly worse than PCM files in option 1.
Does the Bitstreaming setting for DSD change anything in pure PCM playback to your knowledge?
-
Now that I know, for sound quality reasons I want to play everything except DSD256 with Bitstreamimg checked under DLNA options, does anyone have a hint for a kind of quick toggle macro for switching on and off, or a kind of rule based configuration for DSD?
And another topic:
Can someone tell where I can choose to vary the volume of the DAC with JRiver‘s volume or not? I had it but lost it with whatever setting I don’t remember…
Thanks!
-
Investigate Zones and Zoneswitch on our wiki.
-
I understand this is for question one…thanks much, will do!
-
...
Does the Bitstreaming setting for DSD change anything in pure PCM playback to your knowledge?
No.
With PCM, whether or not bitstreaming is selected, you are sending the original file verbatim.
-
That’s really strange, it definitely sounds noticeably different on a resolving setup in terms of air and 3D, bass as well as midrange ease.
-
One more insight from my tests:
DSD256, played with Bitsreaming unchecked in DLNA settings, sounds worse than the same track as DSD128, played with Bitstreaming checked.
This could be some difference in the JRiver code or some difference of the DAC playing DOP vs. DSD direct. But as PCM also sounds even more worse when played with Bitstreaming unchecked, I guess it’s rather a JRiver difference (even if there’s no obvious hint on this and PCM is processed the same with/without Bitstreaming checked).
-
My understanding of how DLNA works, when the mode is set to original, is that the file is passed to the renderer/DAC for it to process.
MC is not processing the audio in anyway; it is just behaving as a file server.
When bitstream DSD is ticked that tells MC to take the dsf file and repack the DSD as a sudo PCM file (DoPE) (this is not converting to PCM) which is then passed to the DAC to unpack it back into DSD.
So, any comments about sound differences are puzzling especially regarding PCM, I am not saying you are mistaken, it is just not obvious to me what is happening to produce these differences.
-
It is indeed puzzling. Especially as the DOP containered DSD sounds better than the direct DSD. Even more puzzling with PCM and how the Bistreaming setting should have an effect there....but it does and it's obvious (but certainly not audible with low/midfi or even a lot of high end equipment..the difference is mainly in the ambience/decay/reverb area. No idea if any code thing is affected in the background...only the programmer can tell.
-
My understanding of how DLNA works, when the mode is set to original, is that the file is passed to the renderer/DAC for it to process.
MC is not processing the audio in anyway; it is just behaving as a file server.
More or less correct. Not exactly a file server, but similar.
When bitstream DSD is ticked that tells MC to take the dsf file and repack the DSD as a sudo PCM file (DoPE) (this is not converting to PCM) which is then passed to the DAC to unpack it back into DSD.
Bitstreaming should have no effect when using DLNA. The wiki discusses bitstreaming.
-
It is indeed puzzling. Especially as the DOP containered DSD sounds better than the direct DSD. Even more puzzling with PCM and how the Bistreaming setting should have an effect there....but it does and it's obvious (but certainly not audible with low/midfi or even a lot of high end equipment..the difference is mainly in the ambience/decay/reverb area. No idea if any code thing is affected in the background...only the programmer can tell.
I think your device doesn't work with 256 over DLNA. You should talk with the manufacturer.
-
Bitstreaming should have no effect when using DLNA. The wiki discusses bitstreaming.
But it definitely has, when playing DSF files, the DAC shows DOP when it’s activated and DSD when not.
-
I think your device doesn't work with 256 over DLNA. You should talk with the manufacturer.
It does with Bitstreaming unchecked. With Bitstreaming checked it doesn’t, because streamer and DAC just support PCM384.
-
It does with Bitstreaming unchecked. With Bitstreaming checked it doesn’t, because streamer and DAC just support PCM384.
Bitstreaming here meaning ONLY the setting in the DLNA server settings (that says DoPE). The one in the Audio zone settings has no effect here.
Most networked DACs only supported DoPE for DSD. That's why the option is there. It doesn't change the DSD in any way, just wraps it into a PCM container and the DAC then strips the wrapping when playing back to get the native DSD.
These days there are more devices that support native DSD. If yours does, you should choose original format and not check the bitstreaming option.
Now the issue is that DoPE requires more bandwidth than native DSD because of the wrapping for the same material.
Usually a DAC that can play native DSD256 can only play DoPE to DSD128.
-
Bob - It seems like this device and some DACs do support native DSD through DLNA and that can cause confusion as to how to set that up in the DLNA server. It would be nice to have an additional option for native DSD in the DLNA options.
Bistream DSD via DLNA (requires DoPE DAC)
Bistream DSD via DLNA (requires native mode DAC)
Or maybe, just add Uncheck for Native DSD to the current option - something like
Bistream DSD via DLNA (check for DoPE and uncheck for Native DSD)
This does not come up often, but it does happen and can cause confusion.
Thanks.
-
Bob - It seems like this device and some DACs do support native DSD through DLNA and that can cause confusion as to how to set that up in the DLNA server. It would be nice to have an additional option for native DSD in the DLNA options.
Bistream DSD via DLNA (requires DoPE DAC)
Bistream DSD via DLNA (requires native mode DAC)
Or maybe, just add Uncheck for Native DSD to the current option - something like
Bistream DSD via DLNA (check for DoPE and uncheck for Native DSD)
This does not come up often, but it does happen and can cause confusion.
Thanks.
Good suggestion. I'll add (check for DoPE and uncheck for Native DSD)
-
Good suggestion. I'll add (check for DoPE and uncheck for Native DSD)
Thanks. I guess that does raise the issue if unchecking actually guarantees bitstreaming, or does it allow DSP study to make changes. If so, maybe a new bitstreaming for native DSD option may be necessary.
-
Bitstreaming here meaning ONLY the setting in the DLNA server settings (that says DoPE). The one in the Audio zone settings has no effect here.
Most networked DACs only supported DoPE for DSD. That's why the option is there. It doesn't change the DSD in any way, just wraps it into a PCM container and the DAC then strips the wrapping when playing back to get the native DSD.
These days there are more devices that support native DSD. If yours does, you should choose original format and not check the bitstreaming option.
Now the issue is that DoPE requires more bandwidth than native DSD because of the wrapping for the same material.
Usually a DAC that can play native DSD256 can only play DoPE to DSD128.
Yes I agree and understand, the Bitstream/DoPE checkbox in DLNA settings just stands for DoPE.
Anyway my problem is, that for whatever reason, if it’s unchecked, everything sounds worse (although it shouldn’t). Even DSD256 direct then sounds worse than DSD128 DopE.
-
Thanks. I guess that does raise the issue if unchecking actually guarantees bitstreaming, or does it allow DSP study to make changes. If so, maybe a new bitstreaming for native DSD option may be necessary.
Unfortunately I don’t fully understand…would this mean you could provide a new mode that does Bitstreaming for native DSD and this could mean it sounds as good as the Bitstreaming for DoPE we now have up to DSD128 in my case?
I didn’t understand if Bitstreaming and DoPE (or direct) can be combined flexibly and what that means..and if we currently just have DoPE with Bitstreaming and direct without Bitstreaming and if the new option would mean Bitstreaming direct as a new mode.
So far I thought direct never means Bitstreaming, just DoPE does.
-
Unfortunately I don’t fully understand…would this mean you could provide a new mode that does Bitstreaming for native DSD and this could mean it sounds as good as the Bitstreaming for DoPE we now have up to DSD128 in my case?
I didn’t understand if Bitstreaming and DoPE (or direct) can be combined flexibly and what that means..and if we currently just have DoPE with Bitstreaming and direct without Bitstreaming and if the new option would mean Bitstreaming direct as a new mode.
So far I thought direct never means Bitstreaming, just DoPE does.
It would be just an information addition.
I see absolutely no way to explain what you are hearing if you have your DLNA server setting to "original format"
It's just sending a file to your renderer.
Maybe your renderer doesn't like the mimetype or something but if it IS playing the original file why should it sound any different???
-
Yes, it makes no sense, but I hear it clearly. Maybe my HW likes DOPE better than direct for whatever reason.
-
This setup is extremely complicated. Note that the DLNA renderer here is not a DAC. It is *connected* to a DAC. This means that many things could be happening after the DLNA device receives the data and then sends it to the DAC.
Brian.
-
I’m following this conversation with interest. There is a somewhat parallel thread on the PS Audio site. I assume some of the same posters, different user names, are involved.
I don’t view a separate streamer feeding a dedicated DAC that complicated or unusual. There are dozens of dedicated streamers available. I use a sonore signature rendu device as a DLNA renderer (also for Roon) feeding a PS Audio mkii DAC. I haven’t tried high rate DSF files but assume it would work direct or DoPE.
Certainly agree that lots could be happening. Decently likely that it’s the airlens. Just a guess based upon my two prior conversdigital based renderers.
One thing I agree on, the term bitstream to mean DoPE is confusing.
Just my $0.02
-
Yes I also posted my findings there.
The Mk II is also limited to DOP128, so it should be the same result with it. DSD256 also has to be played direct.
Just try to play a very airy and spacious sounding PCM file (I use AIF) with and without DoPE checked if you hear a difference. The DSD difference is a bit smaller.
-
FYI…the PSA site says the mkii supports DoP256 for i2s and usb inputs. Limited to 128 for dual aes and 64 for single aes and spdif.
-
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.
-
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.
-
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).
-
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?
-
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.
-
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.
-
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"?
-
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.
-
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?
-
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...
-
Thanks but I use the Mk I, which just supports DSD256 direct, not DoP..
-
As far as I know you can't zone switch on remote zones.
-
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)
-
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.
-
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?
-
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
-
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.
-
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.
-
...
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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."
-
Nobody wants to argue, but I don't buy the "noisy PC process" theory.
-
ok. I just meant I can't discuss it due to lacking deeper knowledge...no reason to argue indeed ;-)
-
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
-
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 ;-)
-
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.
-
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! :) :)