Hi,
Why is the user input so slow? When I press a key in remote, there seems to be a random delay of 0-0.5sec or so.. Sometimes it's fast, sometimes not. It's fine in channel switching but really annoying when you a trying to input filenames or something.
I have been using VDR for two years and the problem has always been there.
However I just made another VDR box, that doesn't have any DVB cards. It just streams data from the bigger box, with streamdev. Remote control is really fast and snappy here, no lag at all! So is it the DVB handling that slows vdr down? Perhaps some priority issue that could be adjusted?
Both boxes use dxr3-plugin as output device, and pretty much identical software setup (copied over from box1 to box2)..
VDR version is 1.4.5.
-- Teemu Suikki http://www.z-power.fi
On Thu, 15 Feb 2007, Teemu Suikki wrote:
.. Replying to myself.. The problem seems to be in kernel level after all, I enabled ir_debug in budget-ci module and the same delay is there as well, debug log appears at the same time as vdr reacts to the keypress.
-- Teemu Suikki http://www.z-power.fi
On Thursday 15 February 2007 11:30, Teemu Suikki wrote:
This is a known driver problem: a link to a patch was posted a few weeks back which removes this delay. See: http://www.linuxtv.org/pipermail/vdr/2007-February/011994.html
I've always had more success with a home-brew LIRC receiver on a serial port.
Cheers,
Laurence
On Thu, 15 Feb 2007, Laz wrote:
I think I'll go for LIRC too.. :( I installed the above patch, it is slightly better but not very much.
-- Teemu Suikki http://www.z-power.fi
On Thu, Feb 15, 2007 at 04:37:16PM +0200, Teemu Suikki wrote:
But are you using the cx88 kernel module? My patch probably breaks all other drivers depending on ir-common.c or ir-funtions.c, as it is called in later 2.6 kernels. I'm talking about this patch, which I have been using since I made it:
http://www.iki.fi/~msmakela/software/vdr/linux-2.6.15.2-cx88_input2.patch
As far as I understand, the cx23882 features a 32-bit shift register for sampling the output of the infrared receiver and generates an interrupt after every 32 shifted bits. I don't know the shifting frequency, but let's assume that the shift register takes 6 samples of each time base T=16/9 ms. The duration of a whole RC5 frame is 64*T, or about 114 ms. The worst case delay of the shift register would then be something like 32*(T/6) = 9.5 ms. By Nyquist's sampling theorem, the absolute minimum sampling frequency would be 1/T (because the minimum pulse width in RC5 code is T/2). Thus, the maximum delay caused by the shift register would be 32*T = 57 ms. I don't think that you can notice that kind of delays, nor that you would get much smaller delays with LIRC.
Marko
On Thu, 15 Feb 2007, Marko Mäkelä wrote:
I use budget-ci, but I tried to find the correct places in the source code.
Your had changed the ir-functions.c key repeat handling, and that seemed to be a good improvement.. But the lag is still there. It might be a hardware issue in the nova-t dvb card. Remote input is interrupt driven so it should be reasonably fast, but perhaps the dvb data transfer blocks the i2c interrupt for too long..
I don't think that you can notice that kind of delays, nor that you would get much smaller delays with LIRC.
My other box uses RCU-compatible remote receiver in serial port, and that seems to be blindlingly fast. Obviously it is much more direct connection to VDR, because VDR handles the serial port directly.. I have to think of something similar to this box as well.
-- Teemu Suikki http://www.z-power.fi
On Fri, Feb 16, 2007 at 03:54:19PM +0200, Teemu Suikki wrote:
Can you please post your patch, so that I and others can review it? Maybe we really should try to get this into the kernel.
Marko
PS: I have two Hauppauge Nova-T PCI 90002 cards, and I rarely need both cards. If it eases troubleshooting, we could swap cards.
-
Laz -
Marko Mäkelä -
Teemu Suikki