This posting is older than 6 months and can contain outdated information.
I note the stars around "in hardware".
With regards to the Apple Remote, these are only around for the EyeTV Receiver, which is a different piece of hardware than the Apple IR Receiver that is being talked about in this thread.
Of course it is not done in hardware, it is done in a level of software that Apple tries to keep out of your reach.
Maybe EyeTV grovels down there somewhere and that is what upsets Remote Buddy.
This isn't the case.
As I said before:
The IR signals are received and decoded directly inside the Apple IR Receiver and NOT by any OS X driver or part of OS X. Of course the receiver hardware will run some kind of firmware, but I don't consider this a part of OS X (since firmware, by definition, is OS independent and will and doesn't work any different under Windows, Linux, ..) nor any attempt of Apple trying to keep anything out of anyones reach. It's normal for USB devices to have firmware to communicate via USB just as well as the kind of IR receiver Apple uses has been around before and is known as "HID receiver". The opposite are "raw receivers" that just pass through the raw IR signal. The Apple IR receiver, however, does not do this.
In the scope of this discussion, the question was whether there's any difference whether Remote Buddy can have any impact on the quality of decoding the IR signal. Since the Apple IR Receiver is a normal HID receiver (and is actually showing up and behaving as a normal HID device on the USB bus), where the decoding of the IR signal is happening directly inside the receiver itself and not by any driver, there can't be any differences. A difference could only be possible when receivers like the Microsoft MCE receivers are used which - unlike the Apple IR Receiver - do provide access to the raw IR stream without any protocol parsing.
And just to answer the logically next question in advance, too: no, Remote Buddy doesn't load its own firmware on the Apple IR Receiver nor does that receiver need any firmware upload. The firmware that is part of the Apple IR Receiver is used at all times.
As I said before: this is not a software problem. I already listed two common physical problems. You'll find more possibilities in the FAQ.
Some really odd stuff happens with a combination of Remote Buddy, EyeTV 3.3 and Front Row on current MacOS. I am finding it hard to diagnose because it does not always seem to be consistent.
I'm sorry, but since the IR signal is decoded by the IR Receiver itself, the driver code really is dead simple and I can't see how code that effectively looks like this
[..]
if (receivedValue == 0x01) { buttonPress = kButtonCodeLeft; }
if (receivedValue == 0x02) { buttonPress = kButtonCodeRight; }
if (receivedValue == 0x03) { buttonPress = kButtonCodeReleased; }
[..]
could behave randomly or not consistent all across the board.
On the other hand, unconsistent behaviour *is* the rule for physically originated problems. Which can have many origins from light to the position of the sender and receiver, to how (and if) the surrounding reflects IR light - and even the shape of the sender:
The new Apple Remote, for example, *does* have other physics than the old Apple Remote. Take a look at the IR window on the front: the old Apple Remote had a broad window over the full width of the remote. The IR diode did rake out of the white plastic case and could send freely in all directions. Compared to that, the new Apple Remote's IR window spans only about 30 percent of the remote's width and the IR diode is completely embedded inside the casing, limiting the directions in which the IR signal is emitted from a full 180 degree (a half sphere) to just a fraction of an estimated 90 degree.
If you have both, feel free to fire up Photobooth and press a button on your remote, then check in which angles you can see the IR diode flash.
Shutdown either EyeTV or Remote Buddy and everything seems to work as it says on the tin, but with both running it is hard to get consistent results.
EyeTV is now using my HID code (as publicly available at http://www.iospirit.com/developers/hidremote/ ).
Remote Buddy uses its own driver.
When Remote Buddy is not running, EyeTV uses my HID code to receive Apple IR Receiver HID events - sent by the Remote Buddy driver.
When EyeTV is not running, Remote Buddy continues to receive events just like it does when EyeTV is running. It makes no difference.
When neither EyeTV nor Remote Buddy are running, Front Row receives the exactly same HID events like EyeTV from the Remote Buddy driver.
Resumée: effectively the same piece of code is used in all cases / scenarios. So where's the difference? There's only one:
Some apps (like EyeTV, Plex, Remote Buddy, ..) distinguish between long and short presses in all circumstances and react differently to them.
Others (like Front Row) don't always do (f.ex. two short presses in a list behave like one longer press). You're of course going to notice the consequences of physical problems much quicker if you use apps that do distinguish vs. apps that don't. Bad reception or a too high signal-noise ratio can lead to signal interruptions or a corrupted IR start sequence that the IR sensor can no longer make sense of.
That doesn't make such issues software issues, though. The origin remains physical.
Best regards,
Felix Schwarz
