Android App

I believe there was a third option Steve, earlier versions of SSDR would process the data in the receiveUDP callback whereas now Eric simply adds it to a queue, as I was pointing out to William, and processing each in a non-IO thread. Once that changed I no longer had an issue. In fact, the only time I did have an issue was if the monitor slept and when it woke up it would be like hyperdrive (my thread of similar name) trying to catch up but there were no UDP interrupts so just mostly blank lines came out. Again, after the queue change all is fine.

https://github.com/chriswhocodes/DemoFX
download the zip, build with ant
./run.sh -s true

the difference between hardware acceleration  and software acceleration is 61fps v 30fps, still better than the 24 I believe SSDR has.

@Sal, that's kind of cool. I am confused though. What was driving the the two monitors? Was this with SSDR driving the monitors and William's android app moving the frequency? You were turning the dial on the Nexus as well as the Flex Control

Another question I have is how married to Processing are you? When I mentioned JavaFX8 before, it natively uses GPU via Prism and you can move the app to any platform via the Gradle build script. That zip file will demonstrate between run.sh and softrun,sh the difference in performance by offloading the graphics to the gpu vs doing it in source. Something to think about.

try this:

void startMyTask(AsyncTask asyncTask) {
    if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB)
        asyncTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
    else
        asyncTask.execute(params);
}

In early versions of Android, if you had multiple asyncTasks only one would run at a time, exactly what you are describing. This tests for the version of Android and dispatches the asycTasks accordingly.

Or, upgrade to 5.x
Actually, I am glad you told me that as, I am running on 5.x but when it goes to GooglePlay it may be downloaded to an earlier version so I will do the same when I have asyncTasks.

As I don't know what hardware or version of Android William has I can't say definitively you are wrong but I am almost positive you are wrong. The days of 'waiting' in a spin loop are about 20 years past. Android derives from Linux and Linux is a multi threaded kernel. The thread listening for IO from the TCP/IP stack is in a wait, this gives any other thread an opportunity to run. Ultimately the thread is blocked  waiting on the main OS's TCP/IP stack. when an packet arrives for that port the thread is marked runnable. The concept of Executor is new in Java5 Even if there was but a single process that was time slicing multiple threads each thread would still get access to the cpu, so long as it was runnable. William, you aren't doing anything with synchronization are you? That could be killing you. I don't believe you are blocked where you think you are blocked.

What version of Android are you running and what is the tablet manufacturer and model? Also, if you go to settings->about and look for model, version, and kernel. You should be able to model what is happening in the VM emulation. Is it possible to copy the code running under asychTask?