Hello all,
The first release of jkmeter is now available in the
usual place:
<www.kokkizinita.net/linuxaudio/downloads>
Also updates of japa and jnoise (mostly maintenance,
but see also below).
>From the README:
jkmeter-0.1.0 (03/08/2008)
--------------------------
Jkmeter is a horizontal or vertical bargraph level
meter based on the ideas of mastering guru Bob Katz.
See <http://www.digido.com/bob-katz/index.php> and
follow the links on 'level practices'.
This is the type of meter you want for live recording,
mixing and mastering. It probably makes no sense to
use it on all tracks of a DAW, where keeping digital
level within limits is the main purpose of metering.
This release implements the K-20 meter. Future
releases will include the K-14 meter as well.
A K-meter displays both the true RMS level and the
digital peak level. The ballistics as defined by Bob
Katz are somewhat ambiguous. In this implementation
the RMS meter is about 15% faster than an VU, but
without the overshoot. This provides a good indication
of subjective loudness.
Instead of providing extra gain for the RMS level,
the K-meter displays it on the same scale as the
digital peak level, but puts the '0dB' mark and the
color change well below the OdB full scale level.
For the K-20 meter it is 20dB down, for the K-14
this is (surprise !) 14 dB.
To use the meter as envisaged by Bob Katz, you
should have a fixed monitoring level, adjusted
so that pink noise indicating 0dB on the meter
corresponds to 83 dB(C) (from each speaker) as
indicated by an sound level meter. Note the (C)
- not (A) - weighting.
As of release 0.4.0, both japa and jnoise provide
a pink noise source at exactly this level.
The current release does not include the 22kHz
lowpass filter required for frequencies such as
96kHz and higher.
Enjoy !
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
a2jmidid is a project that aims to ease usage of legacy ALSA sequencer
applications, in a JACK MIDI enabled system.
a2jmidid implementation is based on jack-alsamidi-0.5 that is [almost]
same as jackd ALSA "seq" MIDI backend, both created by Dmitry Baikov.
Static bridges are based on code by Sean Bolton and Lars Luthman.
Homepage with screenshots: http://home.gna.org/a2jmidid/
Tarball download: http://download.gna.org/a2jmidid/
Changes since version 2:
* Improved port naming, support for bidirectional ports
* Allow exporting of hardware ports (disabled by default)
* Switch from autotools to waf
* Remove support for old JACK MIDI API variants
* Remove usage of posix semaphores that could cause sleep in realtime context, in rare circumstances
* D-Bus background service mode. The old manual mode is still working.
* Log file when running in background service mode.
* Improved documentation
* Import, with slight modifications, static bridges created by Sean Bolton and Lars Luthman.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Fons Adriaensen:
>
> The data used by car manufacturers to describe engine noise
> is a spectral description, where some small divider of the
> RPM (depending on engine configuration) is regarded as the
> funcdamental frequency. For each harmonic you have a smooth
> amplitude map in function of RPM and throttle position.
>
> Staring from these it's not so difficult to synthesise
> something quite realistic.
>
The company "Staccato" tried to provide synthesized car sounds
for race car games in 1999, according to this page:
http://www.scandalis.com/Jarrah/PhysicalModels/index.html
Florian Faber wrote:
> Peter,
>
>> I doubt that it is easy over a transport protocol that doesn't have a
>> global absolute time reference (like ethernet).
>
> What time reference do you have in mind on ethernet that can be used as
> word clock source?
My formulation is a bit unfortunate. I mean that ethernet does NOT have
a global absolute time reference. And word clock is not a time
reference. It's a 'rate' reference, which does not contain absolute time
information. What you need to output signals on different devices with
sample accurate phase is an absolute time reference. Which ethernet does
not have.
Greets,
Pieter
I have some doubts, as both host and plugin programmer, regarding the text
encoding that should be used for Ladspa v1 metadata fields. Is there any
convention? Utf8? Is it limited to plain ASCII? Which fields are restricted
and which are not?
I supose that unicode is supported in some way as many 'makers' have weird
signs on their name but the header-documentation does not provide any answer
to that.
David GarcÃa Garzón.
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.
Fons Adriaensen:
>
> Inkscape lookd more and more as some GUI interface
> to Cairo. ATM I can write the Cairo code a lot
> faster than using the GUI...
>
I was just about to suggest writing Cairo code. :-)
pgf/tikz is probably faster than programming cairo
though. But what would be really nice would
be a programming interface for pgf/tikz.
Fons Adriaensen:
>
> Anyone knows a good vector drawing program for Linux ?
>
> Absolute requirements are:
>
> - Lines, arrows, boxes, circles, etc.
> - Linewidths and styles, colors, filling.
> - Text
> - PDF or PS export.
> - PNG and JPEG import (no bitmap editing required).
> - Accuracy.
>
> I've been using TGIF for years, but I'm more and
> more being blocked by its main flaw which is that
> it seems to use a unit of 0.2mm internally (in
> metric mode) which is orders of magnitude too big.
>
> Tried QCAD and INKSCAPE, both fail basic
> requirements (and have other problems).
>
>
Maybe pgf / tikz would be useful?
http://www.ctan.org/tex-archive/help/Catalogue/entries/pgf.html
Hello, I had a great performing linux audio setup until I had to move to
a newer kernel to get some hardware on a new motherboard to work. Now I
can't seem to get decent performance and thought it might be helpful if
folks could chime in with what versions, etc. they are using with decent
success. In particular I'm having a very challenging time with Linux
Sampler, which I had previously working very solidly but now regardless
of numerous jack/ls version permutations segfaults when I create a jack
driver in ls. Thanks! -Garett
Kernel version? RT patch? Preemption mode? Audio hardware IRQ scheduling
policy and priority?
Alsa version if different from kernel?
Jack version, scheduling policy and priority?
Linux Sampler version (or cvs date), scheduling policy and priority?