[linux-audio-dev] NPTL jack+ardour: large memlock required (was: Jack and NPTL (again?))

From: Jonathan Woithe <jwoithe@email-addr-hidden>
Date: Fri Nov 25 2005 - 02:40:05 EET

Hi

On Tues Nov 22 I wrote:
> I've recently moved a system over to Slackware 10.2 which utilises NPTL and
> I'm aware of the issues NPTL has raised in the past. Based on a comment on
> the Jack website though I sort of assumed that things were now in hand and
> that Jack had a workaround in place for the issue.
>
> Despite this I have found that jackd itself (when run using set_rtlimits)
> gives an error (-11, EAGAIN) when "creating realtime thread".

I have since discovered (thanks to strace) that the problem lies in an
mmap2() call which requests a size of around 8MB. It appears to be part of
the NPTL pthread_create() function. The error returned by mmap2() (EAGAIN)
indicates either a locked file or "too much locked memory" (according to the
manpage). Because this is an anonymous map the problem must have been the
latter. Increasing the "locked memory" limit from 20MB to 40MB made jackd
start without having to resort to the LD_ASSUME_KERNEL hack.

Another problem then surfaced: with jackd running under NPTL, jack
applications using NPTL (eg: ardour) suddenly started to require all of
their memory to be lockable. For ardour with a large session this can get
quite large (I saw 130MB at one point last night).

So, with jackd running with LD_ASSUME_KERNEL = 2.4.19 and a memlock limit of
20MB everything worked and ardour (with NPTL - ie: without LD_ASSUME_KERNEL)
was obviously not trying to lock excessive amounts of memory. With jackd
running with NPTL and a large enough memlock limit things work but jack
clients appear to require much more memory be locked.

One thing I will try next is recompiling ardour; perhaps there's something
funny there. In any case though, does any of this ring a bell with anyone?

Regards
  jonathan
Received on Fri Nov 25 04:15:09 2005

This archive was generated by hypermail 2.1.8 : Fri Nov 25 2005 - 04:15:09 EET