On 02/23/2011 06:24 PM, Daniel Poelzleithner wrote:
Yes, that's the idea. Maybe limit the number of audio clients to a few ones.
> There is no nice api for detecting the number of processes in a group
In the case of Android, here's what I imagine:
- a client program asks for (realtime) audio access
- the audio server verifies if there aren't too many clients
- from that, the server either allows or denies access
- in case of a denial the client program can display a meaningful error
One thing is that each client runs under a different UID. This is part of app
sandboxing. There isn't any predetermined groups of users who can or can't
access audio (oh well there is a permission system for that, but it's another
Basically, any app could request audio access, and ulatencyd or whatever does
the same job would have to be rather tightly integrated into the sound server,
and move the requesting app to a realtime cgroup if it's possible, or deny
access and return an error.
Well, you could imagine that ulatencyd and the sound server are distinct and
that the client program must connect to both to achieve realtime + audio access.
But let's take JACK for example. It handles setting up realtime scheduling
transparently when one creates a jack client. There isn't any extra step
necessary. As a supposition, could you imagine that ulatencyd integrates tightly
into JACK to provide fine-grained per-client realtime permissions?
This would for example result in a new error reported by jack_client_open() in
case realtime permissions can't be granted because there are too many clients, etc..
Linux-audio-dev mailing list