10 Feb
2004
10 Feb
'04
8:53 a.m.
On Tuesday 10 February 2004 13.32, Vincent Touquet wrote:
On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis
wrote:
I'm running quite happily with DRI enabled on my ATI card now, the problem was
definitely that it was trying to lock too much memory. Since shrinking the
amount of vidmem that X utilizes I haven't run into this problem again (see
other message for the actual remedy).
/Robert
its a basic problem with real time software, the
POSIX API etc.
JACK tries to lock *all* the process memory.
This is to ensure that nothing gets swapped out, right ?
Else it is very hard to ensure real time performance ?
(sorry for being somewhat ignorant in this matter).
POSIX doesn't offer any
APIs that would allow us to lock only the parts we need locked without
a lot of impossibly ugly, non-portable kludgery.
the part that needs
locking consists of any memory that will be touched by the code run in
the JACK-managed "audio" thread.
the implementation of DRI by certain video interface drivers means
that we end up trying to lock the video memory as well, and this tends
to fail for various reasons.
Is this faillure due to the nature of the memory that we are trying to lock
? Or is the problem that we try to lock the same part of memory multiple
times ? its not what to do about this. the most obvious
answer is "don't try
to run real-time software on systems with these video drivers
installed". i know its not very satisfactory, but its all we have for
now.
Would the less obvious answer consist of one of the following ?:
- change the video drivers (at least the ones that are source based)
- do something at the API level, so we can lock selectively
From what I can gather the optimal solution would be an API that
can give us what we want (only locking the memory that gets touched
by the audio thread and nothing else), but obviously this goes beyond
the scope of jack alone ?
Would you consider implementing a work around (aka non portable kludgery)
a waste of time ?
regards,
v