[LAD] Realtime threads and security

Hi everyone, I am currently spending a lot of time working on Android, and on the andraudio mailing list [1] we are discussing about possible improvements to the internal Android audio system. Currently, latencies are very high, over 100ms, and we're looking for ways to improve the situation. In my opinion this can't be achieved on Linux without realtime scheduling. On Android, there's something called audioflinger which acts as a sound server, and apps act as clients of this server. The server and clients run in distinct processes. What I'm thinking about is having a realtime thread within the server, as well as another realtime thread in the (each) client. The one thing about Android is that it has a strict security model. Every app is considered potentially harmful and is thus "sandboxed". Here, this for example means that apps can lower their threads priority, but not increase it. And of course they can only use non-realtime scheduling. On desktops, for instance using JACK, apart from a few multimedia distributions, realtime permissions are not granted by default to normal users. And when one enables it, security is usually not a primary concern AFAIK. If a piece of software happens to crash the system when running in realtime, the user may just uninstall the buggy software, etc.. But on phones, this is critical, for example if the system crashes while you're waiting for a call. So, on Android, the security policies are strict. But this could certainly be necessary to plenty of other Linux usages. Now my question is: how to allow user-space apps to use realtime scheduling for one of their threads without compromising the overall security? For example, in man sched_setcheduler() I see SCHED_RR, and "Everything described above for SCHED_FIFO also applies to SCHED_RR, except that each process is only allowed to run for a maximum time quantum". Would this help and be sufficient? Would there need to have some kind of watchdog/monitor running with SCHED_FIFO scheduling to prevent realtime client threads from consuming too much resources? Or is there some other ways to achieve this? Some kernel patch maybe? Thanks in advance [1] http://music.columbia.edu/mailman/listinfo/andraudio Olivier