Print

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

[SamuelMaki]

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

[JimH]

http://wiki.jriver.com/index.php/Audio_Output_Modes

[Hendrik]

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.

[NickF]

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.

[Hendrik]

Just setup MC to output the best format your hardware supports, it'll then do the right thing automatically.

[NickF]

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.

[Hendrik]

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.

[NickF]

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.

[JimH]

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.

[NickF]

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.

[JimH]

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.

[NickF]

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.