Few questions about Reclock speedup and VSync correction

[MarioMan]

Hi,

My configuration is the following:

Video card: Radeon HD 4850

1st DVI output is going to Optoma HD81 projector with 1080p@23.976hz

Audio is being sent through 2nd DVI output with ATI's HDMI adapter to Yamaha RX-V3800 as PCM (with WASAPI Exclusive mode under Vista SP1).

It seems to be working very good, except for few issues:

1. At the information window, Reclock states that the video hardware is sending 1080p@23.976hz, which is correct. but, it also treats the display device as 1080p@24hz. Shouldn't it be treated as 1080p@23.976hz as well ?

2. Vsync correction is only available when using auto mode, and in this mode Reclock states that the movie is being played at 24fps.

I think it should be played at 23.976fps instead because the HTPC send 23.976hz signal to the display, but then of course I don't have the Vsync correction option, so what should I do ?

3. I can't get Vsync correction to work with Haali Renderer, even if I use auto mode. If I use Aero then it doesn't tear, but it stutters like hell.

4. Let's say I check "force reference clock to audio". If I do this then Reclock states that both video hardware and display are 1080p@24. What will happen in this situation ? Will Reclock play the movie at 23.976fps or 24fps ?


Thanks in advance.

[red5goahead]

which is the player? dvi-1 is on the primary monitor, do you have a multimonitor configuration?

I've a 3850 Ati. no stuttering but 23,976 is accelerated to 50 HZ/Pal
(I'm Italian and I've not a 24p compliant tv)

Try evr + aero + vsynch reclock .
move the slide cursor in right position than default one. And try , move again and try with new setting and so on how far you got a good result.

Do you have a orange dvi and a white one on the video card? whatever choose the orange one.

[MarioMan]

I'm using both Zoom Player 6 and MPC Homecinema, and yes, I have a multimonitor configuration (Reclock identifies correctly which display carries the movie)

EVR works fine, but Haali Renderer is the problem.

As for the slider position - it is in the right position, but the Vsync pointer doesn't go there.

[red5goahead]

multimonitor in extended desktop or clone?

Use primary monitor always (it a key for Ati system I don't know for Nvidia cards).

Evr work fine so why not? :D

Imho evr is the best choice for Vista. Without Aero I've the same issue.
Vsynch correction isn't fired and I got jerky play. With Aero no problem.
Media Portal start jerky but in few seconds reclock correct the vsynch postion into the area configurated by its slider control.

[Jong]

I am not an expert in Haali, but others who are say it has own Vsync correction. Although Haali's method appears not to be perfect using both is unlikely to make it so, although it may change the type of stutter you see.

If you have your refresh rate set to 23.976Hz and Reclock on "Auto" it will be adapting the frame rate to 23.976Hz, whatever it says. It is just one of the quirks of Reclock's information display, much discussed here, that James does not want to fix.

[Zardoz]

I am not an expert in Haali, but others who are say it has own Vsync correction. Although Haali's method appears not to be perfect using both is unlikely to make it so, although it may change the type of stutter you see.

If you have your refresh rate set to 23.976Hz and Reclock on "Auto" it will be adapting the frame rate to 23.976Hz, whatever it says. It is just one of the quirks of Reclock's information display, much discussed here, that James does not want to fix.

That's probably not accurate. My latest impression is that it is not only cosmetic but the audible impact is not large enough to warrant a change in reclocks behaviour. That's what James hinted at in his latest replies to the 48048hz display when playing 23.976 material at an exact multiple screen refresh. Basically what seems to be happening can eithe be
A:
1) If screen refresh is near 24.000 Hz (including 23.976) this is unfortunatly set as the "target" frequency
2) the differential actual frame rate/frame rate mod 24.0000 is used to calculate upsample rate and audio in upsampled to 48048 hz
3) in real time reclock now adjusts the 48048 audio to the real screen refresh rate. If you really got an exact multiple of frame rate (e.g. 23.976) is is manipulated to play at approx 48000 Hz again
4)this then is resampled again to match the exact 48000hz required by DSound/Waveout
B:
1) is the same
2) only the Hz differential calculated not actually resampled
3) again only the new differential is calculated but not resampled
4) here resampling must take place multiplying the two differentials

As this last step is only avoidable by WASAPI/Kernel Streaming or dropping PCM packets. The last option (dropping/repeating packets) is used for SP/DIF because resampling is not an option here. If A is used its not cosmetic - if B is used it could be called cosmetic, and its the way it should be done. But unfortunatly A might be used....

[James]

That's probably not accurate. My latest impression is that it is not only cosmetic but the audible impact is not large enough to warrant a change in reclocks behaviour. That's what James hinted at in his latest replies to the 48048hz display when playing 23.976 material at an exact multiple screen refresh. Basically what seems to be happening can eithe be
A:
1) If screen refresh is near 24.000 Hz (including 23.976) this is unfortunatly set as the "target" frequency
2) the differential actual frame rate/frame rate mod 24.0000 is used to calculate upsample rate and audio in upsampled to 48048 hz
3) in real time reclock now adjusts the 48048 audio to the real screen refresh rate. If you really got an exact multiple of frame rate (e.g. 23.976) is is manipulated to play at approx 48000 Hz again
4)this then is resampled again to match the exact 48000hz required by DSound/Waveout
B:
1) is the same
2) only the Hz differential calculated not actually resampled
3) again only the new differential is calculated but not resampled
4) here resampling must take place multiplying the two differentials

As this last step is only avoidable by WASAPI/Kernel Streaming or dropping PCM packets. The last option (dropping/repeating packets) is used for SP/DIF because resampling is not an option here. If A is used its not cosmetic - if B is used it could be called cosmetic, and its the way it should be done. But unfortunatly A might be used....
B
(ReClock only resamples *once*)

[Mark_A_W]

Marioman,

I have a multimonitor setup on Vista32. Video is played on the secondary monitor, smoothly, no tearing, using the Haali Renderer.

It took me a lot of time to get right, but one key thing is Aero MUST be disabled when using multiple monitors.

One monitor = use Aero.

Two monitors = Aero causes CHAOS.


I found that I do not get tearing in Vista with the Haali Renderer.

After debating with James, I am not using Vsync correction with the Haali Renderer. If you turn Vsync display on, you will see the Renderer and Reclock fight each other, and the Vsync position never sorts itself out.


So, I suggest:

- Haali Renderer
- Aero off
- Reclock Vsync off

It's working well for me.

Mark

[Zardoz]

B
(ReClock only resamples *once*)

Good to know!

[red5goahead]

my suggest:

- Evr on primary monitor (i've two monitor but entering in Media portal I switch the monitor)
- Aero on
- Reclock Vsync on (found the correct slide position is not too hard)

It's working well for me.

ps: Media Portal do not have haali renderer.