Bug#507248: realtime settings

[Adrian Knoth]

On Sat, Mar 07, 2009 at 02:47:28PM -0800, Steve Langasek wrote:

> ardour uses mlock() on its ring buffers to ensure they're available in
> physical memory.  What if in order to meet this requirement, the kernel
> instead swaps out the process stack and has to page that back in?  What if
> it drops the pages for the program itself out of the disk cache, and has to
> read /that/ back from disk?

I won't discuss this. The kernel RT wiki is very clear on that point,
and all the audio developers do it for years.

http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application#Latencies_caused_by_Page-faults


> > Increasming the mlock limit is a must and number one recommendation all
> > over the net for pro-audio. jackd won't even start with realtime
> > priority with the kernel's 32k limit.
> Then that's a bug in the jackd package.

Ok, it starts, but it won't have RT prio. And without RT prio, it's
mostly pointless (especially in case of firewire audio interfaces
handled by FFADO, resulting in many underruns and therefore crackle)


> > We're talking pro-audio here, there are usually no other users.
> Then don't ask me to set a system-level default for all Debian systems
> that's only appropriate for single-user audio systems.

I'm no longer asking. You're right not to enable it as a system-level
default. It's the turn of the pro-audio packages to tune the system to
their special needs.


> > > Removing the memlock limit is still wrong.  That needs to be fixed in
> > > whatever app is abusing locked memory this way.
> > No. 
> Yes, it does, and I will file a critical bug report on jackd if I find it
> removing the memlock limit on my systems.

You're sure you have ever used a pro-audio system? Then you won't call
all the apps broken. Feel free to file the appropriate bugs upstream.


However, even if 99.9% of jackd users would be fine with "it's my
machine, I want it all" (read: optimize the common case), I'd use
debconf and ask whether to touch memlock limits and to which degree.

So it's up to the user when things break, either failing RT performance
or ruined system stability due to too much mlock().


JFTR: ubuntustudio has a settings package for tweaking limits.conf.
Since there are non-jackified RT audio applications, it's probably a
good idea.


Just a last remark to make you help understanding why the pro-audio apps
need so much memlock: I have a virtual piano. It uses a 970MB sample
file. When sending MIDI data to it, it has to output the right sample
within 8-12ms, and there's no time for reading it from disk or swapping
it in. That's why all the data is mlock()ed, all the 970MB, and there
are even bigger samples out there (i.e. Vienna Symphonic Library).

Note that also commercial products on Windows or OSX lock the sample
data in memory. It's the only way to get decent performance, and
crackle is surely the last thing you want to get when being on stage.

Also note that many audio distributions (ubuntustudio, studio64 a.s.o.)
raise memlock limits. Take either as a hint that it's just a must, not a
bug.


Thanks so long.

-- 
mail: adi at thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver