>> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
