rtundo,

I have implemented the interaction with WinLirc in a different manner which provides much quicker response than the prior. You should donwnload the latest EMSC and see if that makes your remote more responsive.

I guess a little explanation on what the parameter for "maximum reliable repeat rate (MRRR)" does in the current implementation, will help you tune that value to provide the best response.

IR Remotes send signals only when the buttons are pressed. There is no signal that tells you when the button has been released. The remotes, however, continue to send repeat signals (which can be recognized as such) at a certain rate. Due to the layers imposed by WinLirc, and the complexity of some remotes, these signals reach the application at somewhat irregular intervals. For example, my Pioneer SR-90 is particulary difficult to decode, and WinLirc will not decode a repeat signal every now and then, sometimes several in a row. So, while the interval between repeat signals for this control should be around 180 millisecs, the delay is sometimes 360, 540, or exceptionally even 720 millisecs.

The fact that we want to distinguish between short, long, and sustained presses complicates things when we have this irregularity. (180 is very responsive, buty 540 is sluggish).

Here is what the new implementation in EMSC does:

Receives the first signal from the remote and does nothing. We dont know if it is a short or long press yet. If a repeat signal is not received within MRRR seconds, then EMSC knows it was a short press and takes action. So MRRR determines the lag in time before EMSC can be sure that a button was pressed "short".

If the repeat signal arrives before MRRR msecs have passed, then EMSC knows that it is not a short press right there and then, and takes appropriate action immediately. So even if I you set MRRR to 740, if the repeat comes after 180 millisecs, the action associated with a long press will take place right then without having to wait for MRRR millisecs. If the button is one of those associated with a sustained action, like scrolling a menu, changing volume, or fastforwarding; then every repeat will take the appropriate action as the signals are received.

When more than MRRR millisecs have elapsed after the last repeat, then EMSC assumes that working with that button has ended. However, sometimes a delay larger than MRRR msecs will take place between repeats. EMSC just ignores the repeats that follow because it doesnt want to take a short or long action that wasnt intended. What you will see when this happens, if you are scrolling a menu list for example, is that scrolling stops after a few scrolls no matter how long you keep the button pressed.

So the value of MRRR you choose has impacts in how long you have to wait before a short press can be determined as such. You want the smallest value possible. However, when the actual repeat generated by the remote and decoded by WinLirc is longer than MRRR, then the sustained action you want to carry will stop. In this case, you want MRRR to be larger than the maximum possible repeat rate.

You should set an MRRR that gives you reasonable response time when you want to execute short press actions, but that at the same time doesn't stop sustained actions too frequently (e.g., press down to scroll a menu, actually go down 3 or 4 items, and then no more scrolling until you release the button and hold it down again can be very annoying.)

If the remote is easy to decode and consistent, like the Rio Car remote, then the repeats are pretty regular and shortly spaced. This allows you to use a rather low value of MRRR, obtaining quick response and no interruptions in sustained presses. Check with your Rio Car remote to see this, then compare with the thing you really want to use.

Im pretty sure the new EMSC with the behavior described above and a properly tuned value of MRRR will get you a better experience than what you have been experiencing.

Let me know how it goes.

-Jules