[LAA] [ANN] Realtime priority patch for the linux kernel, jack_capture V0.9.23 and Rollendurcmesserzeitsammler V0.0.4

From: Kjetil S. Matheussen <k.s.matheussen@email-addr-hidden>
Date: Fri Aug 01 2008 - 19:44:24 EEST

Download from:

http://old.notam02.no/arkiv/src/?M=D

Realtime priority patch for the linux kernel
============================================

To make sure the Linux kernel is able to grant realtime
priority, and full nice and mlock capabailites can still
be a little bit inconvenient and/or frustrating.

However, this super-tiny patch:

   http://old.notam02.no/arkiv/src/realtime.diff

against the linux source shortcuts all other
methods. No more pam, realtime-lsm, rtlimits etc.

jack_capture
============
jack_capture is a program for recording soundfiles with jack. Its default
operation is to capture whatever sound is going out to your speakers into
a file. (But it can do a number of other operations as well...)

Changes 0.9.19 -> 0.9.23:
  *Minor spellings
  *Check for out of memory
  *Clean up source a bit
  *Stop connection thread before closing jack client.
  *Made --help a tiny bit cleaner
  *Removed shut down code from the SIGINT signal handler.
  *Fixed segfault in case jack shuts down. Thanks to Julien Claassen
   for reporting the bug.

(Note that there is also a 0.9.24 release. 0.9.24 has
changed internal data representation from lockless ringbuffer to
lockless lifo and fifo stacks. (Unmodified lifo/fifo code taken
from midishare. (Copyright Grame 1999-2005)) 0.9.24 probably works
fine, but it shouldn't be used for important recordings since
it hasn't been much tested yet.)

Rollendurchmesserzeitsammler v0.0.5
------------------------------------
The Audio Rollendurchmesserzeitsammler is a conservative garbage
collector especially made for running inside an audio DSP thread.

New about this release is that I have finally replaced TLSF
(http://rtportal.upv.es/rtmalloc/) with a pool-based dynamic
memory allocator, which makes allocation using the
rollendurchmesserzeitsammler approximately as fast as
using custom memory pools.

Using the rollendurchmesserzeitsammler
should be a lot more convenient than memory pools though, and
since memory is not freed manually, but instead
is automatically freed in a separate thread, there is a
slight chance that using rollendurchmesserzeitsammler
instead of custom memory pools could make some DSP code run
faster.

In non-synthetic benchmarks, I have not been able to see any
significant improvement in CPU use because of this compared to
using the TLSF allocator. But for programs doing
millions of allocations per second, the new memory allocator
will probably perform significantly better than TLSF, if it
would ever make sense doing so many and frequent allocations
of course...

Changes 0.0.4 -> 0.0.5
* Implemented a custom pool-based dynamic memory allocater. This new
    memory allocator is now set as default. To use TLSF instead, set
    "USE_TLSF=-DUSE_TLSF" in the Makefile before compiling. The following
    changes are caused by this switch:
* Allocating memory is now approx 10 times faster (13 vs. 168
    instructions for the allocation itself, but there are some GC
    overhead too)
* The allocator copies used memory only (not just the whole heap).
    But not always! This was a lot more complicated to to with TLSF
    so I didn't do that. Note that for the garbage collector to still
    be hard realtime safe, the programs must ensure that full copies
    are taken now and then. (There's a change in the API for doing that)
* Doing a garbage collection is much faster since the heaps are usually
    much smaller (because only used memory is copied) and that freeing
    is 10-20 times faster.
* Further improvements for reducing memory overhead and make
    searching for used mem to be O(log n) instead of O(n) is
    much simpler now. (this is TODO though)
* However 1: In case the code using the garbage collector will
    continue forever to allocate memory of different sizes, the
    new dynamic memory allocator could eventually run out of memory
    even if the program itself doesn't use very much memory.
    I don't think this is very likely to happen for DSP routines though,
    and there might even be solutions to fix this problem if it should
    ever come up. For now, just switching to TLSF fixes the problem.
* However 2: in non-synthetic benchmarks, I have not been able to see any
    practical improvement in CPU use, apart from the slight improvement
    in CPU available for use in non-realtime threads because taking
    snapshots usually takes a lot less time now. But for programs doing
    millions of allocations per second, the new memory allocator will
    probably perform significantly better than TLSF, if it would ever
    make sense doing so many allocations of course.
_______________________________________________
Linux-audio-announce mailing list
Linux-audio-announce@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-announce
Received on Sun Aug 3 20:15:02 2008

This archive was generated by hypermail 2.1.8 : Sun Aug 03 2008 - 20:15:02 EEST