14 Sep
2005
14 Sep
'05
11:34 a.m.
On Wed, 14 Sep 2005 at 08:49 -0400, Paul Davis wrote:
On Tue, 2005-09-13 at 23:45 -0600, Hans Fugal wrote:
So you're saying jackd should run at priority 1 or higher, and we ought
to check for that? I could probably manage such a patch, but running at
priority 1 is what was causing this error for me with jack apps. Is
there a way to match priority from jack apps automatically?
--
Hans Fugal | If more of us valued food and cheer and
http://hans.fugal.net/ | song above hoarded gold, it would be a
http://gdmxml.fugal.net/ | merrier world.
| -- J.R.R. Tolkien
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
Ah! It came to me just now - I set the priority
field in qjackctl to 0
instead of 1 (where it was) and now jack apps can start. Heads up there.
Maybe applications need a way to recognize what rt_priority level to ask
for based on what jack is running at? On a tangent, how exactly does
that work? Is rt_priority=0 sufficiently prioritized? (because it is the
only thing running realtime)
i think the problem with zero is that with -R, jackd actually needs 2
(or even 3) priorities:
* watchdog thread
* driver thread
* client threads
since it sets the watchdog to run at the stated priority, the others
need to be below it. hence ... the classic UINT_MAX-1 error. we should
probably add a check for the given priority to make sure this can't
happen. care to submit a patch?