Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
From: Jack O'Quin (joq_AT_io.com)
Date: Tue Nov 18 2003 - 03:41:40 EET


Fernando Pablo Lopez-Lezcano <nando_AT_ccrma.stanford.edu> writes:

> > - 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......

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.

> 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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Nov 18 2003 - 03:49:38 EET