I believe I debugged a problem which I've narrowed down to an IRsend timing issue.  I wonder if someone with more knowledge of Linux internals can consider my conclusions and comment on whether I'm correct or not?

I'm using "irsend" to send commands to a Samsung TV.  Both a real and "fake" Samsung remotes send the same key twice in rapid succession and it seems that the TV allows a period of time during which a second occurence of the same code is ignored.  I understand this is done for reliability reasons as if one of the pair is corrupted, the other probably arrives OK.

Unfortunately sometimes this fails, for example, if try to send (pairs of) the keys "1", "2", "3", the TV might react as if I've sent "1", "2, "2", "3".  When this "duplicate" detection occurs is very random and, for example, when sending a "macro" of 11 keys, any one of them might be detected as a duplicate but it could be any of the 11 with no reproducibility.

What I believe is happening is that LIRC (probably the lircd daemon) sends the first of a pair of codes but then the time period until the second of the pair (remember each code is sent twice) is occasionally longer than expected.  The Samsung TV has given up ignoring duplicates and treats the second of the pair as a NEW code.

I've seen similar to this on DOS/Windows where timers get delayed because of interupts etc and I suspect something similar is happening here.  Do you, the reader, agree?

If so, is there a way to send the pair of keys with a more reliable interval between them so that this doesn't happen?  For now I've had to stop the "send twice" and this seems to work but obviously it would be better, and presumably more reliable, if I could follow the example of teh Samsung remote and send a pair of each code.

Paul D Smith