News for hackers. Stuff that matters.
Re:Terminal latency (2017) by squarefoot on Wednesday March 20, 2019 @02:15PM (#19445115)
"As a keyboard player, I can tell you that anything over 10ms latency noticeably degrades the experience."

Which explains why unless I missed some new development, there's no way professional music can be played live on any Android based product. By music I mean music, not triggering prerecorded loops, a thing which could be done on a 50+ years old Mellotron as well. I'm 100% sure Java is to blame: low latency and virtual machines don't mix well.

Re:Terminal latency (2017) by brian_cloutier on Wednesday March 20, 2019 @07:24PM (#19447992)
> I'm 100% sure Java is to blame

I shouldn't but I will anyway: People who are 100% sure of things are generally wrong and this case is no exception.

I'm being facetious here but what if I told you that nearly all machines are virtual machines? Your CPU doesn't really execute instructions, it interprets them by first translating them to microcode.

There's nothing inherent to the idea of not coding directly on the lowest level possible which forces your programs to have bad performance. Zero-cost abstractions really do exist.

I mean, Erlang uses a virtual machine called BEAM, erlang programs sit at a remarkably high level of abstraction, and it's not like erlang systems are known for their chronically high latency.

The Android Runtime also compiles applications before running them [1]. The instructions being run are native code in elf files [2].

Certainly Android has had latency issues, and I'm no fan of Java, but that was more of an architectural thing than a Java-Is-Such-A-Bad-Tool-Lol thing.

[1] https://source.android.com/devices/tech/dalvik [2] https://stackoverflow.com/questions/26254538/difference-betw...

Re:Terminal latency (2017) by rayiner on Wednesday March 20, 2019 @10:37PM (#19448858)
> I'm being facetious here but what if I told you that nearly all machines are virtual machines? Your CPU doesn't really execute instructions, it interprets them by first translating them to microcode.

Well that’s not true.

Re:Terminal latency (2017) by Phrodo_00 on Thursday March 21, 2019 @01:58PM (#19455320)
Re:Terminal latency (2017) by nneonneo on Wednesday March 20, 2019 @02:46PM (#19445442)
You can develop apps in C/C++ with the NDK, cutting out Java almost entirely and avoiding its associated latencies. This is what all serious games do.

However, the lack of a widely-supported low-latency audio stack is still a killer.

Re:Terminal latency (2017) by romwell on Thursday March 21, 2019 @03:48PM (#19456495)
Android Oboe[1] might fix that (an API that goes through (OpenSL ES or AAudio depending on what is available).

Then, in future far, far away we might get a touch input method that isn't too laggy for interaction with audio. Last year, the best we could get was around 30ms[2] on iSomething; and I hope that 120hz refresh rate becomes the standard (but even that is huuuuge compared to a MIDI controller).

[1]https://github.com/google/oboe

[2]https://www.reddit.com/r/Android/comments/7teiwe/lets_discus...

Re:Terminal latency (2017) by romwell on Wednesday March 20, 2019 @05:35PM (#19447192)
>There's no way professional music can be played live on any Android based product.

There are some very recent developments on that frontier[1]. Let's hope that the new Oboe API will result in usable music software on Android.

I have a DX7 emulator on Android that is pretty good latency-wise when used with a MIDI controller.

Sadly, touchscreen latency is still way too big for anything musical (and the new Oboe API doesn't address that).

[1]https://android-developers.googleblog.com/2018/10/introducin...