Stereo Tool

Well, in principle it's easy enough to turn all x86/amd64 stuff off. There are 3 problems with that though:
1. I need to compile it for the cpu used by Raspberry. That's probably the easiest part.
2. Here it gets more difficult: I use some libraries and they also must be available (for a command line version it's a lot easier). The Intel IPP library contains 2 filters that I use a lot. I can easily program them myself (in fact, I used my own code upto version 4.22). The output is identical, but intels version is 2 or 3 times faster...... They obviously know their own processors better than anyone, and I'm guessing that they employ anlot of people who do nothing else than optimizing this code. There's no way I can compete with that without studying a lot and focussing solely on this single function for - well, a long time. And I probably still wouldn't get close (I found a benchmark of dozens of implrmentations of this filter and mine would actually be one of the best ones - but Intel beat all of them by at least a factor two.
3. A lot of cpu-specific optimizations in my own code would have to be switched off.

Points 2 and 3 will severely hurt the performance. And the CPU in the Raspberry isn't very fast to begin with as far as I know.

Interesting benchmark - which confirms that the Pi is (relatively) slow compared to modern pcs. Good enough for most purposes, but not really for this (some simple processing is definitely possible though).

Well, gee-whiz. I'm not suggesting that I should be able to stroll up to a client's transmitter... be able to plug in my ST-powered Galaxy 3 to the composite input of their exciter... and blow away a purpose-specific O* box.

A phone might be even more difficult actually. If I run the same HTML5-code on my Samsung Galaxy S3 and my pc, then the pc can smoothly draw images on 2 1280x720 monitors at 60 fps using one core, while a single full-screen (which is considerably less than 1280x720 pixels) on the phone only reaches about 5 fps.

The CPU in the phone isn't slow, what I think is happening (warning: I haven't checked this, I could be completely wrong) is that apps on Android phones are written in Java, which adds an extra layer that really kills the performance. I think (again, I could be wrong) that the difference in speed is too big to be explained solely by the fact that the CPU in the phone is slower.