On Android devices (and smartphones in general) - hardware would be the limiting factor.
It just takes a SCHED_FIFO task with forced CPU affinity. Android does not make it easy to get one.
There are some other hardware issues, like audio input and output using separate clocks on Qualcomms, but that's at most one extra buffer.
Speaking of this, you can have sub-millisecond latencies on Beagleboard. These devices in phones are vastly more powerful.
Are you aware of any non-RTOS that "makes it easy to get one"?
> "Speaking of this, you can have sub-millisecond latencies on Beagleboard."
I did not make myself clear, so I'm taking the blame here.
I'm mostly interested in the use case. If it's just capturing audio alone, this number makes sense, and no fancy hardware is necessary.
The moment we're introducing some-kind of processing, or even logging the stream to disc, buffering becomes necessary and latency is introduced. Assume audio stream read by a "user-mode" service, then redirected out through headphones - are we still talking sub-millisecond latencies?
The problem on some platforms is one of architectural choices and prioritization. On Android we know they started with the already arguably poor latency Linux audio foundation of ASLA, then layered on and layered on (flingers and HLAs and user-mode transitions), each layer adding its own ring buffers.
Even on Windows, on the fastest PC known to man, audio has generally poor latency (because it's architectural) which is why audio software makers have their own hardware->application drivers (ASIO).
Low latency audio was not important to the project, and they dug themselves in so deep that for many years we've been hearing recurring "We've finally solved that latency issue" claims.
[1]: http://bela.io
The real time audio APIs are in native code and they can request for priority use when on foreground.
Samsung used to support real time audio on their S models since many years.
https://developer.samsung.com/galaxy/professional-audio
Which they are now deprecating as they also contributed to the design of AAudio.
People rightfully pointed out that tablets are plenty powerful to do DSP type applications, but something is consuming all the resources. I'm just saying what that something is.
I lost count the amount of times I have fixed junior code doing what should be background stuff written on the main thread, for loops instead of System.arraycopy, allocating memory in loops and lots of other stuff due to lack of proper teaching.
As for Android, the real time audio stack is fully native and Google had to learn from Samsung how to do it properly.