| |||||||||||||
RealtimeKit and the audio problemRealtimeKit and the audio problemPosted Jul 1, 2009 21:54 UTC (Wed) by dw (subscriber, #12017)In reply to: RealtimeKit and the audio problem by tetromino Parent article: RealtimeKit and the audio problem
What I mean is, in some cases (such as audio), the driver *knows* that the userspace daemon/process that is trying to access it needs extra scheduler priority. Assuming the process has permissions to open the audio device to begin with, I don't see why it should require extra privs (+ extra interface, + extra bugs, + extra knowledge about kernel internals) to inform the scheduler of something that it could find out completely automatically.
This additionally frees up the kernel folk to replace what could be perceived as a hack, with a better solution later, without braking the user space interface (which simply doesn't exist).
(Log in to post comments)
RealtimeKit and the audio problem Posted Jul 1, 2009 21:56 UTC (Wed) by dw (subscriber, #12017) [Link]
I forgot to mention. It is arguable that the requirement for changing process priority at all just to achieve nominal functionality could be considered exporting a bug fix or implementation detail to user space.
RealtimeKit and the audio problem Posted Jul 1, 2009 22:04 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
this assumes that by accessing that driver you intend for the sound to take priority over anything else running on the system.
that may be true for you, but is it really true that it's _always_ more important to get a system beep than to write to the database file? I don't think so.
to some extent, the fact that you need priority is a system bug (when the system is not overloaded), and that should be fixed. but that won't be enough for people pushing their systems to the limit with audio processing (but I would argue that if you want to make the audio processing the most important thing on the box, you need to tell the kernel your priorities)
many times when you are running an high-end audio app you are also doing a bunch of number crunching (to compress the data, to display graphs of the data, to uncompress the data) how is the system supposed to know what parts of this you are willing to have slow down?
RealtimeKit and the audio problem Posted Jul 1, 2009 22:10 UTC (Wed) by dw (subscriber, #12017) [Link]
I thought perhaps there was a very small class of devices that might intuitively use such a flag - things dealing with UI (keyboard, mouse, audio) and so it might be feasible, but on looking at it I realize that firstly such a flag would be a terribly desktop-ish kind of thing to bake into the kernel, and additionally where do you draw the line? What if audio is streaming in over the network - does the BSD sockets API get the flag? Things start to break down very quickly. :)
RealtimeKit and the audio problem Posted Jul 1, 2009 22:08 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Deciding how many resources to provide to a process is a policy decision, and as such is generally considered to be outside the kernel's scope. The problem with realtime processes is that they can consume as many resources as they want - so simply keying it off the right to open the audio device means that anyone with access to the audio device can block any other process from running. Limiting the resources in some way is also problematic. How should the kernel know what limits to apply? You'd end up needing some kind of userspace policy daemon to arbitrate this anyway, so you might as well use it to grant the permissions in the first place as well.
|
|||||||||||||