quoted

alsa is basically driven by the hardware, which delivers/requests data
every ~1.3ms.

this is exactly the use-case we considered in that old paper back in LAC
2011, and let me just add that there is more experimentation and details
and results in Giacomo's MSc thesis:

  https://retis.sssup.it/?q=node/77

FYI, we restarted activities on this use-case just recently, considering
a couple of further dimensions:

1) support for heterogeneous platforms with the aim of achieving a sound
support for Arm big.LITTLE on Android, and apply it to the Android video
& audio processing pipelines;

2) proper consideration of power switching capabilities of the platform
(assuming the user would block the CPU frequency to its maximum is not
really multimedia-friendly);

3) support for multi-threaded processing workflows on multi-cores, as
typically needed by (high-performance) audio applications, either with a
single multi-threaded audio processing client, or, e.g., with JACK, with
a DAG of computations that can take advantage of underlying multi-core
processing.

In this context, we've been playing also with the hierarchical extension
to SCHED_DEADLINE we sent last year on LKML

  https://lkml.org/lkml/2017/3/31/658

I hope we can share some good write-up & experimental results pretty
soon about some of the above...

very interesting! thanks for the links ...

I'm not sure I'm getting this: AFAIU, from this viewpoint, what you
could get
with DEADLINE, is very similar to what you can get already with RT
throttling
on RT (RR/FIFO), setting up properly CPU cgroups & limits. Why do you think
DEADLINE would allow you to avoid a watchdog thread, that you need with
RT instead ?

interesting, wasn't aware of rt throttling ... (haven't done much linux
audio developments for almost 10 years). will give it another read ...

cheers,
tim