INTERACT FORUM
More => Old Versions => JRiver Media Center 18 for Windows => Topic started by: digi340 on May 22, 2013, 12:42:29 pm
-
Hy to all.I use a soundmax ad1986a soundcard with driver for win7 and JRiver Wassapi Event style output in Windows 8 Pro.
In version 18.0.182 when I listen a mp3 JRiver use output 24 bit direct hardware connectin, when I listen DTS file JRiver use output 24 bit but not direct hardware connection (not using enough bit to output direct hardware)
In version 18.0.183 when I listen a mp3 JRiver use output 32 bit direct hardware connection, when I listen DTS file JRiver use output 32 bit direct hardware connection .
In version 18.0.189 when I listen a mp3 JRiver use output 24 bit (padded) but not direct hardware connectin (not using enough bit to output direct hardware), when I listen DTS file JRiver use output 24 bit(padded) direct hardware connection.
Why in my case only version 187.0.183 use Direct hardware connection for mp3, DTS, AC3 and others ?
PS I use driver from Microsoft for my soundcard and driver dedicated from soundmax and in all drivers problem persist.
Excuse me for my English.
-
The way WASAPI is handled was changed recently. In short, what you are seeing in v183 was a "bug" - the audio output was no different from v182 or v189.
Previously 24-bits output in a 32-bit container was labelled as "24-bit" output.
With the new WASAPI update, this was listed as being a "32-bit" output; because it's 24-bits of data, inside a 32-bit container.
This was updated to more accurately reflect what was happening, so you now have "24-bit (padded)" to reflect that Media Center is outputting a 24-bit signal inside a 32-bit container. (24-bit padded with zeroes to fill a 32-bit signal - essentially the same as adding more zeros at the end of a decimal (http://wiki.jriver.com/index.php/Audio_Bitdepth#Conversion))
The DTS files decode to being 32-bit native, I believe.
So in v183 when "24-bits inside a 32-bit container" was listed as a "32-bit" output, it appears to be bit-perfect, which is why you see "direct hardware connection".
But in actuality, "24-bits inside a 32-bit container" is not the same thing as a pure 32-bit output, so it is not a "direct hardware connection" as the decoded 32-bit signal has to be converted to 24-bits.
-
The way WASAPI is handled was changed recently. In short, what you are seeing in v183 was a "bug" - the audio output was no different from v182 or v189.
Previously 24-bits output in a 32-bit container was labelled as "24-bit" output.
With the new WASAPI update, this was listed as being a "32-bit" output; because it's 24-bits of data, inside a 32-bit container.
This was updated to more accurately reflect what was happening, so you now have "24-bit (padded)" to reflect that Media Center is outputting a 24-bit signal inside a 32-bit container. (24-bit padded with zeroes to fill a 32-bit signal - essentially the same as adding more zeros at the end of a decimal (http://wiki.jriver.com/index.php/Audio_Bitdepth#Conversion))
The DTS files decode to being 32-bit native, I believe.
So in v183 when "24-bits inside a 32-bit container" was listed as a "32-bit" output, it appears to be bit-perfect, which is why you see "direct hardware connection".
But in actuality, "24-bits inside a 32-bit container" is not the same thing as a pure 32-bit output, so it is not a "direct hardware connection" as the decoded 32-bit signal has to be converted to 24-bits.
In previous version ex 18.0.182 when I listen mp3 JRiver say direct connection, but in versions from 18.0.183 say "not using enough bit to output direct hardware"