Ah sorry about that.
I've merged that pull request and pushed again.
Actually, I ended up having to do a "force" push, because I think you added to the pull request, and I got a bit confused. Hopefully that won't cause you any problems.
I though you normally worked the night shift
I agree with this analysis.IanB wrote: ↑Mon Dec 03, 2018 4:16 pmThere is one new issue I just noticed: Labyrinth now has problems with the pixel clock. This is probably due to the wrong field length resulting in a calculation error. A fix might be to time a known number of video lines such as the active 270 line video block rather than a whole field assuming the line length is unchanged or maybe fall back to known pixel clock values if an out of spec signal is detected. Also it won't genlock but it may never genlock if there is insufficient adjustment range of the HDMI PLL.
For whatever reason, Labyrinth uses 634 lines per frame, which gives it a vsync rate of 49.288 Hz.
I think we need to do two things:
1. For the sampling clock calculation, measure over a fixed number of lines. If we do this we can drop N_LINES from the geometry. We might also be able to drop CLOCK_FREQ, as it would then just be used I think for the PPM error.
2. For the HDMI clock calculation, we still need to measure the source vsync time, as measure_vsync currently does.
I would suggest leaving measure_vsync as is, and add a new method that measures the duration of N lines.
Code: Select all
int measure_n_lines(int n_lines);
And measure_vsync() would only really be needed if the HDMI clock control was enabled.
I'm happy to have a go at this now if you like?
P.S. I just spotted an amusing bug: genlock only works if the vsync indicator is visible. As soon as you turn this off you get:
Code: Select all
INFO: Lock lost probably due to mode change - resetting ReSync counter
https://github.com/hoglet67/RGBtoHDMI/c ... ef7296?w=1