Print

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

[RichB]

The BDP-105 USB DAC sound quality can be affected by the driver settings.

I prefer J River 19 (Windows) WASAPI event driven and recently I tried setting the bit-depth to 16 bits for 44.1/16 and it sounds a bit better to me than default or 24-bit.
The Automatic bit depth sets is 24-bit padded. Is there a way to send the Source bit-depth so that when I play 24-bit content that is used?

Thanks,

Rich

[6233638]

24-bit padded means that 24-bit audio is being sent inside a 32-bit container. This is very common over HDMI connections, as they typically do not accept a "plain" 24-bit signal.
Outputting a 24-bit signal with a 16-bit input does nothing but add zeros for the last 8-bits. My DAC monitors incoming signals and actually reports this as being identical to a 16-bit signal.
 
If you are modifying the input in any way at all - even something like adjusting the volume, then you actually require more than the input bit-depth to avoid losing data.

[mojave]

You can read more on bitdepth in the wiki.

[RichB]

I understand bit depth and that added zeros should not affect the signal.
If there is a sound quality difference, then is this a USB driver issue?

I first noticed the difference when using J River from my IPad with the IPad connected directly to a DAC USB port.

I am just wondering, if the sample rate is unchanged, why not have an option to leave the bit-depth unchanged?
Something like: Source or  Bit-Direct


- Rich

[Vincent Kars]

You can do it manual: audio device > playback options
The old option in DSP studio (source bit depth) is gone

[RichB]

Thanks Vincent,

I have been doing this manually.

The Oppo supplied TUSBAudio Spy Tool Sound Devices (Out) show has an entry INF: Sample Format with the following values:

2 = J River Automatic and 24 Bit in a 32 bit package and Foobar 24 Bit
3 = J River 24 Bit
4 = J River 16 Bit and Foobar 16 bit


there is a definite difference and for 16 bit, I prefer this setting.

Unfortunately, if I forget it, it down-samples 24 bit content and DoP produces no output.
So, an option for bit-depth source would be great.

- Rich

[RichB]

After more listening sessions different Oppo DACs the 16-bit setting is superior in my system to all other choices with 44.1/16 rips.

It would be fantastic if there were options to select the native bit-rate with WASAPI.
A checkbox option would do the trick. For the record, I have the same results with Foobar2000 so it seems to be a characteristic of this DAC/Driver.

Thanks,

- Rich

[6233638]

Honestly, something else is seriously wrong if outputting 16-bit data sounds better than 24-bit.
You're probably better to find out what that is than hope the developers add a "bad" feature. (if a feature is there, people will use it mistakenly, and something like that is just going to cause problems)

[RichB]

Honestly, something else is seriously wrong if outputting 16-bit data sounds better than 24-bit.
You're probably better to find out what that is than hope the developers add a "bad" feature. (if a feature is there, people will use it mistakenly, and something like that is just going to cause problems)

Ok, I will investigate and get back to you.

- Rich

[RichB]

Honestly, something else is seriously wrong if outputting 16-bit data sounds better than 24-bit.
You're probably better to find out what that is than hope the developers add a "bad" feature. (if a feature is there, people will use it mistakenly, and something like that is just going to cause problems)

I am not sure I follow this logic though.
It can be reasonably argued that expanding 16-bit data to 24-bit should do no harm but it could also be argued that doubling the sampling rate should not harm the sound quality.
However, JR can be defaults to maintain the incoming sampling rate.

If a user sets the bit-depth to 16 bit, they are definitely getting a going to get a reduction is sound quality when playing 24-bit data.
This is the current situation.
For whatever reason, the Automatically for best sound quality, is not delivering the best sound quality.

Since there is an Automatic setting, JR clearly can select an appropriate upper limit to the bit-depth, so I cannot see what possible user error can occur if the sampling rate is 16 bit and JR simple does not expand or pad it in any way.
Are there drivers that cannot handle the 16 bit native data?

- Rich

- Rich

[Hendrik]

Its not as simple as that.
As soon as you do *anything* to the audio, the source bit-depth becomes irrelevant.

You only need to lower the volume of the audio in Media Center, and more then 16-bits may already be in use.
Not to mention what happens with any more complex processing options.

