>It would still be nice to have a system clock based interval process for
>applications that require activity at specific intervals, but are not to
>do with sound or video.
have any actual use cases?
>An audio hardware interrupt can interrupt any process at any time.
>Is there already a procedu
>It would still be nice to have a system clock based interval process for
>applications that require activity at specific intervals, but are not to
>do with sound or video.
i'd be interested to see a realistic usage case. its mostly related to
RT devices of some kind, most of which provide their
Paul Davis wrote:
The ideal scheduler for realtime apps would be one that has an api that
allows for a call like "schedule me at exactly 10ms intervals+-1ms".
no, thats not true.
the system clock does not run in sync with the sample clock. the drift
in this would become noticeable in a few minu
>The ideal scheduler for realtime apps would be one that has an api that
>allows for a call like "schedule me at exactly 10ms intervals+-1ms".
no, thats not true.
the system clock does not run in sync with the sample clock. the drift
in this would become noticeable in a few minutes.
the only ti
Adam Tla/lka wrote:
sigh. of course! because the kernel has no idea that your audio
application needs to run with real-time priority, and is instead
treating all apps as if they are normal interactive programs. if you
tell the kernel that your app needs to run with RT priority (there are
So why I
>On Wed, Feb 25, 2004 at 09:17:54AM -0500, Paul Davis wrote:
>> There are only 2 differences associated with running the code you are
>> talking about in the kernel:
>>
>> a) it runs deterministically in interrupt context
>> b) it avoids a context switch back into user space
>It could be
At Wed, 25 Feb 2004 15:50:20 +0100,
Adam Tla/lka wrote:
>
> > OSS cannot affect this in any way - its a function of the kernel
> > scheduler and not the audio device API.
> OK but we could have some kernel RT thread which is doing mixing
> or MIDI emulation.
if you start a thread, why it's needed
On Wed, Feb 25, 2004 at 09:17:54AM -0500, Paul Davis wrote:
> There are only 2 differences associated with running the code you are
> talking about in the kernel:
>
> a) it runs deterministically in interrupt context
> b) it avoids a context switch back into user space
It could be more
