| |||||||||||||
RealtimeKit and the audio problemRealtimeKit and the audio problemPosted Jul 1, 2009 22:04 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: RealtimeKit and the audio problem by dw Parent article: RealtimeKit and the audio problem
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?
(Log in to post comments)
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. :)
|
|||||||||||||