Print

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

[RD James]

As I understand it, Windows' audio mixer converts everything to 32-bit floating point internally.
The JRiver WDM driver accepts 16-bit and 24-bit inputs - defaulting to 16-bit.
So the mixer converts audio to 32-bit floating point, then to 16/24 bit, JRiver converts that to 64-bit internally, and outputs it at your playback device's bit depth.
 
If the WDM driver supported a 32-bit input, there should be one fewer conversion taking place.
If it's possible for the driver to use 32-bit floating point, I'm not sure there's any reason to continue supporting 16-bit or 24-bit at all.

[tyler69]

While I find this an quite interesting idea I'm trying to understand the process: do the conversions from 32bit->16bit/24bit happen in the windows domain, so one would have to tell windows mixer to output 32bit (I'm not sure if this would be a setting in playback devices in windows?)?

[RoderickGI]

The JRiver WDM driver accepts 16-bit and 24-bit inputs in shared mode, but do we actually know that it only accepts those bit depths when in exclusive mode?

EDIT: I proofread my posts, but sometimes words still end up missing.    Added "do" to make that sentence work. 

[RD James]

I hadn't even considered exclusive mode playback. It is shared mode which converts all playback to 32-bit floating point internally.
If the output device is <32-bit, then the mixer has to downconvert it to 16-bit or 24-bit.
Since JRiver feeds that into their own audio engine, it gets converted to 64-bit and then back down to whatever your output device supports.
 
Currently, it looks like this:

• 16-bit source
• 32-bit FP mixer input
• 16-bit or 24-bit mixer output (JRiver WDM device)
  
• 64-bit JRiver audio engine
• 24-bit output to DAC

If the WDM driver supported 32-bit floating point:

• 16-bit source
• 32-bit FP mixer input
• 32-bit FP mixer output (no conversion)
  
• 64-bit JRiver audio engine
• 24-bit output to DAC

Here, none of the processing stages reduce precision, except for the final output.
 
I don't know if playback devices are capable of supporting 32-bit floating point though.
"32-bit" is supported, but I don't know if that can be 32-bit integer, 32-bit floating point, or both.

[blgentry]

Is there some audible artifact you hear that you are trying to overcome?  Or just suggesting this based upon the perception that the current way is "not optimal" ?

Brian.

[RD James]

Is there some audible artifact you hear that you are trying to overcome?  Or just suggesting this based upon the perception that the current way is "not optimal" ?

Unlikely to be audible, but it's one fewer conversion taking place.
I was doing some testing in response to this topic and having JRiver dump the audio via the Disk Writer output.
Even matching the sample rate, I was unable to get a bitperfect match to the source audio, and this seemed like a low-effort area for potential improvement.

[tyler69]

Is there some audible artifact you hear that you are trying to overcome?  Or just suggesting this based upon the perception that the current way is "not optimal" ?

Brian.

It might also reduce latency I guess.