EnTech Taiwan EnTech Taiwan
July 22, 2017, 08:51:08 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1] 2 3 ... 14
  Print  
Author Topic: [RAMDAC][PLL][RefreshRate] Some low level questions ;)  (Read 96370 times)
Seb.26

Posts: 29


« on: May 20, 2008, 05:49:52 AM »

Hi  Tongue

I'm actually using pstrip to obtain about 48Hz on my HTPC ( based on Opteron dualcore @2.5GHz and ATI Saphire HD3470 PCIe )

I also use Reclock to provide accurate clock to Directshow vid?o render, and to adapt all vid?o streams to 24fps (by resamplign sound on the fly).

My problem is that I cannot obtain stable & smooth playback (using HaaliRender)

The first step to obtain perfect playback is to have perfect refresh rate, this is the task of pstrip.
( perfect refresh rate is needed not because my eagle eyes see the fluctuation, but because Reclock need this to allow smooth Wink )

In pstrip, I've asked for 48.000Hz refresh rate, but the 'camera test' never return 48.000 ... I've made about 20 tests, and 70% were 48.005, other 30% were sometimes greater and sometimes lower ... with about +/-0.030 error ( so from 21.24 to 20.82 ms per VBL ...  )

So : what happens ?

My first idea was that the VBL is stable but pstrip 'camera test' isn't perfect and the error is from it ...
-> I think this is not the case ...
The use of QueryPerformanceCounter() and QueryPerformanceFrequency() often provide at least about microsecond measuring solutions ... ( Am I wrong ? )

So the problem is elsewhere IMO ... could the VBL oscilate around desired frequency ?
If yes : in what case this could happen ? ( PLL divider round problem ? hardware limitation ? )
... and how could I ensure a stable refresh rate ?

Thanks for help
Seb.
Logged
Rik Wang
Administrator
*****
Posts: 8833


« Reply #1 on: May 21, 2008, 07:12:45 AM »

Everything worth saying about these subjects - by me anyway - has already been said here, and more than once at that.  

Rather than rehash this stuff again in yet another thread, if you do a search here you'll find more background than you probably want to sift thru...
Logged

leeperry

Posts: 225


« Reply #2 on: May 21, 2008, 09:03:02 AM »

Hi Rik

I think what Seb.26 would like to see in pstrip is some more advanced mode, where you can actually see the real PLL settings that are used.

because to get 100% rock stable frame rate with Reclock and Haali's Renderer, you need to be SPOT ON 48.000/50.000/60.000 etc...

I've actually had a very HARD time getting 60.000

if I change a single figure in my advanced configuration, I fall back to 59.999 Sad

we understand this kind of accuracy is not that relevant, but actually for Reclock IT IS Sad

besides, on the HD3xx0 ATi serie, you can't get 50.000 for instance.
whatever the pstrip camera or Reclock say 50.001......so that ruins the whole point of using Reclock Sad
Logged
Rik Wang
Administrator
*****
Posts: 8833


« Reply #3 on: May 21, 2008, 09:46:08 AM »

I'm afraid you won't ever see anything like that *in* PowerStrip - for reasons that ought to be obvious. You need to look elsewhere for a solution - perhaps Reclock or the display driver or the OS?

