Just an FYI. I am in the process of adding support for Apple's lossless
Audio Codec (ALAC)  to libsndfile. Should be done my the end of the
Erik de Castro Lopo
On Mon, Sep 26, 2011 at 05:38:24PM +0000, Fons Adriaensen wrote:
> > Those of you who own a Multiface, Digiface or RPM: Could you give
> Does not compile. The installed header doesn't define
> anything RPM, and you don't supply a new one.
Good point. Now? http://adi.loris.tv/hdsp-test-20110927.tgz
The guitarix project could need your help. :-)
After a complete source restructure, to become a real object orientated
source struct, nearly every line have rewritten (by Andreas Degert).
Now, we need to know, if there are any hidden bugs slips in during this
We would push out a new release soon, to cover the new release of
zita-convolver, but we could need some feedback from users of different
arch and distro, to fix possible remaining bug's before.
So, if you like to help us, check out our SVN, let us know if you run
into a problem or if anything works well for you. Let us know your arch
and distro, . .
Help us to bring a usable Guitar Tube Amp emulation to the Free Software
svn co http://guitarix.svn.sourceforge.net/svnroot/guitarix/trunk
your feedback will be welcome here or there or anywhere. :-))
or in our forum:
so please, don't be shy and tell us your test results.
New releases on <http://kokkinizita.linuxaudio.org:/linuxaudio/downloads>:
* General code cleanup, will now allow bugfixes and
minor changes without breaking binary compatibility.
* Will work correctly in Jack's 'freewheeling' mode.
* Optimised partition size sequence in function of number
of inputs and outputs, size and matrix density.
* Should compile and work on OSX. The Makefile is untested.
This release is NOT binary compatible with 2.0.0.
This release is NOT API compatible with 2.0.0. The
required changes are small but essential, and are
documented in the README file. Full API documentation
* Spaces allowed in filenames and jack port names. Use
quotes or escape the spaces.
* Hilbert transform IR built-in, allows creation of
arbitrary complex matrices without requiring any
external audio files. See README_CONFIG.
* Should compile and work on OSX. The Makefile is untested.
This release requires zita-convolver-3.0.x
For an intersting demo of what convolution can do, try
'weird.conf'. Instructions are in the file.
We are seeing unexpected interruptions of SCHED_RR audio processing
threads, and are struggling to understand why they are happening. Does
anyone have any good tips or tools to suggest to help figure out what is
preempting or delaying realtime audio threads?
The issues are coming up with Receptor [see (*) below for an intro]
running its 184.108.40.206 CCRMA based kernel. The bug appears with Receptor
in its "dual core mode", with three instances of Native Instruments'
Kontakt 4 in DFD + multi-core mode. Either lots of held notes, or large
patches are needed to get the spikes.
With these settings there are 5 SCHED_RR threads processing audio (on a
two-core system). 2 are from Receptor, and 1 from each instance of
Kontakt. These Kontakt "helper threads" are released to do work as
possible while the audio thread is processing.
Kontakt/DFD is using mmap to bring its files into memory. This is done
in a lower priority "DFD thread", and the mapped memory is used by the
r/t audio threads.
DFD is important because the problems don't happen without it. And the
high SCHED_RR thread count is important, because the problems also don't
happen if we reduce the count.
When the spike happens there are no:
* wine bottlenecks
* system calls
* threads blocking on each other
* page faults during audio processing
There do appear to be "involuntary context switches" (as reported by
getrusage) when the spikes happen. This makes it seem like the scheduler
is interrupting our threads. But how do you figure out why that is
There aren't many threads in the system with higher priority. All of the
5 processing threads are SCHED_RR/76. The higher priority threads in the
* migration/0 - FIFO/99
* migration/1 - FIFO/99
* watchdog/0 - FIFO/99
* watchdog/1 - FIFO/99
* posix_cpu_timer (x2) - FIFO/99
* IRQ8 (rtc) - FIFO/99
* IRQ20 (our audio card) - FIFO 77
Could other kernel activity interrupt the audio threads? Are there
issues with memory mapping, that can block other unrelated threads? Are
there just too danged many SCHED_RR threads fighting for two cores?
Anyone have any suggestions for how to trace the scheduler, and thread
or process interruptions?
Apologies for the lengthy post, but this is a tricky subject.
Thanks for any tips or insights,
Muse Research & Development
(*) Receptor (http://www.museresearch.com/products/receptor.php) is a
standalone hardware VST plugin player. It runs Windows VSTs using Linux
and Wine in a proprietary host program. We have patched Wine
to make it work better with VSTs in our environment.
LAC 2012: the Linux Audio Conference - Call for Participation
April 12-15, 2012 @ CCRMA, Stanford University
[Apologies for cross-postings] [Please distribute]
Online submission of papers, music, installations and workshops is now
open! On the website you will find up-to-date instructions, as well as
important information about deadlines, travel, lodging, and so on. Read
on for more details!
We invite submissions of papers addressing all areas of audio processing
based on Linux and open source software. Papers can focus on technical,
artistic or scientific issues and can target developers or users. We are
also looking for music that has been produced or composed entirely or
mostly using Linux and other Open Source music software.
The Deadline for all submissions is January 11th, 2012
The Linux Audio Conference (LAC) is an international conference that
brings together musicians, sound artists, software developers and
researchers, working with Linux as an open, stable, professional
platform for audio and media research and music production. LAC includes
paper sessions, workshops, and a diverse program of electronic music.
The upcoming 2012 conference will be hosted at CCRMA, Stanford
University, on April 12-15. The Center for Computer Research in Music
and Acoustics (CCRMA) at Stanford University is a multi-disciplinary
facility where composers and researchers work together using
computer-based technology both as an artistic medium and as a research
tool. CCRMA has been using and developing Linux as an audio platform
Stanford University is located in the heart of Silicon Valley, about one
hour south of San Francisco, California. This is the first time LAC will
take place in the United States.
We look forward to seeing you at Stanford in April!
The LAC 2012 Organizing Team