INTERACT FORUM
More => Old Versions => Media Center 17 => Topic started by: SamuelMaki on January 09, 2012, 03:19:05 am
-
I wonder why LAV-Audio sends always 32-bit stream to JRiver? When going custom mode, I disabled 32-bit float and integer, then JRiver shows correct bits (16 DD and 24 DTS)... Is there some reason why Red October gives 32-bit (float, I assume) playback instead of the "real" 16/24-bits? I use 24-bit output via WASAPI and 32-bit output via ASIO4ALL (hdmi)(have not decided which one sounds better) ... Both shows correct bits in Yamaha rx-v3900, but is there some loss of sound when JRiver does 32->24-bit conversion? Audio path warns about it...
Is it better to use ASIO4ALL or WASAPI or WASAPI Event style? I have thought that ASIO is the best, but I do not have soundcard that supports it, so is ASIO4ALL the same thing? (At least I can hear correct sounds, but Yamaha shows 7.1 when playing 5.1)
And last but not least, is it better to use LAV+madVR or madVR internal filters? I am using gamma correction and sometimes DXVA-deinterlacing... Does LAV send all the information needed for gamma conversion correctly, or does it work better with internal filters? Madshi doesn´t do much for the internal filters, and LAV is getting better and better, so I thought that it might get better (or atleast bugfree) playback? Or is this just cosmetical issue and doesn´t have any real world effect?
That is all this time, thanks for helping :)
-
http://wiki.jriver.com/index.php/Audio_Output_Modes
-
Most lossy formats like AC3/DD or DTS don't have a "real" bitdepth, the decoding results in 32-bit floating point data, and that is exactly what LAV outputs to MC - untouched from the decoder. Most audio output devices don't support floating point however, so it needs to be converted somewhere. If you disable these modes in LAV, it will do the conversion, otherwise MC will do it - no matter what you do, it has to be converted somewhere. You should try to keep the audio in the highest bitdepth possible for as long as you can, so do the conversion as late as possible (so not in LAV Audio).
As a general rule:
- "Lossy" formats don't have a "bitdepth", they should always result in 32-bit floating point, if possible. This includes format like: AC3/DD, AAC, DTS, MP3, Vorbis, and many more.
- "Lossless" formats have a real bitdepth. They should be decoded to that exact bitdepth, and nothing different. This is usually 16-bit or 24-bit integer. This includes: TrueHD, DTS-HD MA, FLAC, ALAC, .... and more
Not all decoders function to these exact specifications, but in LAV Audio i try to stick as close as possible to it as i can.
-
You should try to keep the audio in the highest bitdepth possible for as long as you can, so do the conversion as late as possible (so not in LAV Audio).
Not knowing what the graph is for Red October HQ, where is the latest that the conversion can/should be done? Is it in MC itself, and in that case, in DSP?
I am using an RME sound card and am not sure what I should convert to. 32 bit floating point definitely doesn't work but 24 and 32 bit do.
Nick.
-
Just setup MC to output the best format your hardware supports, it'll then do the right thing automatically.
-
Changing the setting in MC doesn't help. I was getting a WASAPI Initialise error from ReClock. If I use FFDShow for audio, I can uncheck 32 bit Floating Point and it is OK but there is no such setting in LAV. I have now changed ReClock to 32 bit and it works.
Nick.
-
You're not supposed to use ReClock with MC, if you use ReClock you disable all of its smartness, and it cannot affect the audio path, and its all up to your configuration.
-
The problem is that MC's VideoClock simply doesn't work for some people and you can't get smooth video without ReClock. If I remove ReClock and enable VideoClock, my video is wrecked and I get significant problems with audio sync. With ReClock, everything is perfect. What am I supposed to do?
Nick.
-
Try the JRiver benchmark under Help and post the results. It takes a fairly powerful machine to do Red October HQ
You could try Red October Std.
-
Here are the Benchmark test results:
Running 'Math' benchmark...
Single-threaded integer math... 3.930 seconds
Single-threaded floating point math... 2.219 seconds
Multi-threaded integer math... 2.135 seconds
Multi-threaded mixed math... 1.464 seconds
Score: 1949
Running 'Image' benchmark...
Image creation / destruction... 1.200 seconds
Flood filling... 0.957 seconds
Direct copying... 1.559 seconds
Small renders... 2.397 seconds
Bilinear rendering... 2.086 seconds
Bicubic rendering... 1.930 seconds
Score: 2172
Running 'Database' benchmark...
Create database... 0.537 seconds
Populate database... 2.616 seconds
Save database... 0.447 seconds
Reload database... 0.081 seconds
Search database... 1.470 seconds
Sort database... 1.252 seconds
Group database... 0.744 seconds
Score: 3008
JRMark (version 17.0.64): 2376
Nick.
-
I'm guessing that the machine is borderline. Try simplifying it.
If your files on are on a network drive, try a file from a local drive.
Turn off any virus checker and other background processes. iTunes runs a couple.
Check the power settings.
Turn off Aero.
Use RO Std to see if it works. Don't do any tweaks to any filters.
-
Thanks Jim, I'll give it another try tonight.
You may have seen a thread I started here:
http://yabb.jriver.com/interact/index.php?topic=68823.0
to try to determine whether we could find specific thresholds of performance required for the different RO options. Do you have a CPU and Graphics threshold which you use?
Nick.