(Actually I feel sure you need to look for a different class of hardware, but that's a conclusion you need to reach on your own.)
Logged

leeperry

Posts: 225


« Reply #4 on: May 21, 2008, 09:57:04 AM »

haha, I don't quite agree.

I'd say pstrip is a fantastic tool....but it's not advanced enough.

it takes quite some time to get perfect 48.000/50.000/60.000

I'd say the GUI is not advanced enough

I would guess that the computing scheme that works behind the GUI could offer more advanced settings ?!

I understand it's your choice not to offer such advanced settings, and that's what I told Seb.26

too bad they can't get exact 50.000/60.000 Hz on their HD3xx0, which -with a lot of patience- I've managed to get on my HD2600  Cool

the MPC HC jitter test is the best test I've found.

it basically divides the refresh rate /2, so if it's rock stable there.....that means you've reached perfect 48/50/60.

my 48 and 50 are PERFECT, and my 60Hz is almost perfect, just slightly oscillating once in a while.......but definitely good enough  Cool











Logged
Seb.26

Posts: 29


« Reply #5 on: May 21, 2008, 11:26:57 AM »

OK Rik, thanks for "replying" ...  :?

I've read some good posts about this here ... I will continue ... Cool

Just another question :
How could you explain that when I set 48.000 in pstrip, I obtain 48.005 in 'camera test' ? ...
Logged
Seb.26

Posts: 29


« Reply #6 on: May 21, 2008, 11:27:28 AM »

-- Double post ---
Logged
Rik Wang
Administrator
*****
Posts: 8833


« Reply #7 on: May 21, 2008, 01:10:35 PM »

Quote from: "Seb.26"
Just another question :
How could you explain that when I set 48.000 in pstrip, I obtain 48.005 in 'camera test' ? ...


Sure, its apples and oranges.

When you set 48.000Hz in PowerStrip, PowerStrip programs the hardware to provide as close to that as it can. There is no such thing in hardware as a "refresh rate" - you have so many pixels being pumped out at such and such a clock rate, and dividing one by the other gives you the "refresh rate". If you want to measure the result you need to use a hardware frequency counter.

When you click the camera, PowerStrip - using QueryPerformanceCounter as you surmised in your initial post - clocks how long it takes to execute 100 DirectDraw.WaitForVerticalBlanks, and then divides one by the other to yield an average "frame rate".

When you consider the software overhead in a multitasking OS, servicing multiple pieces of hardware and with multiple pieces of other software running, well... a fluctuation of 0.01% is not unexpected. To improve it, check what you are running in the background. And naturally, if the sample was increased from 100 to 1000 or 10000 VBs, the variance would go down.
Logged

Seb.26

Posts: 29


« Reply #8 on: May 21, 2008, 01:46:47 PM »

I'm 100% OK with what you say (about measuring time for x VBL count in real time OS ), but  I always have +0.005 Hz in camera test, not only sometimes due to RTOS issue ...

For exemple, if I "ask" for 60.000 (with 89.1KHz pixel clock) in pstrip, I have 95% of 60.008 result in camera test (other 5% values are for sure due to measuring error) ...

For 50.000Hz (72.250 pixel clock) , I've got  about 95% of 50.006Hz result ... And 48.005 for 48.000 asked ...

Strange, isn't it ?  Wink ... Like error is proportional to pixel clock ...  :?:  :!:
Logged
Seb.26

Posts: 29


« Reply #9 on: May 21, 2008, 01:55:25 PM »

I think pstrip clocking use something like :

Code:
TimeStart = Now()
repeat 100 times
  WaitVBL()
end
TimeStop = Now()

VBL_Duration = (TimeStop-TimeStart)/100
VBL_Freq = 1/VBL_Duration


So, if RTOS take CPU for some unpredicable reason, VBL_Duration will be longer, so the VBL_Freq will be lower than real VBL freq, never greater ...  Wink

But in any case, that's not the real matter ...  Wink

The main matter is trying to find a way that allow getting stable clock, not to reach perfect 48.000000000 refresh rate ...  Wink

My real ask is : does pstip allow user to specified pixel clock that hardware cannot provide ?
... and if "yes" what happens ? ( does the hardware PLL oscillate around the specified pixel clock ? )
Logged
Rik Wang
Administrator
*****
Posts: 8833


« Reply #10 on: May 21, 2008, 04:22:29 PM »

Quote
does pstip allow user to specified pixel clock that hardware cannot provide ? and if "yes" what happens ?

It depends on how you enter it. You can feed PowerStrip values (e.g., thru the API) values that arenot possible/stable, but it will end up using whatever is closest. And the value it ends up using is what will be read back (not the value you asked for).

1. The hardware is always programmed in hertz, not fractions of a hertz.

2. It is not possible to program the hardware to produce a value it cannot generate.

3. It is possible to program the hardware to produce a value that it cannot generate stably, for example a pixel clock of 27.000MHz is just fine at 640x480 but would produce horrible results at 2560x1600.
Logged

Seb.26

Posts: 29


« Reply #11 on: May 21, 2008, 04:51:50 PM »

Code:
3. It is possible to program the hardware to produce a value that it cannot generate stably, for example a pixel clock of 27.000MHz is just fine at 640x480 but would produce horrible results at 2560x1600.

Sorry, I don't understand this point, could you explain it please ?

...

There is probably a point I miss ...

For me, graphic card have a fixed source clock at 27MHz (a quartz)

From this 27MHz signal, a PLL chip build the pixel clock.

The pixel clock with total pixels count (for each frame) result in the final VBL freq.

( Am I wrong here ? )

pstrip allow tweaking of PLL setup and total pixels count of the frame ...

But asking the PLL a pixel clock that it couldn't produce isn't possible ... and the per frame pixels count stay the same.

So the final VBL freq cannot oscillate if the source clock (the 27MHz quartz) doesn't oscillate.

Am I right ?  Wink
Logged
Seb.26

Posts: 29


« Reply #12 on: May 21, 2008, 04:52:33 PM »

-- Another double post --
Logged
Rik Wang
Administrator
*****
Posts: 8833


« Reply #13 on: May 21, 2008, 05:10:53 PM »

At a clock rate of 27000Hz and 2560x1600 pixels, the refresh rate would be ~4Hz. All I meant was that while the clock itself would be stable, the result would not.
Logged

Seb.26

Posts: 29


« Reply #14 on: May 21, 2008, 05:16:54 PM »

Quote from: "Rik Wang"
At a clock rate of 27000Hz and 2560x1600 pixels, the refresh rate would be ~4Hz. All I meant was that while the clock itself would be stable, the result would not.

OK ... I haven't try to compute the output VBL freq for your exemple ...  Wink
( 4Hz VBL freq is perfect if you want to play 4fps clip ... )
Logged
Pages: [1] 2 3 ... 14
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.15 | SMF © 2006-2008, Simple Machines Valid XHTML 1.0! Valid CSS!