> "It just takes a SCHED_FIFO task with forced CPU affinity. Android does not make it easy to get one."
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?
Audio is an extraordinarily low demand task, and hardware is not the issue, and hasn't been for a couple of decades (even DSP offloading has virtually disappeared). A smartphone has many, many magnitudes of excess performance to handle extremely low latency audio. The iPhone has had a 7ms latency for many generations, and the 7ms is not some intrinsic limit but is simply a decent balance between low power usage and ensuring no glitches.
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.
Check out the Bela project[1], which has back-ends for a few different audio packages (e.g. PD and SuperCollider) that totally bypass the kernel and handle the audio callback directly (maybe from a bare-metal ISR, not exactly sure). That’s how they get sub-ms round-trip latencies.
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?