Print

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

[Matt]

Media Center 18.0.181 adds several improvements to audio bitdepth handling.

Improvements
1) When using WASAPI, our recommended mode for USB DACs that don't have ASIO drivers, there is no longer a need to configure the bitdepth.  It will auto-configure, just like ASIO and Core Audio.  It is also possible to manually select a bitdepth in Options > Audio > WASAPI - Event Style > Output mode settings..., although this should rarely be needed.

2) Dither is applied to all integer bitdepth down conversions.  

Dither provides a slightly higher quality last bit of data when there are values that fall in-between two discrete integer values.  Since dither is bit-perfect unless there are in-between values (meaning you're using DSP, internal volume, etc.), it's perfectly transparent for bit-perfect playback, while providing slightly better quality in cases when DSP is engaged.  Some more on this here.  The separate dither option for ASIO was removed, since dither is part of the framework now.

3) Bitdepth selection is controlled by the output plugin.  It is no longer selected in DSP Studio > Output Format.

ASIO has always ignored the bitdepth selection in DSP Studio since the hardware determines the bitdepth.  Core Audio works the same way and always takes 32-bit floating point.  So the setting was already ignored in many cases.  Also, bitdepth is the very last thing in the audio chain, so it's misleading to make it something set in DSP Studio > Output Format (which is otherwise the very first thing in the DSP chain).

4) All bitdepth handling code has merged into a single, well-optimized system.  Previously ASIO had custom bitdepth code to support less common formats like 'big endian 32-bit that only uses 18-bits'.  WASAPI - Event Style had custom code for '24-bit in a 32-bit container'.  Core Audio had custom code for the 32-bit float handling.  Now the core audio engine can provide the output plugins any of these formats.

5) Revision of DoP (DSD bitstreaming) marker strategy to make it (virtually) impossible for the hardware to lose DSD-lock, even during a data shortfall.

6) Optmizations to the bitdepth conversion system, resulting in a faster audio engine and less memory movement in certain cases.


Testing
Since these changes are far reaching, and at the core of the audio engine, extra testing of the first few builds that use it would be appreciated.  Make sure all your devices and output modes work as expected.  Start with your volume knob low the first time you use this build.  We don't have any ASIO devices that make requests in less common formats like big-endian, etc. so this hasn't been tested.  

More information
There's more information on audio bitdepth available in the Wiki:
http://wiki.jriver.com/index.php/Audio_Bitdepth

[6233638]

Sounds great, and seems to be working well - I do have a question though:

When playing back files, my output is reported as being ___kHz 32bit 2ch using WASAPI (direct connection)

Previously, I had to use 24-in-32 for this to work. (it was my understanding that this is a requirement for HDMI)
Is this just 24-in-32 being reported as 32-bit, or have you figured out how to get 32-bit working?

[Matt]

Is this just 24-in-32 being reported as 32-bit, or have you figured out how to get 32-bit working?

Yes.

Technically we consider it a 32-bit audio format but flag that the lowest 8-bits aren't used (which means they'll be zeroed and dither applied to the 24th bit instead of the 32nd bit).

It would probably be good to make the thing that builds a short string to display the format denote this.

Maybe "44.1kHz 32bit 2ch" could be "44.1kHz 24-in-32bit 2ch" or "44.1kHz 24bit (padded to 32bit) 2ch" or even just "44.1kHz 24bit 2ch".

[6233638]

To save confusion, the best thing would probably be to report that it's 24-bit being padded to 32-bit.
Originally I was unsure about what Media Center was doing when "24-bit" was working, despite other applications requiring 24-in-32, and again when it displayed 32-bit. (even though it technically is)

"44.1kHz, 24-bit (padded) ‒ 2ch" might be best?

While I used it as shorthand above, I don't actually like "24-in-32" or "24-in-32-bit"

I understand that you need to keep it short, but you do support multi-line output in that section:


Perhaps change things so that the first line is dedicated to the output format, and use the second line for any status messages?

WASAPI: 48kHz, 24-bit (padded) ‒ 2 channels
(not using enough bits to output the input directly)

[kstuart]

While looking at all things Bitdepth related, it would be helpful if the Bitdepth File Property reported the commonly used meaning of "Bitdepth" for a digital audio file - namely, the lowest digital resolution of the data during its history.   Other meanings, such as the resolution of processes used in its creation. are unhelpful and contrary to the general convention.

For example, MC18 has a 64-bit audio path for processing, but that does not mean processed files have a bitdepth of 64-bits.

If a file itself reports the unhelpful meaning of "Bitdepth", then the best workaround is for MC18 to assume 16 bits.

BTW, MP3 files are correctly reported at 16-bit, so it is not true that lossy files cannot have the correct bitdepth information.

[Blaine78]

To clarify something on the new dithering system. If no DSP, volume etc is used, in 'direct mode', is dithering applied to the conversion of the 64bit float (JRiver's internal) to a 32bit ASIO output?

[Matt]

To clarify something on the new dithering system. If no DSP, volume etc is used, in 'direct mode', is dithering applied to the conversion of the 64bit float (JRiver's internal) to a 32bit ASIO output?

From above:

Since dither is bit-perfect unless there are in-between values (meaning you're using DSP, internal volume, etc.), it's perfectly transparent for bit-perfect playback, while providing slightly better quality in cases when DSP is engaged.

[DoubtingThomas]

I was configured for ASIO... no longer works.

Switched to WASAPI, which didn't work with prior builds.

Working now.

[bobkatz]

2) Dither is applied to all integer bitdepth down conversions.  


this here[/url].  The separate dither option for ASIO was removed, since dither is part of the framework now.

OH! Please excuse my post of 5 minutes ago. I should have looked here in the release notes first!  I'm just a little bit behind in my work  :-)

Thanks for making JRiver even more foolproof.


Bob

[al1947]

What about bitdepth with respect to converting and exporting a file for use elsewhere? The issue for me is exporting 192/24 FLAC to 44.1/16 Apple lossless for use on iDevices... Easy enough to get the sample rate down to 44.1, but the bit depth stays at 24.

[Matt]

What about bitdepth with respect to converting and exporting a file for use elsewhere? The issue for me is exporting 192/24 FLAC to 44.1/16 Apple lossless for use on iDevices... Easy enough to get the sample rate down to 44.1, but the bit depth stays at 24.

Maybe someday.

More here:
http://yabb.jriver.com/interact/index.php?topic=82354.msg562316#msg562316