[mojave]

I am not sure I follow this logic though.
It can be reasonably argued that expanding 16-bit data to 24-bit should do no harm but it could also be argued that doubling the sampling rate should not harm the sound quality.

Yes, but the arguments are from different positions. The bitdepth argument is from a mathmatical perspective. In other words, the numbers are identical when going from 16 to 24-bit. No change has happened.

The doubling the sample rate argument (that it doesn't harm sound quality) is more from observing mathematical changes, but not being able to hear a difference in the final output.

How are you controlling the volume? Are you doing any DSP in JRiver?

The Oppo converts everything internally to 32-bit floating point so any previous bit depth increase won't affect the final output. In other words, if the original is 10 and JRiver converts to 10.000x and the Oppo converts to 10.000xx, going from 10 (source) to 10 (JRiver) to 10.000xx (Oppo) won't change anything.

[RichB]

Its not as simple as that.
As soon as you do *anything* to the audio, the source bit-depth becomes irrelevant.

You only need to lower the volume of the audio in Media Center, and more then 16-bits may already be in use.
Not to mention what happens with any more complex processing options.

Good point.
I am looking for a set it and forget it way to do absolutely nothing to the source bit-depth. Volume control is disabled.

- Rich

[RichB]

Yes, but the arguments are from different positions. The bitdepth argument is from a mathmatical perspective. In other words, the numbers are identical when going from 16 to 24-bit. No change has happened.

The doubling the sample rate argument (that it doesn't harm sound quality) is more from observing mathematical changes, but not being able to hear a difference in the final output.

How are you controlling the volume? Are you doing any DSP in JRiver?

The Oppo converts everything internally to 32-bit floating point so any previous bit depth increase won't affect the final output. In other words, if the original is 10 and JRiver converts to 10.000x and the Oppo converts to 10.000xx, going from 10 (source) to 10 (JRiver) to 10.000xx (Oppo) won't change anything.

I several audio paths that I have been testing via J River:

BDP-105D -> XLR -> Parasound A51 -> Revel Salons (BDP 105D Volume control)
BDP-105D -> RCA Marantz AV8801 (pure Direct) -> A51 -> Revel Salons (AV8801 Volume Control)

I am also testing another Oppo device with an all analog volume control with similar results.
This situation is similar to the sample rate conversion where mathematically leaving the J River software there should be no change.
However, listening to the output at the other end, there is a definite difference.
The 24-bit (padded or unpadded) output sounds less resolved with what I can best described as a slight "hash" making it a bit more difficult to identify instruments and adding to existing sibilance.

There must be something going on in the driver because similar results are obtained with foobar2000.
With Foobar2000, the difference is easier to identify since you can change the bit-depth on the fly with stopping and restarting playback.

I can see the issue with configuration since additional processing within J River benefits from the extra bits.
Could Automatic mode work in conjunction with some other option to bypass padding only when the volume control is disabled?
Perhaps, a Bit-stream PCM option which is really what I am discussing.

- Rich

[Vincent Kars]

If I understand correctly how USB audio works (the emphasizes is on IF of course) the following might be the case.

USB audio is not very strict, you can send anything.
If you send 2ch 16 bit 44.1 Khz, it will send 16 bits of data for each channel (no padding, packaging in 32 bit container etc)
2x16x44100=1411200  bit/s
If you send the same but this time in 24 bit
2x24x44100=2116800 bit/s

Obvious the payload over the bus increases substantially.
Then we need a couple more  “if”s
More data is more electrical activity
More electrical activity is more “noise”
This noise is not sufficiently suppressed, hence it affects the DA conversion inside the Oppo.

However, if this is true one would expect up-sampling by an even number e.g. to 88.2 to do the same.
The ultimate consequence: a 2 channel 24 bit 192 kHz should sound the worst of them all!

Bit to many “if”s imho but what theoretically won’t make a difference (padding 8 bit) does make a difference in payload.

[6233638]

USB audio is not very strict, you can send anything.
If you send 2ch 16 bit 44.1 Khz, it will send 16 bits of data for each channel (no padding, packaging in 32 bit container etc) 2x16x44100=1411200  bit/s
If you send the same but this time in 24 bit 2x24x44100=2116800 bit/s

Obvious the payload over the bus increases substantially.

USB 1.0 supports 12Mb/s.
USB 2.0, which most devices are using now, supports 480Mb/s.
 
The difference between 1.4Mb/s and 2.0Mb/s is negligible on a 480MB/s connection.
 
Everything I have seen suggests that the Oppo players are quite capable devices, so I doubt there's anything wrong there.
 
Are you using a DIY or "Audiophile" USB cable? Most of these will not pass spec.
But even so, it would need to have failed spectacularly if it cannot even handle 2Mb/s.
 
 
I suspect that it's your testing which is flawed more than anything else. (sighted testing, expectation bias etc.)

For whatever reason, the Automatically for best sound quality, is not delivering the best sound quality.

Since there is an Automatic setting, JR clearly can select an appropriate upper limit to the bit-depth, so I cannot see what possible user error can occur if the sampling rate is 16 bit and JR simple does not expand or pad it in any way.

"Automatic (recommended for best sound quality)" means that it will automatically use the highest bit-depth that you hardware supports - because that is the way that you get the best sound quality.
 

This situation is similar to the sample rate conversion where mathematically leaving the J River software there should be no change.

Sample rate conversion absolutely does make a change to the files, as you are using interpolation on the data. Bit-depth is nothing more than adding zeros to the end.
 
 
If you really insist on using a 16-bit output when playing 16-bit files, you can set up multiple zones and use Zone Switch to change between them depending on the source bit-depth.
 
But I think it's crazy to do so.

[RichB]

USB 1.0 supports 12Mb/s.
USB 2.0, which most devices are using now, supports 480Mb/s.
 
The difference between 1.4Mb/s and 2.0Mb/s is negligible on a 480MB/s connection.
 
Everything I have seen suggests that the Oppo players are quite capable devices, so I doubt there's anything wrong there.
 
Are you using a DIY or "Audiophile" USB cable? Most of these will not pass spec.
But even so, it would need to have failed spectacularly if it cannot even handle 2Mb/s.
 
 
I suspect that it's your testing which is flawed more than anything else. (sighted testing, expectation bias etc.)
"Automatic (recommended for best sound quality)" means that it will automatically use the highest bit-depth that you hardware supports - because that is the way that you get the best sound quality.
 Sample rate conversion absolutely does make a change to the files, as you are using interpolation on the data. Bit-depth is nothing more than adding zeros to the end.
 
 
If you really insist on using a 16-bit output when playing 16-bit files, you can set up multiple zones and use Zone Switch to change between them depending on the source bit-depth.
 
But I think it's crazy to do so.

I did not take long for the DBT to creep into the discussion.
I have done SBT tests with others where they cannot see me or what I am doing.

If choosing between Automatic (32-bit padded), 24-bit, and 16-bit for 16-bit sources, Automatic is not better than 24-bit, 24-bit is not better than 16-bit for 16-bit sources.

I have verified that the driver receives different data. I have no idea what the driver does but clearly it is not handled the same way.
There have been many discussions about sound quality when the data stream is the same.

Iin this case, the data stream is different and I do not think it beyond the realm of possibility that a different data stream produces an audible difference.

Just my 2 cents.

- Rich

[6233638]

If choosing between Automatic (32-bit padded), 24-bit, and 16-bit for 16-bit sources, Automatic is not better than 24-bit, 24-bit is not better than 16-bit for 16-bit sources.

If you are not doing any processing to the files (all options in DSP studio are disabled, volume control is disabled etc.) then the bit-depth will make no difference with a 16-bit source file.

But as soon as you start adjusting the volume or using DSP, you need more than 16-bits to avoid degrading the sound quality.
This is why you should always be using the maximum bit-depth that your hardware supports at all times.

In this case, the data stream is different and I do not think it beyond the realm of possibility that a different data stream produces an audible difference.

The data is the same.

This explanation is not technically correct, but should hopefully convey the difference.
Transmitting 00001 and 00000001 both result in "1" being played by the DAC.
That's all the switch from 16-bit to 24-bit is effectively doing.
 
My DAC actually measures the incoming signal, and when Media Center is playing back a 16-bit file in a 24-bit container, it is listed as being a 16-bit signal not a 24-bit one. As soon as I make any changes to the audio (e.g. reduce volume from 100% to 99%) the DAC then reports that the signal has changed to being 24-bit.


As I said though, if you insist on it, you should be able to use Zone Switch to do what you want.

[RichB]

If you are not doing any processing to the files (all options in DSP studio are disabled, volume control is disabled etc.) then the bit-depth will make no difference with a 16-bit source file.

But as soon as you start adjusting the volume or using DSP, you need more than 16-bits to avoid degrading the sound quality.
This is why you should always be using the maximum bit-depth that your hardware supports at all times.
The data is the same.

This explanation is not technically correct, but should hopefully convey the difference.
Transmitting 00001 and 00000001 both result in "1" being played by the DAC.
That's all the switch from 16-bit to 24-bit is effectively doing.

Essentially, but not the same:
As you can see in this post:

http://yabb.jriver.com/interact/index.php?topic=87326.msg598110#msg598110
 
The Driver is reporting a different format. The numerical values may be the same but the format and data stream are different.
That should make no difference, but it is not the same data stream.

My DAC actually measures the incoming signal, and when Media Center is playing back a 16-bit file in a 24-bit container, it is listed as being a 16-bit signal not a 24-bit one. As soon as I make any changes to the audio (e.g. reduce volume from 100% to 99%) the DAC then reports that the signal has changed to being 24-bit.

As I said though, if you insist on it, you should be able to use Zone Switch to do what you want.

I can already do this by changing the bit-depth.
However, it is not easy to remember the bit-depth of every recording.
Unless I am missing something, there is no automatic way to switch.

I appreciate all the responses, but I have done extensive listening tests and I assure you there is a sonic advantage to bit-streaming the source bit-depth.
It is surprising that that optionally automating the transmission of the original bit-stream is controversial.
J River is very powerful and  this is not rocket science.

- Rich

[mwillems]

I can already do this by changing the bit-depth.
However, it is not easy to remember the bit-depth of every recording.
Unless I am missing something, there is no automatic way to switch.

As 6233638 noted above, the zoneswitch feature can do what you want: it allows for automated switching between zones based on a variety of file attributes, including bitdepth.  It doesn't require you to remember the bitdepth, it automatically plays files to the appropriate zones.  There are some quirks to it that may not make it a 100% solution, but it's a method of automatically changing the output bitdepth based on the source bitdepth.  Is there something about zoneswitch that won't work in your application?

[kstuart]

Is there an ASIO driver for the Oppo DAC ?

[kstuart]

As 6233638 noted above, the zoneswitch feature can do what you want: it allows for automated switching between zones based on a variety of file attributes, including bitdepth.  It doesn't require you to remember the bitdepth, it automatically plays files to the appropriate zones.  There are some quirks to it that may not make it a 100% solution, but it's a method of automatically changing the output bitdepth based on the source bitdepth.  Is there something about zoneswitch that won't work in your application?

It won't switch within playlists...

[mwillems]

It won't switch within playlists...

That's why I said it's not a 100% solution, but if OP (like me) is almost exclusively an album listener, it's an almost perfect solution.  OP just seemed to be unaware that any automated switching was possible, and I wanted to make sure I wasn't misunderstanding.

[kstuart]

ASIO would be a lot simpler though, and the OP might find it sounds better... generally ASIO is used when people want the format to be transmitted without changes...

[RichB]

As 6233638 noted above, the zoneswitch feature can do what you want: it allows for automated switching between zones based on a variety of file attributes, including bitdepth.  It doesn't require you to remember the bitdepth, it automatically plays files to the appropriate zones.  There are some quirks to it that may not make it a 100% solution, but it's a method of automatically changing the output bitdepth based on the source bitdepth.  Is there something about zoneswitch that won't work in your application?

OK, Thanks 6233638 and mwillems, I will give that a shot.
I am primarily an album listener.

- Rich

[RichB]

ASIO would be a lot simpler though, and the OP might find it sounds better... generally ASIO is used when people want the format to be transmitted without changes...

I have tried ASIO as well and I like WASAPI better.
Interestingly, it seems to use a different path into the driver and shows up in the spytool in a new section.
Oppo has recommended Kernel Streaming and WASAPI when I have asked in the past.

- Rich

[JimH]

generally ASIO is used when people want the format to be transmitted without changes...

WASAPI, ASIO, and Kernel Streaming all bypass the Windows Mixer.  All are bit perfect.

[RichB]

WASAPI, ASIO, and Kernel Streaming all bypass the Windows Mixer.  All are bit perfect.

Is it possible that once J River sends the data to the Windows driver, the vendor supplied driver can results in different performance?

Is a bit-depth option to pass the source depth un-modified something you may consider?
That would be the most bit perfect of all.

- Rich

[6233638]

ASIO would be a lot simpler though, and the OP might find it sounds better... generally ASIO is used when people want the format to be transmitted without changes...

ASIO operates in 32-bit, as I understand it.

[RichB]

So far, I have not been able to get Zones and Zone Switching to work.
Originally, I had a Zone called Player.
I added a New Zone: 16-Bit copied from Player.

Player is set to bit-depth Automatic. 16-Bit is set to 16 bit.
The two are linked with mutually exclusive selections that turn off the other zone.
They are using the same USB DAC in exclusive mode. The 16 bit-depth files play but higher bit-depth and sacd/dsf files do not play.
The image is attached.

- Rich

[mwillems]

So far, I have not been able to get Zones and Zone Switching to work.
Originally, I had a Zone called Player.
I added a New Zone: 16-Bit copied from Player.

Player is set to bit-depth Automatic. 16-Bit is set to 16 bit.
The two are linked with mutually exclusive selections that turn off the other zone.
They are using the same USB DAC in exclusive mode. The 16 bit-depth files play but higher bit-depth and sacd/dsf files do not play.
The image is attached.

- Rich

When you say that the higher bitdepth files "do not play" what do you mean?  Do you mean that there's an error, or no sound, or nothing happens, or just no zone switch?  

One suggestion: a space between two filters is a logical "and," not a logical "or."  So the "HD Audio" rule won't work correctly unless you put an "or" between the two conditions in the HD Audio rule expression.

[RichB]

When you say that the higher bitdepth files "do not play" what do you mean?  Do you mean that there's an error, or no sound, or nothing happens, or just no zone switch?  

One suggestion: a space between two filters is a logical "and," not a logical "or."  So the "HD Audio" rule won't work correctly unless you put an "or" between the two conditions in the HD Audio rule expression.

Sometimes, playback did not start with no error.
I added a OR between the conditions and switched the Player to ASIO since it is not exclusive and now they both play, ignoring the stop playing rule.

So, it looks like the errors before were because the Player rule is not stopping the 16-bit zone for some reason.
With ASIO, the 16-bit zone plays when it is supposed to be stopped by other zone switch rules.

- Rich

[mwillems]

Sometimes, playback did not start with no error.
I added a OR between the conditions and switched the Player to ASIO since it is not exclusive and now they both play, ignoring the stop playing rule.

So, it looks like the errors before were because the Player rule is not stopping the 16-bit zone for some reason.
With ASIO, the 16-bit zone plays when it is supposed to be stopped by other zone switch rules.

- Rich

That's very odd; did you try the "or" rule before or after you changed output formats?  If not, I'd suggest trying the new rule with both zones set to WASAPI again.  I was thinking that playback wasn't starting because no files met both of the AND conditions, so the rule never engaged.  

Are both zones currently set to ASIO, or one to ASIO and one to WASAPI?  I ask because I've never seen behavior like you're describing with an ASIO driver, and ASIO is ordinarily an exclusive playback mode.  For example, if I try to playback via ASIO to my device when another zone is already playing to that device without a stop playback rule, I get a "cannot start playback" error.  With the stop playback rule, everything works correctly.  

Unless the OPPO doesn't have a native ASIO driver and you're emulating ASIO with ASIO4All or something?  If that's the case, that could potentially explain it?

[6233638]

There's no need for the file type in your rules. Just have "bit depth is 16" and "bit depth is not 16".
 
Though if you are using ASIO, isn't everything being sent as 32-bit anyway?

[RichB]

That's very odd; did you try the "or" rule before or after you changed output formats?  If not, I'd suggest trying the new rule with both zones set to WASAPI again.  I was thinking that playback wasn't starting because no files met both of the AND conditions, so the rule never engaged.  

Are both zones currently set to ASIO, or one to ASIO and one to WASAPI?  I ask because I've never seen behavior like you're describing with an ASIO driver, and ASIO is ordinarily an exclusive playback mode.  For example, if I try to playback via ASIO to my device when another zone is already playing to that device without a stop playback rule, I get a "cannot start playback error."  With the stop playback rule, everything works correctly. 

Unless the OPPO doesn't have a native ASIO driver and you're emulating ASIO with ASIO4All or something?  If that's the case, that could explain it.

The Oppo driver is accessed appears to have a separate path so it can be played simultaneously with WASAPI.
The switch to ASIO allowed me to isolate the problem.

I unlinked and linked the two zones and it appears that the first item in the linked group always plays and seems to ignore the Zone Switch Stop setting.
If the 16-bit is the first then it always plays. If the Player is first it always plays.
The second item plays alone when that content is selected.

It appears to be a Zone Switch bug in 17.0.117.

- Rich

[mwillems]

The Oppo driver is accessed appears to have a separate path so it can be played simultaneously with WASAPI.
The switch to ASIO allowed me to isolate the problem.

I unlinked and linked the two zones and it appears that the first item in the linked group always plays and seems to ignore the Zone Switch Stop setting.
If the 16-bit is the first then it always plays. If the Player is first it always plays.
The second item plays alone when that content is selected.

It appears to be a Zone Switch bug in 17.0.117.

- Rich

Wait, the zones shouldn't be linked (unless you mean "linked" in the sense of having reciprocal stop playback rules).  To be clear, if you mean you selected the "link zone" menu option for the zones, that is the source of your problem.  Link zone plays back output to all linked zones simultaneously, which would always defeat zoneswitch.  If you have them linked in that sense, unlink them and the zoneswitch rules should work as expected.

For what it's worth, I can confirm that zoneswitch is working as expected for me in 117, including stop playback rules.

[RichB]

Wait, the zones shouldn't be linked (unless you mean "linked" in the sense of having reciprocal stop playback rules).  To be clear, if you mean you selected the "link zone" menu option for the zones, that is the source of your problem.  Link zone plays back output to all linked zones simultaneously, which would always defeat zoneswitch.  If you have them linked in that sense, unlink them and the zoneswitch rules should work as expected.

For what it's worth, I can confirm that zoneswitch is working as expected for me in 117, including stop playback rules.

Unlinked, the two zones properly stop the other zone.

I began this journey trying to automatically play 16-bit content without processing at the same depth and rate and also play 24-bit content atomically.
With that mind, I created the Zones and linked them to create this automation.
The Zone system is very powerful, and when linked they almost work; Only the last zone in the linked set list is following the rules.

- Rich

[6233638]

"Linked" zones mean that any changes you make to one zone, are applied to the other.
You would use linked zones if you wanted to have music playing in multiple rooms at the same time, to two separate devices, for example.
 
If you want to use Zone Switch, they need to be unlinked.

[RichB]

"Linked" zones mean that any changes you make to one zone, are applied to the other.
You would use linked zones if you wanted to have music playing in multiple rooms at the same time, to two separate devices, for example.
 
If you want to use Zone Switch, they need to be unlinked.

Thanks, the zone selection is working when unlinked.

- Rich

[RichB]

I have spent some time with Zones.
That is one cool feature. Linking zones is great for comparing DACs.

When unlinked and used to select among playback options, it would be if JRemote followed the active zone.

After spending more time comparing there is an difference in the sound quality playing 16-bit files in their native 16 bit format and bit-expanded to 24 bits. This is likely driver related and not something that J River is causing.

Preferences may vary, but I definitely prefer 16 bit, so I still feel there is a benefit to offering a native bit-depth option when volume control is disabled and no additional processing is engaged. I doubt many ever try 16-bit mode because it will cause problems when processing or playing high bit-depth content.

Thanks for J River and for listening...

- Rich