17 Nov
2003
17 Nov
'03
9:42 p.m.
Fernando Pablo Lopez-Lezcano <nando(a)ccrma.stanford.edu> writes:
Agreed. IMHO, mlock() is mandatory, certainly for JACK applications.
The big difference between realtime and most other kinds of
performance work is that it focuses on tuning the "worst case", not
the average. Paging works fine on average, but in the worst case your
recording session gets blown.
Otherwise, a good solution. Perhaps adequate for some applications.
- Can not
provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
unlikely that pages used in a tight audio loop would be thrown out
- big buffers might... Add additional page reads?)
Well, I'd say this is the showstopper. We really need this. "Unlikely"
is not enough. Eventually memory will run out and the wrong page will
fault and we get a click. We have to be able to lock memory...... BUT, I think a userspace daemon that starts at boot
time and protects
against lockups (rt_monitor) would be a very good thing to have.
Yes it would. I've been using an earlier version of Roger's
rt_monitor quite a lot lately while chasing JACK bugs. It works very
well and has never caused any noticeable trouble on my system.
--
joq