From k.s.matheussen at notam02.no  Mon Oct  2 19:17:14 2006
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Mon Oct  2 19:17:34 2006
Subject: [linux-audio-dev] [ANN] San Dysth V0.1.0, Snd-ls V0.9.7.1,
	E-Radium V0.61f
Message-ID: <Pine.LNX.4.64.0610030052560.6429@ttleush>



1.
===
San Dysth is a standalone realtime soft-synth written in SND.
It was first developed as final project for the 220c course at CCRMA.
For information about the used synthesizing routine and sound examples,
check out San Dysths homepage at:

http://www.notam02.no/~kjetism/sandysth/


Requirements
------------
Snd-ls >=0.9.7.1
G2Reverb ladspa plugin.



2.
===
Snd-ls is a distribution of Bill Schottstaedt's sound editor SND.
Its target is people that don't know scheme very well, and don't want
to spend too much time configuring Snd. It can also serve
as a quick introduction to Snd and how it can be set up.

Download from http://www.notam02.no/arkiv/src/snd/

Changes 0.9.7.0 -> 0.9.7.1
---------------------------
-Updated Snd from 8.4/13.9 to 8.4/26.9. Many important fixes.
-Added workaround for menu problem. Bug found by Dragan Noveski.
-Added check that initialization is complete.
-Some realtime fixes.



3.
===

E-radium is Radium and a special version of E-UAE (with support for
realtime scheduling and alsa midi). Radium is a unique type of music
event editor made to be efficient and provide many possibilities.
The user interface is inspired by trackers, but Radium is
more versatile and can be used for all kinds of genres.

http://www.notam02.no/radium/

Changes 0.61e -> 0.61f
----------------------
-Fixed all build errors in 0.61e (0.61e should never have been released.)
-Made sure everyone can run e-radium after installation, not only root and
  the user doing the compilation.


From a at gaydenko.com  Tue Oct  3 09:58:11 2006
From: a at gaydenko.com (Andrew Gaydenko)
Date: Tue Oct  3 09:58:54 2006
Subject: [linux-audio-dev] avoiding signal invertion
Message-ID: <200610031758.11337@goldspace.net>

(Sorry for crossposting, it seems like Alsa-user list hasn't an answer)

I use ICE1724 ALSA driver for Terratec Aureon 7.1 Space card. I have noticed
both default (line out) and plug:spdif devices'es outputs are inverted. Is there
a way to add additional inversion and, as a result, to get "normal" output signal?


Andrew

From ico at vt.edu  Tue Oct  3 12:10:29 2006
From: ico at vt.edu (Ivica Ico Bukvic)
Date: Tue Oct  3 12:10:46 2006
Subject: [linux-audio-dev] VST API license
Message-ID: <003a01c6e706$72a12020$0502a8c0@64BitBadass>

Hi all,

I am in the process of considering to, on behalf of Linuxaudio.org,
negotiate with Steinberg possible change of VST API license in order to
allow its easier adoption within Linux LGPL/GPL environment. As Daniel has
already pointed out, with Yamaha now owning Steinberg, we ought to have a
better chance at making this a reality.

For this reason, I was wondering if anyone else is currently working on this
and if so what is its status. I also recall quite a few years ago Paul
trying to compile a letter to Steinberg. Whatever happened to that?

Ivica Ico Bukvic, D.M.A.
Linuxaudio.org Director
Virginia Tech
Department of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
ico@linuxaudio.org
http://www.music.vt.edu/people/faculty/bukvic


From tszilagyi at users.sourceforge.net  Tue Oct  3 15:17:46 2006
From: tszilagyi at users.sourceforge.net (Tom Szilagyi)
Date: Tue Oct  3 15:16:45 2006
Subject: [linux-audio-dev] [ANN] Aqualung 0.9beta6 released
Message-ID: <20061003191746.GD4677@r51>

The developers are pleased to announce the latest release of
Aqualung, a music player for GNU/Linux.

Website: http://aqualung.sf.net

Without further ado, the ChangeLog is attached below.

Enjoy,
Tom


2006-10-03      Tom Szilagyi <tszilagyi at users dot sourceforge dot net>

Aqualung 0.9beta6
http://aqualung.sf.net

This release introduces a fair number of substantial improvements:

* Music Store builder: automatically build a Music Store by scanning the
  files on disk. Perform CDDB lookups & extract metadata on the fly.

* MPEG decoder enhancements: robust file recognition, VBR and UBR file
  support, frame-accurate seeking, true gapless playback via eliminating
  encoder padding+delay read from LAME headers.

* Fully revamped metadata support using TagLib. The result is a more
  complete implementation also supporting APE tags in Musepack files.

* Automatic output driver detection: ability to startup without command
  line arguments (using default driver parameters).
        
* Systray (a.k.a. Notification Area) support.

* Handling of compressed MOD files (.gz and .bz2).

* Resolved issue with JACK memory locking (which previously resulted in
  runaway memory consumption when running with realtime JACK output).

* Aqualung compiles & runs under FreeBSD and Cygwin.


NEW LIBRARY DEPENDENCIES:
        
* TagLib >= 1.4 is now required for metadata support.
  http://developer.kde.org/~wheeler/taglib.html

* GTK+ >= 2.10 is needed for the (optional) Systray support.


DROPPED DEPENDENCIES:
        
* libid3tag library is not required anymore (succeeded by TagLib).
From yosvanyllr at gmail.com  Wed Oct  4 03:19:43 2006
From: yosvanyllr at gmail.com (=?UTF-8?Q?Yosvany_Llerena_Rodr=C3=ADguez?=)
Date: Wed Oct  4 03:19:55 2006
Subject: [linux-audio-dev] Gaussian Mixture Models
Message-ID: <dfdb6df00610040019x15869087k755f5e48880d4800@mail.gmail.com>

Hi all.

I'm student of Telecommunication Systems and my ending homework  is
related about GMM's - EM algorith for classification. My searchs in
IEEE I found a few papers but this paper are just a resume of the
technique and I need a Detailed information to develop the full
algorithm in C/C++...

All your help about any document, or sourceode will be grateful...

Thank's in advanced.
Yosvany
From nico at tekNico.net  Wed Oct  4 05:37:18 2006
From: nico at tekNico.net (Nicola Larosa)
Date: Wed Oct  4 05:37:41 2006
Subject: [linux-audio-dev] Re: avoiding signal invertion
In-Reply-To: <200610031758.11337@goldspace.net>
References: <200610031758.11337@goldspace.net>
Message-ID: <efvvcb$c9j$1@sea.gmane.org>

Andrew Gaydenko wrote:
> (Sorry for crossposting, it seems like Alsa-user list hasn't an answer)
> 
> I use ICE1724 ALSA driver for Terratec Aureon 7.1 Space card. I have noticed
> both default (line out) and plug:spdif devices'es outputs are inverted. Is there
> a way to add additional inversion and, as a result, to get "normal" output signal?

I have a Terratec Aureon USB 5.1 MKII, and have channel inversions too.
Here's the relevant snippet of my asound.conf:


# Terratec Aureon USB 5.1 MKII
# software mixed, multiple access in output only
pcm.dmix51 {
  type dmix
  ipc_key 12347
  slave {
    pcm "hw:2,0"
    channels 6
  }
}

pcm.aureon {
  type route
  slave.pcm "dmix51"
  slave.channels 6
  # Front Left
  ttable.0.0 0.7
  # Front Right
  ttable.1.1 0.7
  # Rear Left
  ttable.2.4 1.0
  # Rear Right
  ttable.3.5 1.0
  # Center
  ttable.4.2 1.0
  # LFE
  ttable.5.3 1.0
}

ctl.aureon {
  type hw
  card 2
}

The (Rear Left, Center) and the (Rear Right, LFE) pairs had to be swapped.
Also, I attenuated the Front Left and Front Right channels somewhat.

Hoe this helps.


-- 
Nicola Larosa - http://www.tekNico.net/

The answer isn't to make the command-and-control system harder to get
around, but to throw the system away. People do their best work not
because they have to, but because they want to, and it's a rare IT
professional who wants to do their best work under the iron fist of
someone who looks to Dilbert's Pointy-Haired Boss for inspiration.
 -- Andy Lester, May 2006

From cournape at gmail.com  Wed Oct  4 09:30:20 2006
From: cournape at gmail.com (David Cournapeau)
Date: Wed Oct  4 09:30:31 2006
Subject: [linux-audio-dev] Gaussian Mixture Models
In-Reply-To: <dfdb6df00610040019x15869087k755f5e48880d4800@mail.gmail.com>
References: <dfdb6df00610040019x15869087k755f5e48880d4800@mail.gmail.com>
Message-ID: <5b8d13220610040630u733c7b13q8bf2a3f37d89b454@mail.gmail.com>

On 10/4/06, Yosvany Llerena Rodr?guez <yosvanyllr@gmail.com> wrote:
> Hi all.
>
> I'm student of Telecommunication Systems and my ending homework  is
> related about GMM's - EM algorith for classification. My searchs in
> IEEE I found a few papers but this paper are just a resume of the
> technique and I need a Detailed information to develop the full
> algorithm in C/C++...
>
This has nothing to do with linux or even audio development... I
shouldn't answer, but anyway:

 Implementing EM for GMM is not really difficult by reading some good
paper on EM (the master thesis here is quite well done, actually, with
extension using variationel Bayes methods for reinforcement
learning:http://www.cs.ubc.ca/grads/resources/thesis/Nov03/Kejie_Bao.pdf#search=%22kejie%20bao%22
). There is an implementation of EM for finite GMM in python available
here:

http://www.ar.media.kyoto-u.ac.jp/members/david/pyem.tar.gz

which handles both diagonal and full covariance matrices.

David
From yosvanyllr at gmail.com  Wed Oct  4 09:38:53 2006
From: yosvanyllr at gmail.com (=?UTF-8?Q?Yosvany_Llerena_Rodr=C3=ADguez?=)
Date: Wed Oct  4 09:39:00 2006
Subject: [linux-audio-dev] Gaussian Mixture Models
In-Reply-To: <5b8d13220610040630u733c7b13q8bf2a3f37d89b454@mail.gmail.com>
References: <dfdb6df00610040019x15869087k755f5e48880d4800@mail.gmail.com>
	<5b8d13220610040630u733c7b13q8bf2a3f37d89b454@mail.gmail.com>
Message-ID: <dfdb6df00610040638n467420e3tdb8cb9889eff8aab@mail.gmail.com>

Thank's David.
From andres at geminiflux.com  Wed Oct  4 23:51:08 2006
From: andres at geminiflux.com (Andres Cabrera)
Date: Wed Oct  4 23:50:58 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
Message-ID: <4524812C.6070402@geminiflux.com>

Hi all,
I've written a paper analyzing the characteristics of some software 
dynamic range compressors. The interesting part concerning linux, is 
that all my results show jaggedness on the gain reduction curves. I did 
the tests using Ardour, Audacity and Rezound with the same results, 
which points to something strange in some part of the process.
If you're interested, have a look a the paper, and let me know what you 
think.

http://www.geminiflux.com/Stuff/Cabrera-Compression.pdf

Cheers,
Andr?s

From fons.adriaensen at alcatelaleniaspace.com  Thu Oct  5 04:45:54 2006
From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen)
Date: Thu Oct  5 04:46:10 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <4524812C.6070402@geminiflux.com>
References: <4524812C.6070402@geminiflux.com>
Message-ID: <20061005084554.GA595@bth05w.ABSp.alcatel.be>

On Wed, Oct 04, 2006 at 10:51:08PM -0500, Andres Cabrera wrote:

> I've written a paper analyzing the characteristics of some software 
> dynamic range compressors. The interesting part concerning linux, is 
> that all my results show jaggedness on the gain reduction curves. I did 
> the tests using Ardour, Audacity and Rezound with the same results, 
> which points to something strange in some part of the process.

Or in your measurement methods which are ill-defined, making it all but
impossible to correctly interpret some of the results.

- How do you measure gain ? By comparing single input/output samples ?
  It seems so, otherwise how do you obtain a gain vs. time curve at
  50 Hz with sub-millisecond resolution (Fig. 3) ?
  This will be invalid in many cases, for example if the plugin includes
  audio delay to achieve 'zero latency', as you suggest some of them do.

- This delay is the first thing that should be measured. Without
  this information it is impossible to evaluate the results.

- How on earth do can you define the level of a white noise signal 
  by a peak value ?

- What is a square wave at 0dB FS ? Positive and negative samples 
  at the maximum amplitude ? That does no correspond to a analog
  square wave signal.

- How do you expect to measure distortion using square waves ?

-- 
FA

Lascia la spina, cogli la rosa.
From ladev at sound-man.co.uk  Thu Oct  5 07:10:16 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Thu Oct  5 06:48:22 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005084554.GA595@bth05w.ABSp.alcatel.be>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
Message-ID: <20061005111016.GA3136@localhost.localdomain>

Some additional nit-picks:

"these models are as closed and unknown as their analog originals"

Analog equipment is very rarely closed and unknown, as anyone who
understands electronics can usually look at the circuitry and work out what
it does. Sometimes a manufacturer will encapsulate circuits in resin
or use custom ICs to prevent copying, but that was pretty rare when most
of the `classic' analog compressors were designed.

"If a compressor had a knee setting, relevant settings were chosen"

What is a relevant setting?

"lower frequencies tended to be less attenuated, while DC offsets tended
to be the most attenuated. This seems to point that all plug-ins tested
use some form of RMS or integration method."

This doesn't follow. Most compressors do indeed use some form
of integration, but that's not the reason for these effects. 
The lesser attenuation of lower frequencies points to high pass
filtering in the signal used for envelope tracking, and the greater
attenuation of DC offset is likely due to high pass filtering in the
audio path (analogous to DC blocking capacitors in a hardware compressor).

John
From andres at geminiflux.com  Thu Oct  5 09:44:43 2006
From: andres at geminiflux.com (Andres Cabrera)
Date: Thu Oct  5 09:44:44 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005084554.GA595@bth05w.ABSp.alcatel.be>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
Message-ID: <45250C4B.7000002@geminiflux.com>

Hi,

First, let me clarify that my main intent with this paper is not to bash 
linux plugins or demerit people's work, but to see how other commercial 
plugins compare to the linux ones, to be able to make the best possible 
compressors as open source. I'm just presenting my results, it's a 
learning experience for me, so I appreciate all comments.


 Alfons Adriaensen wrote:
> On Wed, Oct 04, 2006 at 10:51:08PM -0500, Andres Cabrera wrote:
>
>   
>> I've written a paper analyzing the characteristics of some software 
>> dynamic range compressors. The interesting part concerning linux, is 
>> that all my results show jaggedness on the gain reduction curves. I did 
>> the tests using Ardour, Audacity and Rezound with the same results, 
>> which points to something strange in some part of the process.
>>     
>
> Or in your measurement methods which are ill-defined, making it all but
> impossible to correctly interpret some of the results.
>
> - How do you measure gain ? By comparing single input/output samples ?
>   It seems so, otherwise how do you obtain a gain vs. time curve at
>   50 Hz with sub-millisecond resolution (Fig. 3) ?
>   This will be invalid in many cases, for example if the plugin includes
>   audio delay to achieve 'zero latency', as you suggest some of them do.
>   
Yes, gain change was measured comparing individual samples, this 
measures the exact effect of the plugin on a known signal. The csound 
program compensates for any delay introduced by the plugin by not 
comparing exact times, but rather by looking for the start sample for 
each section. When I talk about latency in the paper, I'm not referring 
to audio latency or latency introduced by the plugin from a look-ahead 
method, but rather about a latency (or delay) in the start of gain 
reduction by the plugin, which is probably dictated by the 'windowed' or 
integration mechanism used by the plugin to calculate the envelope.
It's worth noting that the Renaissance Compressor does not introduce 
this type of latency (i.e. gain reduction is applied to a signal from 
the start of the first sample), but still it does not introduce any 
delay in the audio signal. The first sample of the waves is exactly in 
the same position for both the source signal and the processed signal. 
This seems to point to a compression algorithm that relies on additional 
mechanisms to follow an envelope, which can track gain from a few 
samples (probably within the process buffer size, to keep the signal in 
time). I'm thinking that maybe Sonar (which I used to process audio with 
the RCompressor plugin) has applied some sort of delay compensation 
mechanism, and maybe there is after all a delay in the plugin that is 
later compensated...

> - This delay is the first thing that should be measured. Without
>   this information it is impossible to evaluate the results.
>   
True, but since either the plugin produces no delay, or Sonar has 
compensated the delay, this is not evident. I'll see if I can find a 
simple host that can load Rcompressor and can process the file without 
delay compensation, to check for plugin delay (or see if there's a way 
in Sonar to turn delay compensation off).

> - How on earth do can you define the level of a white noise signal 
>   by a peak value ?
>   
Since the source white noise is known, it was possible to compare the 
effect sample by sample. As said in the paper, there was no effect on 
the phases of the sound (so each sample was still in the same place, but 
its gain had changed)

> - What is a square wave at 0dB FS ? Positive and negative samples 
>   at the maximum amplitude ? That does no correspond to a analog
>   square wave signal.
>   
True, but I'm measuring the audio processed in the digital domain. I 
included square waves and saw waves (saw waves used are also not 
band-limited) in the test sample for completeness and to see whether 
they yield significant results, but most of the conclusions are drawn 
from the pure sine waves.
> - How do you expect to measure distortion using square waves ?
>
>   
I don't.... Sine waves would show this better.


What I think is most significant in the paper is not the fact that the 
linux plugins tested introduced 'compression latency', but that they 
produced jagged gain reduction curves. This jaggedness is periodic and 
independent of the processed signal. This either points to a user error 
that is hard to avoid (I tried to be as thorough and careful as I 
could), that might (or might not) be affecting audio quality, or to some 
problem somewhere in the audio chain (maybe it's not the plugin). I'm 
very interested in finding out the reason for this if only to learn I'm 
doing something wrong.

Cheers,
Andr?s


From andres at geminiflux.com  Thu Oct  5 10:01:19 2006
From: andres at geminiflux.com (Andres Cabrera)
Date: Thu Oct  5 10:01:13 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005111016.GA3136@localhost.localdomain>
References: <4524812C.6070402@geminiflux.com>	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
Message-ID: <4525102F.9030901@geminiflux.com>

Hi,

John Rigg wrote:
> Some additional nit-picks:
>
> "these models are as closed and unknown as their analog originals"
>
> Analog equipment is very rarely closed and unknown, as anyone who
> understands electronics can usually look at the circuitry and work out what
> it does. Sometimes a manufacturer will encapsulate circuits in resin
> or use custom ICs to prevent copying, but that was pretty rare when most
> of the `classic' analog compressors were designed.
>   
True, I'm a digital age guy, so I hadn't thought of that...
> "If a compressor had a knee setting, relevant settings were chosen"
>
> What is a relevant setting?
>   
By relevant settings I mean evaluting several settings across the 
available ones to later determine the behavior of the knee. If the knee 
was a toggle switch, the different knee settings were evaluated.
> "lower frequencies tended to be less attenuated, while DC offsets tended
> to be the most attenuated. This seems to point that all plug-ins tested
> use some form of RMS or integration method."
>
> This doesn't follow. Most compressors do indeed use some form
> of integration, but that's not the reason for these effects. 
> The lesser attenuation of lower frequencies points to high pass
> filtering in the signal used for envelope tracking, and the greater
> attenuation of DC offset is likely due to high pass filtering in the
> audio path (analogous to DC blocking capacitors in a hardware compressor).
>
>   
I was assuming that RMS measruments and windowed integration act as a 
high pass filter, is this not true?
> John
>
>   
Thanks for your comments,
Andr?s

From andres at geminiflux.com  Thu Oct  5 10:14:26 2006
From: andres at geminiflux.com (Andres Cabrera)
Date: Thu Oct  5 10:14:13 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <4525102F.9030901@geminiflux.com>
References: <4524812C.6070402@geminiflux.com>	<20061005084554.GA595@bth05w.ABSp.alcatel.be>	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com>
Message-ID: <45251342.7050609@geminiflux.com>

Hi,

Just to clarify the problem I'm encountering, here's a zoom in on the 
processed wave, exactly at the point where gain reduction starts 
occuring. This screenshot doesn't apply any of the methods proposed in 
the paper, it shows the output of the plugin. This behavior occurs for 
the Tap, SC1 and SC4 plugins in Ardour, Audacity and Rezound. All 
processed files were saved at 32-bit floating point.

www.geminiflux.com/Tap-processed.jpg

Cheers,
Andr?s

From fons.adriaensen at alcatelaleniaspace.com  Thu Oct  5 10:22:32 2006
From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen)
Date: Thu Oct  5 10:22:49 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <45251342.7050609@geminiflux.com>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com> <45251342.7050609@geminiflux.com>
Message-ID: <20061005142232.GE595@bth05w.ABSp.alcatel.be>

On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote:

> Just to clarify the problem I'm encountering, here's a zoom in on the 
> processed wave, exactly at the point where gain reduction starts 
> occuring. This screenshot doesn't apply any of the methods proposed in 
> the paper, it shows the output of the plugin. This behavior occurs for 
> the Tap, SC1 and SC4 plugins in Ardour, Audacity and Rezound. All 
> processed files were saved at 32-bit floating point.
> 
> www.geminiflux.com/Tap-processed.jpg

Interesting. Could you post the pictures for the two others as well ?


-- 
FA

Lascia la spina, cogli la rosa.
From ben at glw.com  Thu Oct  5 10:50:44 2006
From: ben at glw.com (Ben Loftis)
Date: Thu Oct  5 10:55:33 2006
Subject: [linux-audio-dev] Re: Paper on dynamic range compression
In-Reply-To: <20061005134450.7D1F73482672@music.columbia.edu>
References: <20061005134450.7D1F73482672@music.columbia.edu>
Message-ID: <45251BC4.4040808@glw.com>

Andreas, I want to thank you for bringing this up.  This is very 
important work.  Interest in open-source audio is going to grow 
DRAMATICALLY within the pro audio industry in the next year or so, and 
it will be quickly squelched if basic principles ( like smooth gain 
adjustments given a wide range of inputs ) are ignored.

Personally I find many of the plugins, particularly the filters and 
compressor/gates, to be nearly unusable and certainly not in the same 
class as commercial offerings.  Why should this be true?

Commercial developers have the advantages of full-time development, 
years of focused experience, and expensive test equipment.  Open-source 
developers have the advantage of peer review.  I hope that your study is 
just the first in a series of highly critical looks at the open-source 
offerings, and that it results in a definition and refinement of the 
"best practices" that are already known by professional developers.

For our part, Harrison has taken an interest in Ardour and has actively 
guided development towards professional needs for the last 6 months or 
so.  You can expect to see more industry involvement as the benefits of 
"Free sofware" become obvious to the pro audio world.  10 years of 
proprietary development has resulted in the stagnation of our industry.  
For example, there are certain limitations: bit depth, file 
compatibility, and inter-app communication, that cannot be lifted given 
the current audio software business environment.  These limitations are 
NOT imposed by Free software like Ardour.  Open Source and/or Free 
software is the only avenue open for true innovation and improvement in 
sound quality.

Please continue to look critically at the available plugins, and 
continue to raise these issues before there is an influx of professional 
interest.  Open-source plugins may never sound as good as the best 
commercial offerings ( *cough* Harrison *cough* ), but they shouldn't be 
allowed to sound BAD, given the wealth of knowledge available in the LAD 
group.

-Ben Loftis
www.harrisonconsoles.com

From fons.adriaensen at alcatelaleniaspace.com  Thu Oct  5 11:29:20 2006
From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen)
Date: Thu Oct  5 11:29:30 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <45251342.7050609@geminiflux.com>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com> <45251342.7050609@geminiflux.com>
Message-ID: <20061005152920.GF595@bth05w.ABSp.alcatel.be>

On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote:

> Just to clarify the problem I'm encountering, here's a zoom in on the 
> processed wave, exactly at the point where gain reduction starts 
> occuring. This screenshot doesn't apply any of the methods proposed in 
> the paper, it shows the output of the plugin. This behavior occurs for 
> the Tap, SC1 and SC4 plugins in Ardour, Audacity and Rezound. All 
> processed files were saved at 32-bit floating point.
> 
> www.geminiflux.com/Tap-processed.jpg

I just had a look at the TAP sources. The gain is only updated every
fourth sample, probably because the calculations to compute it involve
some functions that are not so cheap in CPU terms. This explains the
ripples.

The least that should be done is to interpolate the gain between these
points (introducing some latency). A better idea would be to simplify
the calculations - I haven't looked at them in detail but they seem
much too heavy for what's needed.


-- 
FA

Lascia la spina, cogli la rosa.
From S.W.Harris at ecs.soton.ac.uk  Thu Oct  5 12:04:07 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Thu Oct  5 12:04:55 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005152920.GF595@bth05w.ABSp.alcatel.be>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com> <45251342.7050609@geminiflux.com>
	<20061005152920.GF595@bth05w.ABSp.alcatel.be>
Message-ID: <20061005160407.GE31106@login.ecs.soton.ac.uk>

On Thu, Oct 05, 2006 at 05:29:20 +0200, Alfons Adriaensen wrote:
> On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote:
> 
> > Just to clarify the problem I'm encountering, here's a zoom in on the 
> > processed wave, exactly at the point where gain reduction starts 
> > occuring. This screenshot doesn't apply any of the methods proposed in 
> > the paper, it shows the output of the plugin. This behavior occurs for 
> > the Tap, SC1 and SC4 plugins in Ardour, Audacity and Rezound. All 
> > processed files were saved at 32-bit floating point.
> > 
> > www.geminiflux.com/Tap-processed.jpg

[I miseed the orignal posting, but went back i the archives and found it]

This is kinda interesting, but it's slightly peverse as some ofthe results
can be got by looking at the source! Though it's good to confirm what the
results actually are.

Like Fons I'm a bit concerned about the tests, 0dB square wave in
particular is worrying.

The point about latency is interesting. I did consider delaying the input
in the SC* plugins, but I guess that analogue compressors likly didn't
have it, and they're often considered to be the best so it can't be too
important.

Have you measureued the systemic delay of the waves compressor to verify
that it does have a delay line?

- Steve
From S.W.Harris at ecs.soton.ac.uk  Thu Oct  5 12:12:20 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Thu Oct  5 12:12:46 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005160407.GE31106@login.ecs.soton.ac.uk>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com> <45251342.7050609@geminiflux.com>
	<20061005152920.GF595@bth05w.ABSp.alcatel.be>
	<20061005160407.GE31106@login.ecs.soton.ac.uk>
Message-ID: <20061005161220.GF31106@login.ecs.soton.ac.uk>

On Thu, Oct 05, 2006 at 05:04:07 +0100, Steve Harris wrote:
> On Thu, Oct 05, 2006 at 05:29:20 +0200, Alfons Adriaensen wrote:
> > On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote:
> > 
> > > Just to clarify the problem I'm encountering, here's a zoom in on the 
> > > processed wave, exactly at the point where gain reduction starts 
> > > occuring. This screenshot doesn't apply any of the methods proposed in 
> > > the paper, it shows the output of the plugin. This behavior occurs for 
> > > the Tap, SC1 and SC4 plugins in Ardour, Audacity and Rezound. All 
> > > processed files were saved at 32-bit floating point.
> > > 
> > > www.geminiflux.com/Tap-processed.jpg

The SC* plugins do the same as TAP (calculate the gain every 4 samples),
but I interpolate the gain values between each computation. The
attch/deacay times were slow enough in my testing that it was OK to do
that.

It would be trivial to change the plugins to caclulate every sample, but
at the time they were first released it made the plugin too expensive to
run many at once. Things may be better on current CPUs.

- Steve
From fons.adriaensen at skynet.be  Thu Oct  5 13:07:34 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Thu Oct  5 13:05:35 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005161220.GF31106@login.ecs.soton.ac.uk>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com> <45251342.7050609@geminiflux.com>
	<20061005152920.GF595@bth05w.ABSp.alcatel.be>
	<20061005160407.GE31106@login.ecs.soton.ac.uk>
	<20061005161220.GF31106@login.ecs.soton.ac.uk>
Message-ID: <20061005170734.GB5949@linux-1.site>

On Thu, Oct 05, 2006 at 05:12:20PM +0100, Steve Harris wrote:

> The SC* plugins do the same as TAP (calculate the gain every 4 samples),
> but I interpolate the gain values between each computation. The
> attch/deacay times were slow enough in my testing that it was OK to do
> that.

It should be OK for all practical attack/release times. The only
penalty is 3 samples of delay on the gain change and maybe that's
to be avoided for a hard limiter. For a normal compressor it should
not matter.

-- 
FA

Lascia la spina, cogli la rosa.

From ladev at sound-man.co.uk  Thu Oct  5 14:09:19 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Thu Oct  5 13:49:32 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <4525102F.9030901@geminiflux.com>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com>
Message-ID: <20061005180919.GA2696@localhost.localdomain>

On Thu, Oct 05, 2006 at 09:01:19AM -0500, Andres Cabrera wrote:
> I was assuming that RMS measruments and windowed integration act as a 
> high pass filter, is this not true?

No, a low pass filter integrates and a high pass filter differentiates.

The audio signal is rectified before it can be filtered and used for
gain control, so there is no AC signal for the filter to act on,
just a varying DC level. The time constants for the filter
(eg. charge and discharge rates on a capacitor in an analog LP filter)
determine the rate at which the control signal can increase or
decrease, and hence the attack and decay times.

John
From pw_lists at slinkp.com  Thu Oct  5 13:59:51 2006
From: pw_lists at slinkp.com (Paul Winkler)
Date: Thu Oct  5 14:00:29 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005170734.GB5949@linux-1.site>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com> <45251342.7050609@geminiflux.com>
	<20061005152920.GF595@bth05w.ABSp.alcatel.be>
	<20061005160407.GE31106@login.ecs.soton.ac.uk>
	<20061005161220.GF31106@login.ecs.soton.ac.uk>
	<20061005170734.GB5949@linux-1.site>
Message-ID: <20061005175951.GB1390@slinkp.com>

On Thu, Oct 05, 2006 at 07:07:34PM +0200, Fons Adriaensen wrote:
> On Thu, Oct 05, 2006 at 05:12:20PM +0100, Steve Harris wrote:
> 
> > The SC* plugins do the same as TAP (calculate the gain every 4 samples),
> > but I interpolate the gain values between each computation. The
> > attch/deacay times were slow enough in my testing that it was OK to do
> > that.
> 
> It should be OK for all practical attack/release times. The only
> penalty is 3 samples of delay on the gain change and maybe that's
> to be avoided for a hard limiter. For a normal compressor it should
> not matter.

That is what, 90 microseconds at 44.1 kHz? I don't think there are any
analog compressors that react anywhere near that fast. Don't worry about
it :-)

-- 

Paul Winkler
http://www.slinkp.com
From dsbaikov at gmail.com  Thu Oct  5 14:00:36 2006
From: dsbaikov at gmail.com (Dmitry Baikov)
Date: Thu Oct  5 14:00:57 2006
Subject: [linux-audio-dev] hearnet improvement
Message-ID: <70a871c80610051100m754010a3v51691a279d9002db@mail.gmail.com>

Hi!
First of all, thanks for a great program!

I made two patches for it:
1) make hearnet suid and drop privileges right after libpcap initialization.
 I had to move libpcap init code above jack

So, you can use hearnet as regular user.

2) Mutex in jack_process is a very bad thing. Moreover, it seems
there's no need for it, as voice->active field serves as a mutex.
Attached patch removes pthread_mutex.
If you think voice->active assumption is a weak one, the problem can
be solved with a pair of jack_ringbuffers: one for free voices and one
for active.


Regards,

Dmitry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: privdrop.patch
Type: text/x-patch
Size: 1399 bytes
Desc: not available
Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061005/1a7f99aa/privdrop.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nomutex.patch
Type: text/x-patch
Size: 1182 bytes
Desc: not available
Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061005/1a7f99aa/nomutex.bin
From gene.heskett at verizon.net  Thu Oct  5 14:02:50 2006
From: gene.heskett at verizon.net (Gene Heskett)
Date: Thu Oct  5 14:03:23 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005180919.GA2696@localhost.localdomain>
References: <4524812C.6070402@geminiflux.com> <4525102F.9030901@geminiflux.com>
	<20061005180919.GA2696@localhost.localdomain>
Message-ID: <200610051402.50941.gene.heskett@verizon.net>

On Thursday 05 October 2006 14:09, John Rigg wrote:
>On Thu, Oct 05, 2006 at 09:01:19AM -0500, Andres Cabrera wrote:
>> I was assuming that RMS measruments and windowed integration act as a
>> high pass filter, is this not true?
>
>No, a low pass filter integrates and a high pass filter differentiates.
>
>The audio signal is rectified before it can be filtered and used for
>gain control, so there is no AC signal for the filter to act on,
>just a varying DC level. The time constants for the filter
>(eg. charge and discharge rates on a capacitor in an analog LP filter)
>determine the rate at which the control signal can increase or
>decrease, and hence the attack and decay times.
>
>John

Which is why one of the best compressors of all time, designed by CBS Labs 
back in about 1960, was so good.  It had 2 versions for two different 
broadcast scenarios, one for the 75u-s pre-emphasis of fm, and one that 
was flat for am.  But both had 2 circuits, with the faster circuit having 
microsecond response times to control the peaks while allowing a fairly 
high average.  I'm refering of course to the Volumax and Audimax devices.  
Some of those are still in service, hidden away at transmitters in your 
neighborhood.  The single vacuum tube they used in one of them, a 
'nuvistor' has probably long since been replace by a depletion mode fet 
transistor and the device recalibrated back to factory specs.  And all the 
2 uf electrolytic capacitors used in the original have long since been 
replaced with 2 uf mylars.  At that point, you can literally forget its in 
there, for years at a time.

You couldn't hear it working unless the next audio source switched to was 
-30db from the previous one, then you could hear it slowly raisng the gain 
for several seconds, eventually picking up a peak that opened the high 
speed gate and 100ms later the sound was at the normal level again.  All 
without the sleeping dj ever knowing he wasn't doing his job on the board.

Anything else we attempt to put in there just seems to bring back memories 
of that 5 minutes of heavy breathing from last night, just before you went 
to sleep...

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
From david at olofson.net  Thu Oct  5 14:14:35 2006
From: david at olofson.net (David Olofson)
Date: Thu Oct  5 14:16:26 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005175951.GB1390@slinkp.com>
References: <4524812C.6070402@geminiflux.com>
	<20061005170734.GB5949@linux-1.site>
	<20061005175951.GB1390@slinkp.com>
Message-ID: <200610052014.36097.david@olofson.net>

On Thursday 05 October 2006 19:59, Paul Winkler wrote:
> On Thu, Oct 05, 2006 at 07:07:34PM +0200, Fons Adriaensen wrote:
> > On Thu, Oct 05, 2006 at 05:12:20PM +0100, Steve Harris wrote:
> > 
> > > The SC* plugins do the same as TAP (calculate the gain every 4
> > > samples), 
> > > but I interpolate the gain values between each computation. The
> > > attch/deacay times were slow enough in my testing that it was OK
> > > to do 
> > > that.
> > 
> > It should be OK for all practical attack/release times. The only
> > penalty is 3 samples of delay on the gain change and maybe that's
> > to be avoided for a hard limiter. For a normal compressor it
> > should not matter.
> 
> That is what, 90 microseconds at 44.1 kHz? I don't think there are
> any analog compressors that react anywhere near that fast. Don't
> worry about it :-)

I don't know how fast it *actually* is, but FWIW, my old Behringer 
compressor/limiter has a lowest attack setting of 0.1 ms, and a 
lowest release setting of 50 ms.


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'
From andres at geminiflux.com  Thu Oct  5 22:26:02 2006
From: andres at geminiflux.com (Andres Cabrera)
Date: Thu Oct  5 22:26:11 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005180919.GA2696@localhost.localdomain>
References: <4524812C.6070402@geminiflux.com>	<20061005084554.GA595@bth05w.ABSp.alcatel.be>	<20061005111016.GA3136@localhost.localdomain>	<4525102F.9030901@geminiflux.com>
	<20061005180919.GA2696@localhost.localdomain>
Message-ID: <4525BEBA.4@geminiflux.com>

John Rigg wrote:
> On Thu, Oct 05, 2006 at 09:01:19AM -0500, Andres Cabrera wrote:
>   
>> I was assuming that RMS measruments and windowed integration act as a 
>> high pass filter, is this not true?
>>     
>
> No, a low pass filter integrates and a high pass filter differentiates.
>
>   
Yes, I meant low pass filter.... Maybe the window size or something 
similar has to do with the apparent high pass filtering?

Andr?s


> The audio signal is rectified before it can be filtered and used for
> gain control, so there is no AC signal for the filter to act on,
> just a varying DC level. The time constants for the filter
> (eg. charge and discharge rates on a capacitor in an analog LP filter)
> determine the rate at which the control signal can increase or
> decrease, and hence the attack and decay times.
>
> John
>
>   

From andres at geminiflux.com  Thu Oct  5 22:49:01 2006
From: andres at geminiflux.com (Andres Cabrera)
Date: Thu Oct  5 22:48:52 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005160407.GE31106@login.ecs.soton.ac.uk>
References: <4524812C.6070402@geminiflux.com>	<20061005084554.GA595@bth05w.ABSp.alcatel.be>	<20061005111016.GA3136@localhost.localdomain>	<4525102F.9030901@geminiflux.com>
	<45251342.7050609@geminiflux.com>	<20061005152920.GF595@bth05w.ABSp.alcatel.be>
	<20061005160407.GE31106@login.ecs.soton.ac.uk>
Message-ID: <4525C41D.2070400@geminiflux.com>

Hi,

Steve Harris wrote:
> miseed the orignal posting, but went back i the archives and found it]
>
> This is kinda interesting, but it's slightly peverse as some ofthe results
> can be got by looking at the source! Though it's good to confirm what the
> results actually are.
>
>   
I know... I've been meaning to look at the sources for a while, but 
haven't done it yet...
> Like Fons I'm a bit concerned about the tests, 0dB square wave in
> particular is worrying.
>
>   
I'm curious as to why it is worrying. I'm not expecting the square waves 
to yield particularly important results, but I'm interested to know why 
it seems such a bad idea.
> The point about latency is interesting. I did consider delaying the input
> in the SC* plugins, but I guess that analogue compressors likly didn't
> have it, and they're often considered to be the best so it can't be too
> important.
>
>   
> Have you measureued the systemic delay of the waves compressor to verify
> that it does have a delay line?
>
>   
I tried... but there's no way to turn delay compensation off for plugins 
in Sonar, either in DX or VST versions... So there probably is some 
delay, but I have no way of finding out how much. It's specially hard 
for Waves plugins since they use a rare waveshell which is not 
compatible with most simple hosts. Do waves plugins work with xfst?

Cheers,
Andr?s

> - Steve
>
>   

From andres at geminiflux.com  Thu Oct  5 23:48:07 2006
From: andres at geminiflux.com (Andres Cabrera)
Date: Thu Oct  5 23:48:06 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061005142232.GE595@bth05w.ABSp.alcatel.be>
References: <4524812C.6070402@geminiflux.com>	<20061005084554.GA595@bth05w.ABSp.alcatel.be>	<20061005111016.GA3136@localhost.localdomain>	<4525102F.9030901@geminiflux.com>
	<45251342.7050609@geminiflux.com>
	<20061005142232.GE595@bth05w.ABSp.alcatel.be>
Message-ID: <4525D1F7.90103@geminiflux.com>

Hi,

Here they are:

www.geminiflux.com/SC1-Processed.jpg

www.geminiflux.com/SC4-Processed.jpg



Cheers,
Andr?s


Alfons Adriaensen wrote:
> On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote:
>
>   
>> Just to clarify the problem I'm encountering, here's a zoom in on the 
>> processed wave, exactly at the point where gain reduction starts 
>> occuring. This screenshot doesn't apply any of the methods proposed in 
>> the paper, it shows the output of the plugin. This behavior occurs for 
>> the Tap, SC1 and SC4 plugins in Ardour, Audacity and Rezound. All 
>> processed files were saved at 32-bit floating point.
>>
>> www.geminiflux.com/Tap-processed.jpg
>>     
>
> Interesting. Could you post the pictures for the two others as well ?
>
>
>   

From S.W.Harris at ecs.soton.ac.uk  Fri Oct  6 03:24:10 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Fri Oct  6 03:25:29 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <200610052014.36097.david@olofson.net>
References: <4524812C.6070402@geminiflux.com>
	<20061005170734.GB5949@linux-1.site>
	<20061005175951.GB1390@slinkp.com>
	<200610052014.36097.david@olofson.net>
Message-ID: <20061006072410.GB31234@login.ecs.soton.ac.uk>

On Thu, Oct 05, 2006 at 08:14:35 +0200, David Olofson wrote:
> On Thursday 05 October 2006 19:59, Paul Winkler wrote:
> > On Thu, Oct 05, 2006 at 07:07:34PM +0200, Fons Adriaensen wrote:
> > > On Thu, Oct 05, 2006 at 05:12:20PM +0100, Steve Harris wrote:
> > > 
> > > > The SC* plugins do the same as TAP (calculate the gain every 4
> > > > samples), 
> > > > but I interpolate the gain values between each computation. The
> > > > attch/deacay times were slow enough in my testing that it was OK
> > > > to do 
> > > > that.
> > > 
> > > It should be OK for all practical attack/release times. The only
> > > penalty is 3 samples of delay on the gain change and maybe that's
> > > to be avoided for a hard limiter. For a normal compressor it
> > > should not matter.
> > 
> > That is what, 90 microseconds at 44.1 kHz? I don't think there are
> > any analog compressors that react anywhere near that fast. Don't
> > worry about it :-)
> 
> I don't know how fast it *actually* is, but FWIW, my old Behringer 
> compressor/limiter has a lowest attack setting of 0.1 ms, and a 
> lowest release setting of 50 ms.

So that would be a little iffy. SC4 only advertises that it goes down to
1.5ms, which gives something like 90 segments in the attack segment.

Looking at the code, the compressors use a pretty expensive linear -> dB
conversion routine (cubicly interpolated lookup table) to work out the
gain changes, maybe I could substitute a cheap approximation function.
I'll bet that analogue compressors didn't use accurace logarithmic
approximations. I'm not sure It'd be worth dropping the calcualtion period
below 2 though.

- Steve
From S.W.Harris at ecs.soton.ac.uk  Fri Oct  6 03:42:19 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Fri Oct  6 03:42:42 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <4525D1F7.90103@geminiflux.com>
References: <4524812C.6070402@geminiflux.com>
	<20061005084554.GA595@bth05w.ABSp.alcatel.be>
	<20061005111016.GA3136@localhost.localdomain>
	<4525102F.9030901@geminiflux.com> <45251342.7050609@geminiflux.com>
	<20061005142232.GE595@bth05w.ABSp.alcatel.be>
	<4525D1F7.90103@geminiflux.com>
Message-ID: <20061006074219.GC31234@login.ecs.soton.ac.uk>

On Thu, Oct 05, 2006 at 10:48:07 -0500, Andres Cabrera wrote:
> Hi,
> 
> Here they are:
> 
> www.geminiflux.com/SC1-Processed.jpg
> 
> www.geminiflux.com/SC4-Processed.jpg

What's that glitch near the cursor? Is that a bug, or was it in the input
waveform?

What immediatly strikes me as wierd is that you don't get that rippling
effect in the attack, or at least it's not as pronounced. Without delving
into the code too deeply, I think theres a bug, theres some interpolation
factor that's calculated from the attack coefficient (ef_a), but then its
later applied whether were in the attack segment or the decay segment.

So actually it's not linearly interpolated, I think I was attempting to
process the gain response with the envelope function. But I'm not really
sure, as theres no comments in the code (bad Steve, no biscuit).

- Steve
From fons.adriaensen at alcatelaleniaspace.com  Fri Oct  6 04:59:47 2006
From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen)
Date: Fri Oct  6 05:00:14 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061006072410.GB31234@login.ecs.soton.ac.uk>
References: <4524812C.6070402@geminiflux.com>
	<20061005170734.GB5949@linux-1.site>
	<20061005175951.GB1390@slinkp.com>
	<200610052014.36097.david@olofson.net>
	<20061006072410.GB31234@login.ecs.soton.ac.uk>
Message-ID: <20061006085947.GA1276@bth05w.ABSp.alcatel.be>

On Fri, Oct 06, 2006 at 08:24:10AM +0100, Steve Harris wrote:

> Looking at the code, the compressors use a pretty expensive linear -> dB
> conversion routine (cubicly interpolated lookup table) to work out the
> gain changes, maybe I could substitute a cheap approximation function.
> I'll bet that analogue compressors didn't use accurace logarithmic
> approximations.

Most didn't, and the set compression ratio was just an indication
of how strong the effect would be, and by no means constant over the
dynamic range. And that was probably part of their charm. Many of the
control circuits were just designed or tweaked by trial and error
rather than trying to follow some exact mathematical law.

The same can be said of the time constants, in particular the
attack time, which in most analog circuits depends on the actual
levels (the higher, the faster). Just the simple combination of a
diode and a capacitor defeats any analysis in simple terms, since
a real diode is highly non-linear.

A lot depends on if the compressor uses feed-forward control
(i.e. the gain is controlled by the input signal), or feedback
gain control (the gain is controlled by the output level).
At high compression ratios, FF requires very precise control
voltage manipulation, and most analog equipment would use FB
for that reason.


-- 
FA

Lascia la spina, cogli la rosa.
From andres at geminiflux.com  Fri Oct  6 10:31:56 2006
From: andres at geminiflux.com (Andres Cabrera)
Date: Fri Oct  6 10:31:45 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061006074219.GC31234@login.ecs.soton.ac.uk>
References: <4524812C.6070402@geminiflux.com>	<20061005084554.GA595@bth05w.ABSp.alcatel.be>	<20061005111016.GA3136@localhost.localdomain>	<4525102F.9030901@geminiflux.com>
	<45251342.7050609@geminiflux.com>	<20061005142232.GE595@bth05w.ABSp.alcatel.be>	<4525D1F7.90103@geminiflux.com>
	<20061006074219.GC31234@login.ecs.soton.ac.uk>
Message-ID: <452668DC.5010503@geminiflux.com>

Hi Steve,
> What's that glitch near the cursor? Is that a bug, or was it in the input
> waveform?
>   

There is a very odd glitch there... I just repeated the test and the 
glitch is produced by the plugin, apparently from a sample that is 
wrapped around when the amplitude = maximum but only when using 
Rezound.... The output generated by Audacity doesn't have this glitch.
> What immediatly strikes me as wierd is that you don't get that rippling
> effect in the attack, or at least it's not as pronounced. Without delving
> into the code too deeply, I think theres a bug, theres some interpolation
> factor that's calculated from the attack coefficient (ef_a), but then its
> later applied whether were in the attack segment or the decay segment.
Yes, it appears the rippling is only there when gain reduction starts to 
be applied. Maybe the envelope tracker takes a while to kick in? Maybe 
that's the reason why the rippling starts when gain reduction starts to 
be applied, since gain reduction is not applied from the start, but a 
little into the sound. Bear in mind that the images show the first peak 
of the sample (even though the sample scale might suggest some time has 
elapsed-the sample contains some silence at the beginning)


> ope function. But I'm not really
> sure, as theres no comments in the code (bad Steve, no biscuit).
>
>   
Thanks for having a look.

Cheers,
Andr?s

From rncbc at rncbc.org  Fri Oct  6 19:24:55 2006
From: rncbc at rncbc.org (Rui Nuno Capela)
Date: Fri Oct  6 19:22:08 2006
Subject: [linux-audio-dev] [ANN] QjackCtl 0.2.21 is out!
Message-ID: <4526E5C7.8070409@rncbc.org>

Greetings,

In the wake of the JACK 0.102.20 release, here goes the respective
friendly GUI: QjackCtl 0.2.21 is out.

As usual, the change-log says it all:

- GPL address update.

- All window captions can now be set smaller as tool-widgets. This
option takes effect when child windows are kept always on top.

- For the brave of heart, specially the ones brave enough to try with
Stephane Letz's jackdmp, a win32 build should be now possible.

- The main window button text labels are now optional (after a kind
suggestion by Geoff Beasley, thanks).

- Increse default maximum number of ports setting from 128 to 256.

- Initial freebob backend driver support. Also changed the coreaudio
backend driver command line device name/id parameter (EXPERIMENTAL).

- Closing the main window while not as an active JACK client, nor under
a server running state, will just quit the whole application, even
though the system-tray icon option is in effect.

- The most relevant transport commands (Rewind, Play and Pause) are now
made available on the main window context popup menu.

- The post-shutdown script is now also being called when using the Stop
button, whether the jackd server has been started internally or not. The
initial hard-coded default is now on and set to `killall jackd` (as a
workaround to an old request from Stephane Letz).

- The main window buttons display are now optional. One can choose
whether the left, right and/or transport buttons are hidden, making it
for a total of six different modes for the main window presentation
(after a much simpler suggestion from Paul Davis and Stephane Letz).

- Added configure support for x86_64 libraries (UNTESTED).

Nuff this time.

Hope you enjoy.
--
rncbc aka Rui Nuno Capela

From dmills_00 at yahoo.co.uk  Sat Oct  7 09:18:24 2006
From: dmills_00 at yahoo.co.uk (Dan Mills)
Date: Sat Oct  7 09:19:02 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <200610052014.36097.david@olofson.net>
References: <4524812C.6070402@geminiflux.com>
	<20061005170734.GB5949@linux-1.site> <20061005175951.GB1390@slinkp.com>
	<200610052014.36097.david@olofson.net>
Message-ID: <1160227104.5212.7.camel@localhost>

On Thu, 2006-10-05 at 20:14 +0200, David Olofson wrote:

> I don't know how fast it *actually* is, but FWIW, my old Behringer 
> compressor/limiter has a lowest attack setting of 0.1 ms, and a 
> lowest release setting of 50 ms.

If those sort of settings are to be available in a software compressor
then we need upsampling as the bandwidth of the sidechain must be at
least 10Khz (and possibly much higher) and the product of a 10Khz
bandwidth sidechain and a 20Khz bandwidth audio stream exceeds 1/2 the
SR for 44.1 and 48Khz. 

For slower compression, the possibility of just including a low pass
filter in the sidechain processing just before the final sample * gain
calculation is an alternative. 

Good dynamics processing in software is a pig. 

Regards, Dan. 


		
___________________________________________________________ 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
From ico at vt.edu  Sat Oct  7 23:16:39 2006
From: ico at vt.edu (Ivica Ico Bukvic)
Date: Sat Oct  7 23:16:54 2006
Subject: [linux-audio-dev] Linuxaudio.org seeking volunteer help
Message-ID: <000901c6ea88$2bb7de80$0502a8c0@64BitBadass>

October 7, 2006 -- Linuxaudio.org announces new staff openings

If applicable, please forward to your respective mailing lists.

FOR IMMEDIATE RELEASE:

With increasing membership and expanding services, Linuxaudio.org is 
experiencing growing pains. As a result, the existing staff is overwhelmed
with day-to-day operations, which is making overseeing long-term strategic 
goals, increasingly difficult. For this reason, we would like to invite 
LAU/LAD members, to consider joining our staff in order to help keep up with

the daily activities. Committing to Linuxaudio.org has never been easier as 
the service term for these is very flexible: once you commit to any of the 
duties stated below, you will be able to back out at any time (obviously 
advance notice will be very much appreciated).

Please note that these are currently volunteer positions (something that may

change in the future, but one should probably not apply for these in hopes 
that this will happen anytime soon). The benefits include:

1) free membership
2) credit where credit is due
3) references/letters of support
4) PR for your work and your project (if applicable)
5) recognition within the Linuxaudio.org, Linux audio community, and beyond

Please see the list of vacancies below:

1) Linuxaudio.org Webmaster (1 position)
Duties: Update content, monitor consortium mailing lists for new updates, 
actively participate in the management discussions/meetings.
Prerequisites: fluent English, active member of the Linux audio community.

2) Docs.linuxaudio.org creator/Webmaster (2-4 positions)
Duties: Design a template for the documentation project (i.e. Wiki), solicit
and format documentation submitted by others, write documentation for 
software projects while maintaining unified framework (i.e. similar to ALSA 
soundcard Matrix install how-to), participate in the consortium mailing
list.
Prerequisites: solid English writing skills, active member of the Linux
audio community, familiarity with HTML/CSS, optimized Web graphics 
editing/creating skills preferred (i.e. Gimp).

3) Project Updates and Press Release Summary Writer (2 positions)
Duties: Solicit new updates from members using consortium mailing list, 
forward monthly summary to the Linuxaudio.org Webmaster for online posting, 
compile Press Releases for relevant stories, participate in the consortium 
mailing list.
Prerequisites: solid English writing skills, active member of the Linux
audio community, past writing experience preferred.

4) Freelance Writers/Interviewers (unlimited number of positions)
Duties: submit monthly (or bi-weekly) articles to the Linuxaudio.org (topics
are left to your choice as long as they are relevant to our agenda), writers

are strongly encouraged to develop a topic-driven periodical with revolving 
topics which are pertinent to membership and the Linuxaudio.org's mission 
(i.e. member project interviews, how-tos, updates, etc.), participate in the
consortium mailing list.
Prerequisites: solid English writing skills, active member of the Linux
audio community, past writing experience preferred.

5) Membership recruiters (2 positions)
Duties: recruit new members for Linuxaudio.org primarily focusing on the
relevant projects within the Linux community, report new members to director
for bi-monthly updates, coordinate with other recruiters, participate in the

consortium mailing list and management list.
Prerequisites: strong communication/recruitment skills, solid English,
preferably active member of the Linux audio community.

Please note that the consortium mailing list is relatively low-volume, so
keeping up with it should not cause you much of an overhead. Similarly, most
of the aforesaid positions bear low overhead requiring no more than a few
hours per week of your time.

Again, if interested, please contact Linuxaudio.org director at
ico_AT_linuxaudio_DOT_org.

Linuxaudio.org is now bigger and stronger than ever and we hope to continue
to grow until we encompass most if not all libre Linux audio projects, as
well as allied corporate vendors, institutions, artists, and non-profit
organizations, therefore allowing us to best represent, nurture, and protect
interests of this vibrant community. Linux audio scene is already a very
powerful branch of the Linux scene and with the help of Linuxaudio.org we
can make great things happen. For this reason, we hope you will consider
partaking in this new exciting initiative by Linuxaudio.org.

ABOUT LINUXAUDIO.ORG
Linuxaudio.org is a not-for-profit consortium of libre software
projects and artists, companies, institutions, organizations, and
hardware vendors using Linux kernel-based systems and allied libre software
for audio-related work, with an emphasis on professional tools for 
the music, production, recording, and broadcast industries. The consortium
aims to co-ordinate joint projects between members, collaborate on the 
promotion of Linux based systems for audio tasks, offer programs beneficial 
to members and subsequently its mission, and provide a single point of 
contact for prospective industry partners.

More information on the Linuxaudio.org consortium can be obtained by
visiting:

http://www.linuxaudio.org/

Press contacts: Ivica Ico Bukvic at (ico at linuxaudio dot org)

ends

From dlphillips at woh.rr.com  Wed Oct 11 18:05:18 2006
From: dlphillips at woh.rr.com (Dave Phillips)
Date: Wed Oct 11 17:39:49 2006
Subject: [linux-audio-dev] question about a c++ error
Message-ID: <452D6A9E.7020603@woh.rr.com>

Greetings:

This is perhaps a bit OT (or more than a bit). I'm eager to work with a 
new macro for Open Office that inserts LilyPond-encoded music fragments 
into an OOo document, but I've hit an unusual snag. The macro is 
installed correctly, but when I try to use it I receive this error:

terminate called after throwing an instance of
'std::logic_error'
what():basic_string::_S_construct
           NULL not valid

It almost looks poetic. :)

Alas, Google wasn't much help, and the author of the macro has no idea 
why this error results (his code contains no C++). Can any C++ guru here 
shed any light on the how/what/why of the error ? Maybe even suggest a 
fix ?

LilyPond 2.8.4, OOo 2.03, and I'll be happy to supply any other needed 
information.

And yes, the error has been posted on the LP dev list.

Best,

dp

From jens.andreasen at chello.se  Thu Oct 12 00:26:17 2006
From: jens.andreasen at chello.se (Jens M Andreasen)
Date: Thu Oct 12 00:26:29 2006
Subject: [linux-audio-dev] question about a c++ error
In-Reply-To: <452D6A9E.7020603@woh.rr.com>
References: <452D6A9E.7020603@woh.rr.com>
Message-ID: <1160627177.9224.116.camel@c80-216-124-251.cm-upc.chello.se>

On Wed, 2006-10-11 at 18:05 -0400, Dave Phillips wrote:

>   terminate called after throwing 
>     an instance of 'std::logic_error'
>   what():basic_string::_S_construct
>              NULL not valid
> 
> It almost looks poetic. :)
> 

Shakespeare! :)

> Alas, Google wasn't much help, and the author of the macro has no idea 
> why this error results (his code contains no C++). Can any C++ guru here 
> shed any light on the how/what/why of the error ? Maybe even suggest a 
> fix ?

Not a guru, but have thrown a few errors around.

It looks like it is the interpreter in OO that ends up in a confused
state, apparently trying to create a string out of nothing, perhaps
after the end of input. The reason could be:

* A programming error (thinko) in the macro
* A bug in the OO macro interpreter

Either way, it might be a good idea to ask on the OO dev/user lists as
well.
-- 

From taybin at earthlink.net  Thu Oct 12 09:46:57 2006
From: taybin at earthlink.net (Taybin Rutkin)
Date: Thu Oct 12 09:47:04 2006
Subject: [linux-audio-dev] question about a c++ error
Message-ID: <2735669.1160660817647.JavaMail.root@elwamui-little.atl.sa.earthlink.net>

Just a guess, but it looks like at some point it is trying to create a NULL string, which isn't allowed (apparently).  I'm not sure if this is helpful or obvious to you.

Taybin

-----Original Message-----
>From: Dave Phillips <dlphillips@woh.rr.com>
>Sent: Oct 11, 2006 6:05 PM
>To: LAD Mail List <linux-audio-dev@music.columbia.edu>
>Subject: [linux-audio-dev] question about a c++ error
>
>Greetings:
>
>This is perhaps a bit OT (or more than a bit). I'm eager to work with a 
>new macro for Open Office that inserts LilyPond-encoded music fragments 
>into an OOo document, but I've hit an unusual snag. The macro is 
>installed correctly, but when I try to use it I receive this error:
>
>terminate called after throwing an instance of
>'std::logic_error'
>what():basic_string::_S_construct
>           NULL not valid
>
>It almost looks poetic. :)
>
>Alas, Google wasn't much help, and the author of the macro has no idea 
>why this error results (his code contains no C++). Can any C++ guru here 
>shed any light on the how/what/why of the error ? Maybe even suggest a 
>fix ?
>
>LilyPond 2.8.4, OOo 2.03, and I'll be happy to supply any other needed 
>information.
>
>And yes, the error has been posted on the LP dev list.
>
>Best,
>
>dp
>

From doj at cubic.org  Fri Oct 13 06:02:04 2006
From: doj at cubic.org (Dirk Jagdmann)
Date: Fri Oct 13 06:02:47 2006
Subject: [linux-audio-dev] question about a c++ error
In-Reply-To: <452D6A9E.7020603@woh.rr.com>
References: <452D6A9E.7020603@woh.rr.com>
Message-ID: <452F641C.9070007@cubic.org>

> This is perhaps a bit OT (or more than a bit). I'm eager to work with a 
> new macro for Open Office that inserts LilyPond-encoded music fragments 
> into an OOo document, but I've hit an unusual snag. The macro is 
> installed correctly, but when I try to use it I receive this error:
> 
> terminate called after throwing an instance of
> 'std::logic_error'
> what():basic_string::_S_construct
>           NULL not valid
> 
> It almost looks poetic. :)
> 
> Alas, Google wasn't much help, and the author of the macro has no idea 
> why this error results (his code contains no C++). Can any C++ guru here 
> shed any light on the how/what/why of the error ? Maybe even suggest a 
> fix ?

The following program produces the exact error message (aka throws this 
c++ exception):
$ cat a.cpp
#include <string>
int main()
{
   std::string s(NULL);
   return 0;
}
$ c++ a.cpp
$ ./a.out
terminate called after throwing an instance of 'std::logic_error'
   what():  basic_string::_S_construct NULL not valid
Aborted (core dumped)

So somewhere in the OOo code a std::string object is created but it is 
passed a null pointer in the constructor. Of course you should not find 
a call like "std::string s(NULL);" in the OOo codebase, but more likely 
something like "std::string s(somestr);" where "somestr" is a "char*". 
It could also result from a function call like

void foo(std::string s) { }
char *str=NULL;
foo(str);

However the following test program shows a different behaviour:
$ cat b.cpp
#include <string>
int main()
{
   char *str=NULL;
   std::string s;
   s=str;
   return 0;
}
$ c++ b.cpp
$ ./a.out
Segmentation fault (core dumped)

This is the reason I suspect an array call to be the likeliest case for 
throwing the exception.

Now how to fix this? I suggest you compile yourself OOo with debugging 
enabled, then run your OOo with gdb and do your tests which should throw 
the exception. Then you can easily backtrace (bt) or go up (up) untill 
you find the throwling source code line. Then you can choose to either 
do a quick'n'dirty fix and just prefix the string construction with some 
  "if(str==NULL)return;" or similar or look further to fix the reason 
why the C-String has not been initialized correctly (thus still be NULL).

-- 
---> Dirk Jagdmann ^ doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org
From ladev at sound-man.co.uk  Sun Oct 15 07:05:14 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Mon Oct 16 10:45:23 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <1160227104.5212.7.camel@localhost>
References: <4524812C.6070402@geminiflux.com>
	<20061005170734.GB5949@linux-1.site>
	<20061005175951.GB1390@slinkp.com>
	<200610052014.36097.david@olofson.net>
	<1160227104.5212.7.camel@localhost>
Message-ID: <20061015110514.GA3059@localhost.localdomain>

On Sat, Oct 07, 2006 at 02:18:24PM +0100, Dan Mills wrote:
> If those sort of settings are to be available in a software compressor
> then we need upsampling as the bandwidth of the sidechain must be at
> least 10Khz (and possibly much higher) and the product of a 10Khz
> bandwidth sidechain and a 20Khz bandwidth audio stream exceeds 1/2 the
> SR for 44.1 and 48Khz.

While we're on this subject, has anyone analysed the aliasing behaviour
of the LADSPA compressors? This post reminded me of an article I read
in the AES journal a while back, and a search on aes.org found it:

Aliasing in Digital Clippers and Compressors
- Paul Kraght - Nov 2000 AES Journal

The author refers to some previous work by Mapes-Riordan, who has
a quick overview of the problem here:
http://www.omniaaudio.com/tech/dynamics.htm

As Ben Loftis points out, it might be nice to address any potential
problems here before the inevitable growth of interest from high end
users.

John
From dsbaikov at gmail.com  Sun Oct 15 17:14:48 2006
From: dsbaikov at gmail.com (Dmitry Baikov)
Date: Mon Oct 16 11:03:15 2006
Subject: [linux-audio-dev] ghostess patches
Message-ID: <70a871c80610151414v66a93331q3b3275990a957327@mail.gmail.com>

Hi!

Sean, thanks a lot for ghostess!
Take a look at the patches if you have time.

-execlp patch fixes things on 64-bit architectures: execlp() expects
its arglist to end with NULL, not 0. And on 64-bit architectures they
are different (0 is 32-bit int, and NULL is 64-bit pointer).

-configure and -jackmidi patches are from gentoo proaudio overlay and
are included for completeness.


Regards,
Dmitry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghostess-execlp.patch
Type: text/x-patch
Size: 1219 bytes
Desc: not available
Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061016/88d113b8/ghostess-execlp.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghostess-configure.patch
Type: text/x-patch
Size: 1049 bytes
Desc: not available
Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061016/88d113b8/ghostess-configure.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghostess-jackmidi.patch
Type: text/x-patch
Size: 1010 bytes
Desc: not available
Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061016/88d113b8/ghostess-jackmidi.bin
From ladev at sound-man.co.uk  Mon Oct 16 13:18:36 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Mon Oct 16 15:16:44 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061015110514.GA3059@localhost.localdomain>
References: <4524812C.6070402@geminiflux.com>
	<20061005170734.GB5949@linux-1.site>
	<20061005175951.GB1390@slinkp.com>
	<200610052014.36097.david@olofson.net>
	<1160227104.5212.7.camel@localhost>
	<20061015110514.GA3059@localhost.localdomain>
Message-ID: <20061016171836.GA2609@localhost.localdomain>

On Sun, Oct 15, 2006 at 12:05:14PM +0100, John Rigg wrote:
> The author refers to some previous work by Mapes-Riordan, who has
> a quick overview of the problem here:
> http://www.omniaaudio.com/tech/dynamics.htm

Oops. The linked-to article is by Frank Foti. Dan Mapes-Riordan's
article "A Worst Case Analysis for Analog-Quality (Alias-Free)
Digital Dynamics Processing" appeared in AES journal Nov 1999. It described
a nice test method using a pair of swept sine waves around 10Hz apart
to give an amplitude modulated signal which exercises the attack and
decay of the compressor under test. As the input fundamental frequencies
approach the upper limit of hearing, they decrease in loudness and the
lower-frequency aliasing artifacts become more audible.

John
From dmills_00 at yahoo.co.uk  Mon Oct 16 14:48:35 2006
From: dmills_00 at yahoo.co.uk (Dan Mills)
Date: Mon Oct 16 16:11:20 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061015110514.GA3059@localhost.localdomain>
Message-ID: <20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>


--- John Rigg <ladev@sound-man.co.uk> wrote:

> While we're on this subject, has anyone analysed the
> aliasing behaviour
> of the LADSPA compressors? This post reminded me of
> an article I read
> in the AES journal a while back, and a search on
> aes.org found it:

I just hacked up a little experiment, by making SC4
output the gain control signal in place of the right
channel and using Jaaa.

It turns out that we DONT handle this at all!

The gain control signal has energy right the way out
to the band limit (and probably aliased around it),
never mind what happens when that hits the multiplier!

Fixing this right means upsampling and adding a
lowpass filter to the control loop, then downsampling
again. Anyone have a pointer to the latest version of
that fast factor of two resampler that was posted here
kicking around? 

Fixing it crude (but probably close enough) means
adding a serious LPF at a few Khz in the sidechain
just before the gain multiplier....
Note that doing this inherently limits the speed of
the attack. 

The problem is that SC4 is far from the only
problematic case, I don't see ANY of the ladspa
dynamics plugins getting this right (with the possible
exception of the 'Dyson' compressor, and I am not too
sure about that one).
 
Regards, Dan (Who is now honour bound to propose a
patch), working on it.  

Send instant messages to your online friends http://uk.messenger.yahoo.com 
From fons.adriaensen at skynet.be  Tue Oct 17 05:56:20 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Tue Oct 17 05:54:19 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
Message-ID: <20061017095620.GC5877@linux-1.site>

On Mon, Oct 16, 2006 at 07:48:35PM +0100, Dan Mills wrote:

> The gain control signal has energy right the way out
> to the band limit (and probably aliased around it),
> never mind what happens when that hits the multiplier!

The question is: how much of this HF energy is there ?

There shouldn't be much in a compressor with controlled
attack / release times. In that case it is always possible
to filter the control signal. In fact the obvious way to set
attack / release times is by such filtering !
 
A fast peak limiter could still do this. But even here it can
be avoided by look-ahead, i.e. having a short delay on the
audio which in turn allows a finite attack time.

A fast limiter needs a higher sample rate or interpolation
anyway, just to detect the correct peak level. Remember that
'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a
signal when converted to the analog domain can be several
dB above that of the highest sample.

-- 
FA

Lascia la spina, cogli la rosa.

From S.W.Harris at ecs.soton.ac.uk  Tue Oct 17 08:06:17 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Tue Oct 17 08:06:56 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017095620.GC5877@linux-1.site>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
	<20061017095620.GC5877@linux-1.site>
Message-ID: <20061017120617.GA5923@login.ecs.soton.ac.uk>

On Tue, Oct 17, 2006 at 11:56:20 +0200, Fons Adriaensen wrote:
> On Mon, Oct 16, 2006 at 07:48:35PM +0100, Dan Mills wrote:
> 
> > The gain control signal has energy right the way out
> > to the band limit (and probably aliased around it),
> > never mind what happens when that hits the multiplier!
> 
> The question is: how much of this HF energy is there ?
> 
> There shouldn't be much in a compressor with controlled
> attack / release times. In that case it is always possible
> to filter the control signal. In fact the obvious way to set
> attack / release times is by such filtering !

Right, the RMS envelope follower in SC* is a lowpass filter, though its
only a one pole IIRC, so it wont be steep enough to kill off everything in
the top end.

> A fast limiter needs a higher sample rate or interpolation
> anyway, just to detect the correct peak level. Remember that
> 'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a
> signal when converted to the analog domain can be several
> dB above that of the highest sample.

True enough, and infact the SWH lookahead limiter doesn't upsample. It
probably should do, but it's quite expensive.

- Steve
From ladev at sound-man.co.uk  Tue Oct 17 08:53:40 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Tue Oct 17 08:31:12 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017095620.GC5877@linux-1.site>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
	<20061017095620.GC5877@linux-1.site>
Message-ID: <20061017125340.GA2617@localhost.localdomain>

On Tue, Oct 17, 2006 at 11:56:20AM +0200, Fons Adriaensen wrote:
> On Mon, Oct 16, 2006 at 07:48:35PM +0100, Dan Mills wrote:
> > The gain control signal has energy right the way out
> > to the band limit (and probably aliased around it),
> > never mind what happens when that hits the multiplier!
> 
> The question is: how much of this HF energy is there ?
> There shouldn't be much in a compressor with controlled
> attack / release times. In that case it is always possible
> to filter the control signal. In fact the obvious way to set
> attack / release times is by such filtering !

True, but if the audio signal contains significant HF energy near
the band limit, it doesn't take a very fast gain change to push it
past that. Bear in mind that the ear is _very_ sensitive to aliasing
artifacts, so `significant' can be a very small amount.

John
From paul at linuxaudiosystems.com  Tue Oct 17 09:59:10 2006
From: paul at linuxaudiosystems.com (Paul Davis)
Date: Tue Oct 17 09:59:44 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017095620.GC5877@linux-1.site>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
	<20061017095620.GC5877@linux-1.site>
Message-ID: <1161093550.17041.62.camel@localhost.localdomain>

On Tue, 2006-10-17 at 11:56 +0200, Fons Adriaensen wrote:

> 'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a
> signal when converted to the analog domain can be several
> dB above that of the highest sample.

indeed. there are people who are coming to believe that this "error" is
responsible for a significant part of the audible difference between
digital and analog playback when the levels in the source material are
high. 

From fons.adriaensen at skynet.be  Tue Oct 17 10:43:39 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Tue Oct 17 10:41:47 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <1161093550.17041.62.camel@localhost.localdomain>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
	<20061017095620.GC5877@linux-1.site>
	<1161093550.17041.62.camel@localhost.localdomain>
Message-ID: <20061017144339.GF5877@linux-1.site>

On Tue, Oct 17, 2006 at 09:59:10AM -0400, Paul Davis wrote:
> On Tue, 2006-10-17 at 11:56 +0200, Fons Adriaensen wrote:
> 
> > 'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a
> > signal when converted to the analog domain can be several
> > dB above that of the highest sample.
> 
> indeed. there are people who are coming to believe that this "error" is
> responsible for a significant part of the audible difference between
> digital and analog playback when the levels in the source material are
> high. 

It could be. OTOH, most DACs today would upsample and filter before the
real conversion takes place, and could allow for this. But maybe they
don't, and just clip at that point.

-- 
FA

Lascia la spina, cogli la rosa.

From simon at schampijer.de  Tue Oct 17 11:52:26 2006
From: simon at schampijer.de (Simon Schampijer)
Date: Tue Oct 17 11:53:00 2006
Subject: [linux-audio-dev] Linux Audio Conference #5 (LAC2007): Call for
	Papers, Music, etc
Message-ID: <4534FC3A.6020903@schampijer.de>

Dear all,

we are happy to announce the call for papers for the 5th Linux Audio 
Developers Conference (LAC2007). The conference is organized by the 
TU-Berlin in cooperation with people of the Linux Audio Developers 
mailing list, the music festival Inventionen 2007 and the Humboldt 
University of Berlin.

The LAC2007 is taking place at the TU-Berlin, Germany from the 22nd - 
25th of March 2007.

We have introduced some new tracks. Besides the category for papers, 
demos and workshops, calls for tutorials and hands on demos have been 
added. The tutorials aim is to give new (potential) users an overview of 
the possibilities of Linux Audio Software and how to get started. The 
LAC2007 provides a computer pool (LA Pool) where developers can give an 
introduction to their software and where participants can try out Linux 
Audio Software during the conference. This has been combined in the call 
hands on demos.
Since the TU-Berlin is installing a new Wave Field Synthesis (WFS) 
system the call for music has been extended by a call for compositions 
for this system. Music that can be used for radio airplay can be 
submitted, and will after acceptance by the Campusradio of the TU 
Berlin, be played during the conference.

More detailed Information can be found in the 'Call for Papers' attached 
to this email or on the website at: http://www.kgw.tu-berlin.de/~lac2007/

We are looking forward to many interesting submissions for the Linux 
Audio Conference 2007 and hope to see you in Berlin in 2007!

Please feel free to forward this email to anybody who is interested.

On behalf of the LAC2007 organisation team,
Simon Schampijer and Marije Baalman




-------------- next part --------------
Call for the Linux Audio Conference 2007 - 22nd - 25th of March 2007
      taking place at the Technische Universit?t Berlin
in cooperation with Inventionen 2007 and the Humboldt University of Berlin


This call includes:

Call for Papers
Call for Demos
Call for Hands On Demos
Call for Workshops
Call for Tutorials
Call for Music (categories: Concert, Club, Radio and Wave Field Synthesis)

-----------------------------

Call for Papers

 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. This includes (but is not limited to) the following categories: 
 Computer Music 
 Music Production 
 Instruments 
 Drivers and Sound Architecture 
 Audio Distributions 
 Generic (Usage, Documentation etc.) 

 The conference is held in English. 

 Length of a paper is 4-8 pages. Papers have to include an abstract (50-100 words). The abstract will be published separately on the conference website once the paper has been accepted. Also, papers should include up to 5 keywords. 

 In general talks should take 20-30 minutes followed by 5 minutes discussion. 

 Please notify us if you need a special technical setup. The technical standard setup will be: 
microphone (head set) 
projector with XVGA input (resolution 1024x768) 
stereo speaker setup with mini jack input 
a PC with a pdf viewer 

 How to submit 
File format is PDF, formatted for A4 paper. Make use of the templates for paper formatting available at: http://www.kgw.tu-berlin.de/~lac2007/download/templates-lac2007.tar.gz
 
See our check list to ensure that you do not forget to enclose all necessary information.
 
Send your paper and all necessary information by 8 Jan 2007 via email to this address: lac2007 AT robin.kgw.tu-berlin.de 
You will be notified by 05 Feb 2007 whether your paper has been accepted. The reviewers may ask you to modify your paper in order to be accepted. The deadline for the final version is March 1, 2007. 

 Important Dates 

 08 Jan 2007: Paper submission deadline 
 05 Feb 2007: Notification of acceptance
 01 Mar 2007: Final version deadline 

 22 - 25 March 2007: Conference 


-----------------------------
 Call for Demos

 You do not need to write a whole paper, but rather a short abstract only (50-100 words). This category is mainly thought for software demos. Be aware though that in case of too many submissions papers take priority over demos... 

 See section "Call for Papers" for info on the duration of talks and the technical setup.

-----------------------------
 Call for Hands On Demos

 A new item of the LAC 2007 is LA Pool: a pool with Linux audio computers, on which programs can be demonstrated. To give a "hands on" demo you can reserve LA Pool for 1 hour, of which ca. 20 minutes can be used as a general introduction and the rest should be free for participants to try out the program and ask questions.
 A Hands On demo can be held in addition to a Paper Presentation or as the presentation for the Demo, so you need to either submit a paper or an abstract as mentioned above. Additionally, you need to give us a version of your software, with clear installation instructions and requirements, so that we can install the software on the Pool before the conference.


 How to submit 
See our check list to ensure that you do not forget to enclose all necessary information. 
Send your abstract and all necessary information by 8 Jan 2007 via email to this address: lac2007 AT robin.kgw.tu-berlin.de 


 Deadline for submissions is 08 Jan 2007. 

You will be notified by 05 Feb 2007 whether your submission has been accepted. 

----------------------------- 
 Call for Workshops

 With respect to their content workshops do not differ from talks: Workshops can have technical focus as well as artistic or scientific focus. Workshops can be targeted to developers as well as users. See section "Call for Papers" for more info on this. 

 The shape of the workshop is completely up to you. E.g. it can be tutorial-like ("how to write an ALSA driver/ a jack application/ a LADSPA plugin/ etc.") or it can be BOFS-like (e.g. a meeting of like-minded users and/or developers to exchange experience and knowledge about a specific topic), or it can be anything in between. 

 Workshops can take place in seminar rooms or in a public space like the TU Lichthof. Depending on the location, attendance might be limited to ca 10 people. 

 We strongly encourage you to submit early. It will be more likely to get a free slot and it will be easier for attendants to know about the workshop if it is published on the conference website. If you expect the attendants to prepare their laptops for your workshop (e.g. by installing some software) or if there are other requirements, please note so in your abstract.

 How to submit:
See our check list to ensure that you do not forget to enclose all necessary information. 
Send an abstract (ca. 50-100 words) and all necessary information via email to this address: lac2007 AT robin.kgw.tu-berlin.de 
The abstract will be published on the conference website once the workshop has been accepted (not before 01 March 2007 though). 

 Submission deadline is 05 Feb 2007. 
 You will be notified by 01 March 2007 whether your submission has been accepted. 

-----------------------------
 Call for Tutorials

 New in this edition of the Linux Audio Conference will be a Tutorial track for new users. This Tutorial track will be hosted by the Media Science Department of the Humboldt University of Berlin. Proposals for additions to this Tutorial program are welcome.
 The aim of this Tutorial track is to give new (potential) users an overview of the possibilities of Linux Audio Software and how to get started. The difference to workshops is that the tutorials are given in a lecture environment and should focus on how to make music with Linux, more than going into specifics of certain programs.
 The tutorial track is supported by the LA Pool facility as attendants can try out the software themselves with hands on support.

Send a short description of your proposed Tutorial topic (ca. 50-100 words), via email to this address: lac2007 AT robin.kgw.tu-berlin.de

 Submission deadline is 08 Jan 2007. 
 You will be notified by 05 Feb 2007 whether your submission has been accepted. Criteria will be based upon creating a full fledged Tutorial program for Linux Audio.

-----------------------------
 Call for Music

 The conference will include several concerts. We are looking for music that has been produced completely or mostly under Linux and/or with open source software: 
Serious compositions, Electronica, Chill-Out, Ambient etc. Indicate whether you want to have your piece played in a concert like environment or a club like environment. Additionally you can submit Radio music (see below) and Wave Field Synthesis music (see also below).

 Additionally you are welcome to give a talk about your piece. We encourage you especially to show how you made the piece using open source software. Please send a short abstract (ca. 50-100 words) if you want to give a talk. 

 If you want to participate, send your composition(s) to this address: 

 LAC2007 - Call for Music
 Institute of Communications Research
 Sekretariat EN 8
 Einsteinufer 17
 D-10587 Berlin
 Germany 

 Make use of one of the following media formats: 
Media: Audio-CD, DVD, DVD-R or CD-R 
File formats: aiff or wav 
Channels: mono, stereo, multi-channel and multi-mono (8 channels is no problem, more than 8 must be discussed). 
Samplerate: 44.1 or 48 kHz
Resolution: 16 or 24 bit 
 Include the following items with your submission (in English):
A filled-out and signed printout of the form available here: http://www.kgw.tu-berlin.de/~lac2007/download/musicagreement.pdf
 For the printed program and to be published online and on the conference CD, in continuous text (no table or list please): 
A short commentary on the composition(s) (each ca. 150 words) 
A short Curriculum Vitae (ca. 100 words) 
 Deadline for submissions is 08 Jan 2007. 

 A jury will select the compositions that will be performed/played. Furthermore, the jury will give out three prices to participants to contribute to their travel expenses. 

 Besides artistic criteria and technical reasons, these criteria apply for the selection:
 
Tape pieces or pieces which are performed by the composers themselves will generally have more chances to get included. 
If we get more pieces than we can include in the program, composers who are attending the conference are preferred. 

Terms and conditions for participation can be found in the form mentioned above. This form includes among other things: 
I will receive no fees whether my composition is played or not. 
GEMA fees (in case of performance) will be paid by the organizer. 
The material I send to the TU Berlin will not be returned.

 
Additionally to this Call for Music, during the late night concerts there will be an open stage:

"Plug & Chill - The Linux Jam Nights" 

 where attendants of the conference are invited to perform their pieces in a more club-like context. There is no deadline for this, so people can decide during the conference if they want to participate. 

 However if you already know that you want to participate do not hesitate to inform us. Send us an email to lac2007 AT robin.kgw.tu-berlin.de and include a description of your equipment and a short characterization of your music (keywords only). 

 During the conference it is possible to register at the info desk. Note that there is a time limit for "Plug & Chill". If we have received too many registrations already you might not get a slot. 

 Contributions to "Plug & Chill" should not exceed 10 min. 

 There will be a room at the TU Berlin where people can meet during the conference and rehearse for "Plug & Chill".

-----------------------------
Radio Music

 A new category in the Music call is the call for music that can be used for radio airplay. In cooperation with the Campusradio (http://www.campusradio-online.de) of the TU Berlin, who will do a live report on the conference, we invite composers, musicians and producers of Music made or recorded and mastered with Open Source tools, to submit their works. 

If you want to participate, send an email to: 
lac2007-radio AT robin.kgw.tu-berlin.de
with a link to your audio files.

Alternately, send your music to the address above, with the addition:
 LAC2007 - Call for Music Radio

Make use of one of the following media formats: 
Media: Audio-CD, DVD, DVD-R or CD-R 
File formats: aiff or wav or ogg 
Channels: mono or stereo 
Samplerate: 44.1 or 48 kHz 
Resolution: 16 or 24 bit 

Include the following items with your submission (in English): A filled-out and signed printout of the form available here (sent by mail, or by fax to: +49 30 31421143): http://www.kgw.tu-berlin.de/~lac2007/download/musicagreement.pdf
Deadline for submissions is 05 Feb 2007.

The choice of which pieces are played is in the hands of the Campusradio crew. A program listing will be on their website http://www.campusradio-online.de shortly before the conference. 


-----------------------------

Wave Field Synthesis Music

Shortly before the conference, a new Wave Field Synthesis (WFS) system will be installed in one of the lecture halls of the TU Berlin. We are looking for composers who are interested in creating a composition for this system or who have already written pieces for WFS, which could be played on the system.
The WFS system will be based on the sWONDER software (http://swonder.sourceforge.net), and can be controlled by OSC.
For more information, please contact us at lac2007 AT robin.kgw.tu-berlin.de

As there is no standard format for WFS material yet, we ask for a elaborate description of the piece and some examples of previous works.
To prepare the piece for performance, it will be necessary for the composer to be present a few days before the conference. We will support efforts to get funding for this from external organizations (such as DAAD).

Send your material to this address: 

 LAC2007 - Call for WFS Music
 Institute of Communications Research
 Sekretariat EN 8
 Einsteinufer 17
 D-10587 Berlin
 Germany 

 Make use of one of the following media formats: 

Media: Audio-CD, DVD, DVD-R or CD-R 
File formats: aiff or wav 
Channels: mono, stereo, multi-channel and multi-mono (8 channels is no problem, more than 8 must be discussed). 
Samplerate: 44.1 or 48 kHz
Resolution: 16 or 24 bit 

 Include the following items with your submission (in English):
A filled-out and signed printout of the form available on: http://www.kgw.tu-berlin.de/~lac2007/download/musicagreement.pdf
 For the printed program and to be published online and on the conference CD, in continuous text (no table or list please): 
A short commentary on the composition(s) (each ca. 150 words) 
A short Curriculum Vitae (ca. 100 words) 
 Deadline for submissions is 08 Jan 2007. 

Terms and conditions for participation can be found in the form mentioned above. This form includes among other things: 
I will receive no fees whether my composition is played or not. 
GEMA fees (in case of performance) will be paid by the organizer. 
The material I send to the TU Berlin will not be returned.

From hans at fugal.net  Tue Oct 17 12:49:06 2006
From: hans at fugal.net (Hans Fugal)
Date: Tue Oct 17 12:49:19 2006
Subject: [linux-audio-dev] hearnet improvement
In-Reply-To: <70a871c80610051100m754010a3v51691a279d9002db@mail.gmail.com>
References: <70a871c80610051100m754010a3v51691a279d9002db@mail.gmail.com>
Message-ID: <20061017164906.GA23299@falcon.fugal.net>

I did reply to Dmitry earlier by email, but for posterity, I integrated
his patch and released a new version. I think I posted to the announce
list but I'm not sure if it came through or not. If not, head on over to
http://hans.fugal.net/typo/articles/2006/10/10/hearnet-0-0-9

On Thu,  5 Oct 2006 at 22:00 +0400, Dmitry Baikov wrote:
> Hi!
> First of all, thanks for a great program!
> 
> I made two patches for it:
> 1) make hearnet suid and drop privileges right after libpcap initialization.
> I had to move libpcap init code above jack
> 
> So, you can use hearnet as regular user.
> 
> 2) Mutex in jack_process is a very bad thing. Moreover, it seems
> there's no need for it, as voice->active field serves as a mutex.
> Attached patch removes pthread_mutex.
> If you think voice->active assumption is a weak one, the problem can
> be solved with a pair of jack_ringbuffers: one for free voices and one
> for active.
> 
> 
> Regards,
> 
> Dmitry.




-- 
Hans Fugal ; http://hans.fugal.net
 
There's nothing remarkable about it. All one has to do is hit the 
right keys at the right time and the instrument plays itself.
    -- Johann Sebastian Bach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061017/945fcb75/attachment.bin
From david at olofson.net  Tue Oct 17 12:50:04 2006
From: david at olofson.net (David Olofson)
Date: Tue Oct 17 12:51:52 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017144339.GF5877@linux-1.site>
References: <20061015110514.GA3059@localhost.localdomain>
	<1161093550.17041.62.camel@localhost.localdomain>
	<20061017144339.GF5877@linux-1.site>
Message-ID: <200610171850.04185.david@olofson.net>

On Tuesday 17 October 2006 16:43, Fons Adriaensen wrote:
> On Tue, Oct 17, 2006 at 09:59:10AM -0400, Paul Davis wrote:
> > On Tue, 2006-10-17 at 11:56 +0200, Fons Adriaensen wrote:
> > 
> > > 'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a
> > > signal when converted to the analog domain can be several
> > > dB above that of the highest sample.
> > 
> > indeed. there are people who are coming to believe that
> > this "error" is responsible for a significant part of the audible
> > difference between digital and analog playback when the levels in
> > the source material are high. 
> 
> It could be. OTOH, most DACs today would upsample and filter before
> the real conversion takes place, and could allow for this. But maybe
> they don't, and just clip at that point.

I would consider that a hardware bug - but you never know... If this 
actually does happen, it would certainly cause a great deal of damage 
with the kind of compression applied to most things these days.


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'
From fons.adriaensen at skynet.be  Tue Oct 17 13:08:00 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Tue Oct 17 13:05:55 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <200610171850.04185.david@olofson.net>
References: <20061015110514.GA3059@localhost.localdomain>
	<1161093550.17041.62.camel@localhost.localdomain>
	<20061017144339.GF5877@linux-1.site>
	<200610171850.04185.david@olofson.net>
Message-ID: <20061017170800.GB10663@linux-1.site>

On Tue, Oct 17, 2006 at 06:50:04PM +0200, David Olofson wrote:

> On Tuesday 17 October 2006 16:43, Fons Adriaensen wrote:
>
> > It could be. OTOH, most DACs today would upsample and filter before
> > the real conversion takes place, and could allow for this. But maybe
> > they don't, and just clip at that point.
> 
> I would consider that a hardware bug - but you never know... If this 
> actually does happen, it would certainly cause a great deal of damage 
> with the kind of compression applied to most things these days.

I'd say that the damage is already done by that type of compression.
Squeezing out the latest 0.1 dB of apparent loudness seems to be
the norm these days (much more than say 15 years ago). Nobody gets
any better by this, it only leads to listening fatigue and destroys
most music.

-- 
FA

Lascia la spina, cogli la rosa.

From ladev at sound-man.co.uk  Tue Oct 17 16:31:41 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Tue Oct 17 16:09:12 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
Message-ID: <20061017203141.GA2972@localhost.localdomain>

On Mon, Oct 16, 2006 at 07:48:35PM +0100, Dan Mills wrote:
> Fixing this right means upsampling and adding a
> lowpass filter to the control loop, then downsampling
> again. Anyone have a pointer to the latest version of
> that fast factor of two resampler that was posted here
> kicking around?

Don't have a pointer, but wouldn't a simple linear interpolator
followed by a basic LPF do it fairly cheaply?

John
From dmills_00 at yahoo.co.uk  Tue Oct 17 17:04:20 2006
From: dmills_00 at yahoo.co.uk (Dan Mills)
Date: Tue Oct 17 17:04:30 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017203141.GA2972@localhost.localdomain>
Message-ID: <20061017210420.86843.qmail@web27909.mail.ukl.yahoo.com>


--- John Rigg <ladev@sound-man.co.uk> wrote:
> 
> Don't have a pointer, but wouldn't a simple linear
> interpolator followed by a basic LPF do it fairly
cheaply?
>

It might if we only needed to do the control signal,
but at 44.1, there just is not the bandwidth in either
the control or AUDIO channels to alllow fast gain
changes. Therefore we need to upsample both the audio
and the control data (albiet that the control
upsampler can get away with a lot less bandwidth then
the audio one).

When we hit that multiplier the condition is that the
sum of the audio bandwidth and the control bandwidth
must fit within the nyquest limit, at 44.1 ther just
is nothing like the required bandwidth at this point. 

With both the audio and control bandlimited to 0.25 *
FS, we can safely multiply them, any more then that
(split any way you like) and it all falls apart. 
 
With respect to viewing the attack and decay logic as
a LPF, this is only the case if the same timeconstant
applies to both (seldom the case), as otherwise there
is a discontinuity in the rate of change at the
transition which will itself generate HF splatter. 

It is a thorny problem.

Regards, Dan.
 

Send instant messages to your online friends http://uk.messenger.yahoo.com 
From mle+la at mega-nerd.com  Tue Oct 17 17:16:58 2006
From: mle+la at mega-nerd.com (Erik de Castro Lopo)
Date: Tue Oct 17 17:18:31 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
Message-ID: <20061018071658.c07d1943.mle+la@mega-nerd.com>


Sorry, I'm coming into this late but .....

Dan Mills wrote:

> The gain control signal has energy right the way out
> to the band limit (and probably aliased around it),
> never mind what happens when that hits the multiplier!

You need a low pass filter on the control signal. It should
be somewhere well below 1kHz.
 
> Fixing this right means upsampling and adding a
> lowpass filter to the control loop, then downsampling
> again.

No it doesn't. You want to absolutely avoid fast changes in
the control signal because fast changes will modulate the 
audio signal whcih is **not** desirable.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"The reasonable man adapts himself to the world; the unreasonable
one persists to adapt the world to himself. Therefore all
progress depends on the unreasonable man."
  -- George Bernard Shaw (1856-1950)
From dmills_00 at yahoo.co.uk  Tue Oct 17 17:52:58 2006
From: dmills_00 at yahoo.co.uk (Dan Mills)
Date: Tue Oct 17 17:53:09 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018071658.c07d1943.mle+la@mega-nerd.com>
Message-ID: <20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>


--- Erik de Castro Lopo <mle+la@mega-nerd.com> wrote:

> You need a low pass filter on the control signal. It
> should
> be somewhere well below 1kHz.

Agreed that you need the filter, but a 'brick wall' at
1Khz means that anything faster then 50ms or so as an
attack time (and there are legit uses for such), will
itself overshoot horrribly due to the gibb effect of
bandlimiting the control signal.   

Resampling:

> No it doesn't. You want to absolutely avoid fast
changes in
> the control signal because fast changes will
> modulate the  audio signal whcih is **not**
desirable.

So, how do you implement a fast limiter if the fastest
time constant you can have is greater then 1ms?
Remember that to get to within 10 percent of the
computed gain will take multiple timeconstants.... 

I agree that a 'gain rider' poses no particular
problem at 44.1 or 48K, but even then lowpassing the
audio input to ensure you have the bandwidth to work
in would be a good idea (Think crash cymbal hit). 

However for anything fast (and there are well
respected hardware compressors with attack TCs down to
100us), you need substantially more then 44.1 both in
the sidechain and in the gain cell and that means you
need resampling. 

Regards, Dan.



Send instant messages to your online friends http://uk.messenger.yahoo.com 
From mle+la at mega-nerd.com  Tue Oct 17 18:28:15 2006
From: mle+la at mega-nerd.com (Erik de Castro Lopo)
Date: Tue Oct 17 18:28:28 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
Message-ID: <20061018082815.c9e9ab5c.mle+la@mega-nerd.com>

Dan Mills wrote:

> 
> --- Erik de Castro Lopo <mle+la@mega-nerd.com> wrote:
> 
> > You need a low pass filter on the control signal. It
> > should
> > be somewhere well below 1kHz.
> 
> Agreed that you need the filter, but a 'brick wall' at
> 1Khz means that anything faster then 50ms or so as an
> attack time (and there are legit uses for such), will
> itself overshoot horrribly due to the gibb effect of
> bandlimiting the control signal.

This is the way analogue compressors work. If you have a 
sound with a fast transient going into a slow attack 
compressor, the transient passes throught pretty much
untouched (apart from any clipping that may occur due
to other parts of the design).

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
Failure is not an option. It comes bundled with your Microsoft
product.
From ladev at sound-man.co.uk  Tue Oct 17 19:12:04 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Tue Oct 17 18:49:35 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017210420.86843.qmail@web27909.mail.ukl.yahoo.com>
References: <20061017203141.GA2972@localhost.localdomain>
	<20061017210420.86843.qmail@web27909.mail.ukl.yahoo.com>
Message-ID: <20061017231204.GA3048@localhost.localdomain>

On Tue, Oct 17, 2006 at 10:04:20PM +0100, Dan Mills wrote:
> but at 44.1, there just is not the bandwidth in either
> the control or AUDIO channels to alllow fast gain
> changes. Therefore we need to upsample both the audio
> and the control data (albiet that the control
> upsampler can get away with a lot less bandwidth then
> the audio one).

If the control signal is derived from the upsampled input
to the compressor, that is taken care of.

> ...
> With both the audio and control bandlimited to 0.25 *
> FS, we can safely multiply them, any more then that
> (split any way you like) and it all falls apart. 

Yes; that more or less makes 2x upsampling essential.

> With respect to viewing the attack and decay logic as
> a LPF, this is only the case if the same timeconstant
> applies to both (seldom the case), as otherwise there
> is a discontinuity in the rate of change at the
> transition which will itself generate HF splatter.

Isn't there always a discontinuity here anyway? When it changes from
attack to decay the rate of gain change switches suddenly from
negative to positive. A bandwidth limit on the control signal
should take care of that, as long as the cutoff is steep enough.

John
From pw_lists at slinkp.com  Tue Oct 17 18:59:48 2006
From: pw_lists at slinkp.com (Paul Winkler)
Date: Tue Oct 17 19:00:21 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
Message-ID: <20061017225948.GA9181@slinkp.com>

On Wed, Oct 18, 2006 at 08:28:15AM +1000, Erik de Castro Lopo wrote:
> Dan Mills wrote:
> > --- Erik de Castro Lopo <mle+la@mega-nerd.com> wrote:
> > 
> > > You need a low pass filter on the control signal. It
> > > should
> > > be somewhere well below 1kHz.
> > 
> > Agreed that you need the filter, but a 'brick wall' at
> > 1Khz means that anything faster then 50ms or so as an
> > attack time (and there are legit uses for such), will
> > itself overshoot horrribly due to the gibb effect of
> > bandlimiting the control signal.
> 
> This is the way analogue compressors work. If you have a 
> sound with a fast transient going into a slow attack 
> compressor, the transient passes throught pretty much
> untouched (apart from any clipping that may occur due
> to other parts of the design).

Conversely, I'll just mention that it's possible to get distortion of
low-frequency audio by setting the release time extremely fast, because
the compressor is effectively trying to increase the gain at the end of
every half-cycle.  This is considered a case of giving the engineer
enough rope to hang himself, and hoping that he uses it responsibly. See
http://www.fmraudio.com/FAQ.htm#question4
for more.

-- 

Paul Winkler
http://www.slinkp.com
From ce at christeck.de  Tue Oct 17 19:07:44 2006
From: ce at christeck.de (Christoph Eckert)
Date: Tue Oct 17 19:07:25 2006
Subject: [linux-audio-dev] [ANN] Simple Sysexxer 0.1.1
Message-ID: <200610180107.44232.ce@christeck.de>

Hi all,


first my apologies for cross-posting (TM) :) . This is a wee small 
bugfix release of Simple Sysexxer. It now should build without needing 
Qt debug libs installed.
As I didn't get any feedback since the first release (neither success 
stories nor complaints), I'd like to encourage anyone to send feedback 
or bug reports.

Simple Sysexxer is a tool to exchange sysex data with MIDI devices, e.g. 
to do backups of the device's memory contents or to send presets loaded 
from the web.

Advantages:
* (Hopefully) easy to use graphical user interface
* True ALSA sequencer support
* Built using Qt, no KDE dependency at all
* Minor changes to the source should make it run on Mac OS X or even 
Windows

Disadvantages:
* Requires Qt4 and will *not* build against Qt3
* No JACK MIDI support :)
* No OSS support
* No prebuilt binaries available

Information and source download:
http://www.christeck.de

Enjoy,

ce
From dmills_00 at yahoo.co.uk  Tue Oct 17 19:48:59 2006
From: dmills_00 at yahoo.co.uk (Dan Mills)
Date: Tue Oct 17 19:51:01 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017231204.GA3048@localhost.localdomain>
Message-ID: <20061017234859.54697.qmail@web27909.mail.ukl.yahoo.com>


--- John Rigg <ladev@sound-man.co.uk> wrote:

> If the control signal is derived from the upsampled
> input
> to the compressor, that is taken care of.

But that puts potentially expensive gain calculations
into the fast sr code, also I was rather planning on
using the impulse used for the upsampler to provide
the band limiting for free.
 
> > ...
> > With both the audio and control bandlimited to
> >0.25 * FS, we can safely multiply them, any more
then
> >that (split any way you like) and it all falls
apart. 
> 
> Yes; that more or less makes 2x upsampling
> essential.

True as far as I can see, and there is a sting in the
tail - you cannot just upsample at the input to
something like jamin and have done with it, you would
have to band limit between each stage as otherwise the
HF crud from the first stage will just get aliased in
the second!
 
BEAST was the project that had the SSE 2* up/down
sampler code that seems to be reasonably quick. 

> Isn't there always a discontinuity here anyway? When
> it changes fromattack to decay the rate of gain
change switches
> suddenly from negative to positive. A bandwidth
limit on the
> control signal should take care of that, as long as
the cutoff is
> steep enough.

True when I think about it. 

That is why I am trying to do the upsampling **JUST**
before the gain multiplication, so that the upsampler
also provides the band limiting.

The downside (Apart from the CPU load) is the need to
add a Latency port to things that would not otherwise
need one. 

I might (depending on how manic work gets) have
something based on SC4 using libsamplerate by the
weekend. 
I doubt that libsamplerate is the correct tool for
this however, we don't need the features and given we
know the ratio is 2, we can gain some serious speedups
with vector optimisations. 

Would an 'Aliasing free gain cell' library be of
interest to anyone? The idea would be that it could be
dropped in place of the whole 

output = gain * sample;

thing and would handle upsampling gain and sample
arrays, multiplying them and downsampling the result. 


This would potentially make fixing a LOT of the LADSPA
dynamics much easier and would be one place to bugfix
rather then scattering that pain all over the place.

The API is likely to be 'interesting' as most dynamics
plugs don't generate an array of gain values then
apply them, and a single sample streaming resampler
doesn't bear thinking about. 

Regards, Dan. 






Send instant messages to your online friends http://uk.messenger.yahoo.com 
From jens.andreasen at chello.se  Wed Oct 18 01:23:12 2006
From: jens.andreasen at chello.se (Jens M Andreasen)
Date: Wed Oct 18 01:23:23 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
Message-ID: <1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>

On Wed, 2006-10-18 at 08:28 +1000, Erik de Castro Lopo wrote:
> Dan Mills wrote:
> 
> > 
> > --- Erik de Castro Lopo <mle+la@mega-nerd.com> wrote:
> > 
> > > You need a low pass filter on the control signal. It
> > > should
> > > be somewhere well below 1kHz.
> > 
> > Agreed that you need the filter, but a 'brick wall' at
> > 1Khz means that anything faster then 50ms or so as an
> > attack time (and there are legit uses for such), will
> > itself overshoot horrribly due to the gibb effect of
> > bandlimiting the control signal.
> 
> This is the way analogue compressors work. If you have a 
> sound with a fast transient going into a slow attack 
> compressor, the transient passes throught pretty much
> untouched (apart from any clipping that may occur due
> to other parts of the design).
> 
The clipping of the signal could be designed to sound resonably good by
having the area around zero to be linear, but as you get closer to the
extremes, the response curve bends inwards, fitting a virtual headroom
of say 36 dB into only 12 dB of the mastered 16bit signal. Overdrive I
think is the proper name?

A sine wave transient too fast for the compressor to handle immediately
would then start out as a square with gentle rounded corners instead of
a square with a flat-roof haircut. The distribution of the added
frequencies is thus moved to lower octaves where the distortion is less
dangerous/disturbing.

An improvement could then be to apply a 2 dB/oct high-pass before the
overdrive circuit followed by the inverse after the circuit, emphasizing
the effect on the faster transients and leaving deep sine waves to use
the full dynamic range unaltered, without distortion. This would also be
an approximation of magnetic tape dynamic response.

50 ms still appears like a long time. Was there a technical reason not
to go down to around 20 ms to reach the psychological sense of
"simultaniously"? 
Or perhaps 50 ms is a good value? Something very dramatic obviously
happened in the signal when the compressor kicked in, so moving the
"drama" from dynamics into short bursts of distortion  might actually
help in preserving a sense of "naturalness."




> Erik
-- 

From ladev at sound-man.co.uk  Wed Oct 18 04:44:57 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Wed Oct 18 04:22:29 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
	<1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
Message-ID: <20061018084457.GA2695@localhost.localdomain>

On Wed, Oct 18, 2006 at 07:23:12AM +0200, Jens M Andreasen wrote:
> A sine wave transient too fast for the compressor to handle immediately
> would then start out as a square with gentle rounded corners instead of
> a square with a flat-roof haircut. The distribution of the added
> frequencies is thus moved to lower octaves where the distortion is less
> dangerous/disturbing.

Soft clipping always sounds better than hard clipping, and there are
analog compressors that behave like this. Unfortunately even a soft
clipper generates significant harmonic distortion, largely 3rd and 5th.
The 3rd harmonic alone potentially increases the signal bandwidth by
three times, and aliasing will occur if the sample frequency isn't
high enough to accommodate all harmonics that have an amplitude greater
than the noise floor (below that it doesn't matter).

John
From mle+la at mega-nerd.com  Wed Oct 18 04:50:39 2006
From: mle+la at mega-nerd.com (Erik de Castro Lopo)
Date: Wed Oct 18 04:50:58 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018084457.GA2695@localhost.localdomain>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
	<1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
	<20061018084457.GA2695@localhost.localdomain>
Message-ID: <20061018185039.3611aa9b.mle+la@mega-nerd.com>

John Rigg wrote:

> Soft clipping always sounds better than hard clipping, and there are
> analog compressors that behave like this. Unfortunately even a soft
> clipper generates significant harmonic distortion, largely 3rd and 5th.

But this should only be happening on transients and the clipping
should stop as soon as the attack portion of the compression
process kicks in.

Most instruments with fast transients usually *already* have a high
levels of higher harmonics (and inharmonics) that die away far more 
quickly than the lower harmonics.

> The 3rd harmonic alone potentially increases the signal bandwidth by
> three times

Ok, lets say we're sampling at 44.1kHz, which makes the highest
3rd harmonic we can represent is 22.0/3 kHz which is about 7kHz.
Do you really listen to many instruments where the fundamental
is at 7kHz?????

> and aliasing will occur if the sample frequency isn't
> high enough to accommodate all harmonics

These higher harmonics will be transitory. As soon as the attack
portion of the compressor's action is over they're gone. In 
addition, any aliasing that does occur will be almost indistinguishable
from the inharmonics frequencies already in transient part of the 
sound.

I say again, nearly all instruments with very fast transients have
a high number of inharmonics frequencuies that die off almost 
immediately. For instance, think of instruments like acoustic guitars
and pianos.

Its very easy to get carried away with trying to reach some sort
of audio perfection. Things like upsampling in order to apply 
compression is over-engineering.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Attacks by Microsoft Chairman Bill Gates on the GNU General
Public License, under which much open source and free software is
distributed, have been driven by a fear that the GPL creates a
domain of software that Microsoft cannot privatize and control"
   -- Richard Stallman
From S.W.Harris at ecs.soton.ac.uk  Wed Oct 18 05:45:02 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Wed Oct 18 05:46:16 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017125340.GA2617@localhost.localdomain>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
	<20061017095620.GC5877@linux-1.site>
	<20061017125340.GA2617@localhost.localdomain>
Message-ID: <20061018094502.GA6398@login.ecs.soton.ac.uk>

On Tue, Oct 17, 2006 at 01:53:40 +0100, John Rigg wrote:
> On Tue, Oct 17, 2006 at 11:56:20AM +0200, Fons Adriaensen wrote:
> > On Mon, Oct 16, 2006 at 07:48:35PM +0100, Dan Mills wrote:
> > > The gain control signal has energy right the way out
> > > to the band limit (and probably aliased around it),
> > > never mind what happens when that hits the multiplier!
> > 
> > The question is: how much of this HF energy is there ?
> > There shouldn't be much in a compressor with controlled
> > attack / release times. In that case it is always possible
> > to filter the control signal. In fact the obvious way to set
> > attack / release times is by such filtering !
> 
> True, but if the audio signal contains significant HF energy near
> the band limit, it doesn't take a very fast gain change to push it
> past that. Bear in mind that the ear is _very_ sensitive to aliasing
> artifacts, so `significant' can be a very small amount.

These are aliasing artifacts in the sidechain though, right? So they will
show up as modulations in the output, rather than directly audible
aliasing.

- Steve
From S.W.Harris at ecs.soton.ac.uk  Wed Oct 18 05:47:43 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Wed Oct 18 05:48:40 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017144339.GF5877@linux-1.site>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
	<20061017095620.GC5877@linux-1.site>
	<1161093550.17041.62.camel@localhost.localdomain>
	<20061017144339.GF5877@linux-1.site>
Message-ID: <20061018094743.GB6398@login.ecs.soton.ac.uk>

On Tue, Oct 17, 2006 at 04:43:39 +0200, Fons Adriaensen wrote:
> On Tue, Oct 17, 2006 at 09:59:10AM -0400, Paul Davis wrote:
> > On Tue, 2006-10-17 at 11:56 +0200, Fons Adriaensen wrote:
> > 
> > > 'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a
> > > signal when converted to the analog domain can be several
> > > dB above that of the highest sample.
> > 
> > indeed. there are people who are coming to believe that this "error" is
> > responsible for a significant part of the audible difference between
> > digital and analog playback when the levels in the source material are
> > high. 
> 
> It could be. OTOH, most DACs today would upsample and filter before the
> real conversion takes place, and could allow for this. But maybe they
> don't, and just clip at that point.

I've actually measured this with an oscilloscope (because I'm that sad,
and to settle an argument), and at least the DA converters I tested did
respect the fact that the peak voltage was obove the INT_MAX voltage level.

It was a few years ago, so I cant remember what I tested, but one thing
was a yamaha digital desk.

- Steve
From S.W.Harris at ecs.soton.ac.uk  Wed Oct 18 05:54:54 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Wed Oct 18 05:55:31 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061017234859.54697.qmail@web27909.mail.ukl.yahoo.com>
References: <20061017231204.GA3048@localhost.localdomain>
	<20061017234859.54697.qmail@web27909.mail.ukl.yahoo.com>
Message-ID: <20061018095453.GC6398@login.ecs.soton.ac.uk>

On Wed, Oct 18, 2006 at 12:48:59 +0100, Dan Mills wrote:
> 
> --- John Rigg <ladev@sound-man.co.uk> wrote:
> 
> > If the control signal is derived from the upsampled
> > input
> > to the compressor, that is taken care of.
> 
> But that puts potentially expensive gain calculations
> into the fast sr code, also I was rather planning on
> using the impulse used for the upsampler to provide
> the band limiting for free.

the gain calculations are relativly cheap, its converting those gain
levels back into a gain coefficient on the output that's expensive (from
what I remember).

the gain tracking is done per sample, but the cofficient calcualtion is
done every 4.

> BEAST was the project that had the SSE 2* up/down
> sampler code that seems to be reasonably quick. 

But what interpolation function? If you something obvious and cheap you
may as well not bother, as you wont get accurate peak interpolation.

> The API is likely to be 'interesting' as most dynamics
> plugs don't generate an array of gain values then
> apply them, and a single sample streaming resampler
> doesn't bear thinking about. 

I dont think a streaming resampler is more challenging than a correct one
that runs on buffers. You just have to preserve state with every call,
rather than at the buffer boundaries.

- Steve
From dmills_00 at yahoo.co.uk  Wed Oct 18 06:02:26 2006
From: dmills_00 at yahoo.co.uk (Dan Mills)
Date: Wed Oct 18 06:02:35 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018094502.GA6398@login.ecs.soton.ac.uk>
Message-ID: <20061018100226.20873.qmail@web27902.mail.ukl.yahoo.com>


--- Steve Harris <S.W.Harris@ecs.soton.ac.uk> wrote:
 
> These are aliasing artifacts in the sidechain
> though, right? So they will
> show up as modulations in the output, rather than
> directly audible
> aliasing.

The last thing almost all software compressors do is
something of the form output = gain * sample; 

If either gain or sample contain aliasing, or if the
sum of their bandwidths would cause aliasing then
there will be aliasing present at the output. 

To an extent what happens earlier is in the sidechain
is less important as long as the last condition can be
met at the 'gain cell'.

Audio_bw + Gain_bw must be < 0.5 * SR at the gain
control multiplier. 

To address Erics point, in a slow 'gain riding'
compressor your point is valid, but this fails for
things like fast limiters or even for something like
an emulation of an SSL Mix bus comp, which has some
seriously fast attacks available. 

Further, it is not the instruments fundamental that is
the problem, as energy in the harmonics  will also get
aliased quite happily (And the aliasing products are
non harmonically related). 

I am going to code it up, we will see what happens
when we have something measurable (and listenable). 


Regards, Dan.

Send instant messages to your online friends http://uk.messenger.yahoo.com 
From yosvanyllr at gmail.com  Wed Oct 18 06:04:32 2006
From: yosvanyllr at gmail.com (=?ISO-8859-1?Q?Yosvany_Llerena_Rodr=EDguez?=)
Date: Wed Oct 18 06:04:40 2006
Subject: [linux-audio-dev] unsubcribe
Message-ID: <dfdb6df00610180304i2e6f59cco71f90e94fc00fc17@mail.gmail.com>


From dmills_00 at yahoo.co.uk  Wed Oct 18 06:12:32 2006
From: dmills_00 at yahoo.co.uk (Dan Mills)
Date: Wed Oct 18 06:12:48 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018095453.GC6398@login.ecs.soton.ac.uk>
Message-ID: <20061018101232.51535.qmail@web27915.mail.ukl.yahoo.com>


--- Steve Harris <S.W.Harris@ecs.soton.ac.uk> wrote:

> > But that puts potentially expensive gain
> > calculations into the fast sr code, also I was
rather planning
> > on using the impulse used for the upsampler to
> >provide the band limiting for free.
> 
> the gain calculations are relativly cheap, its
> converting those gain
> levels back into a gain coefficient on the output
> that's expensive (from
> what I remember).

But all that can still be done at 44.1/48, it is only
the final sample multiplication that needs its inputs
band limited and thus potentially needs the upsampler.
 

> > BEAST was the project that had the SSE 2* up/down
> > sampler code that seems to be reasonably quick. 
> 
> But what interpolation function? If you something
> obvious and cheap you
> may as well not bother, as you wont get accurate
> peak interpolation.

The usual half band impulse convolution based
approach. 

> I dont think a streaming resampler is more
> challenging than a correct one
> that runs on buffers. You just have to preserve
> state with every call,
> rather than at the buffer boundaries.

But that breaks the ability to use the vectorisation
capability of modern compilers and  besides the call
and return overhead will end up costing as much as the
convolution!

We seem to be discussing two separate problems here,
aliasing in the gain cell and real 'audio' peak
discovery, they are peripherally related byt are not
the same thing. 

Regards Dan (Who really now has to go and do some work).

Send instant messages to your online friends http://uk.messenger.yahoo.com 
From S.W.Harris at ecs.soton.ac.uk  Wed Oct 18 06:42:20 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Wed Oct 18 06:42:52 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018185039.3611aa9b.mle+la@mega-nerd.com>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
	<1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
	<20061018084457.GA2695@localhost.localdomain>
	<20061018185039.3611aa9b.mle+la@mega-nerd.com>
Message-ID: <20061018104220.GD6398@login.ecs.soton.ac.uk>

On Wed, Oct 18, 2006 at 06:50:39 +1000, Erik de Castro Lopo wrote:
> Its very easy to get carried away with trying to reach some sort
> of audio perfection. Things like upsampling in order to apply 
> compression is over-engineering.

I'm tempted to agree. Particualrly the interpediate peak thing, if the
compressors gain slope is appropriatly shallow then the output waveform
will still have the intermediate peak in it. If your DA converter is
broken, you can't really fix that up in software.

According to a collegue, there was a study of consumer hardware DACs for
this behaviour, and there was a mix of results, some reconstruct the
correct curve, some produce an over, but not correct curve and some clip.
>From what he can remember it mostly depended on the manufacturer.

- Steve
From ladev at sound-man.co.uk  Wed Oct 18 07:14:45 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Wed Oct 18 06:53:03 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018185039.3611aa9b.mle+la@mega-nerd.com>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
	<1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
	<20061018084457.GA2695@localhost.localdomain>
	<20061018185039.3611aa9b.mle+la@mega-nerd.com>
Message-ID: <20061018111445.GA3016@localhost.localdomain>

On Wed, Oct 18, 2006 at 06:50:39PM +1000, Erik de Castro Lopo wrote:
> John Rigg wrote:
> 
> > Soft clipping always sounds better than hard clipping, and there are
> > analog compressors that behave like this. Unfortunately even a soft
> > clipper generates significant harmonic distortion, largely 3rd and 5th.
> 
> But this should only be happening on transients and the clipping
> should stop as soon as the attack portion of the compression
> process kicks in.

Yes but my point is that the resulting aliasing sounds worse than the
harmonic distortion.

> Most instruments with fast transients usually *already* have a high
> levels of higher harmonics (and inharmonics) that die away far more 
> quickly than the lower harmonics.

True, but those are removed by the anti-aliasing filters in
the ADCs. The problem here is harmonics generated _inside_ the digital
domain. Once they're generated it's too late to filter them out, as
the aliasing has already occurred.

> > The 3rd harmonic alone potentially increases the signal bandwidth by
> > three times
> 
> Ok, lets say we're sampling at 44.1kHz, which makes the highest
> 3rd harmonic we can represent is 22.0/3 kHz which is about 7kHz.
> Do you really listen to many instruments where the fundamental
> is at 7kHz?????

A lead guitarist will often deliberately play a harmonic `squeal'
in a lead solo (particularly in rock and metal). As a guitarist myself,
I fairly frequently generate fundamentals of around 4 kHz. Deliberate
use of higher frequencies than that might not be very common, but
the equipment should at least deal with it gracefully.

The fact remains that a lot of high end professional users consider many
of the free software plugins to be "nearly unusable" (see Ben Loftis'
earlier post in this thread). This isn't intended as a criticism of the
developers, just an acknowledgement that perhaps more attention needs to be
paid to some fairly subtle aspects of design that have not been
considered important up to now, if these high end users are to take
Linux audio more seriously.

John
From S.W.Harris at ecs.soton.ac.uk  Wed Oct 18 06:53:49 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Wed Oct 18 06:55:09 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018100226.20873.qmail@web27902.mail.ukl.yahoo.com>
References: <20061018094502.GA6398@login.ecs.soton.ac.uk>
	<20061018100226.20873.qmail@web27902.mail.ukl.yahoo.com>
Message-ID: <20061018105349.GF6398@login.ecs.soton.ac.uk>

On Wed, Oct 18, 2006 at 11:02:26 +0100, Dan Mills wrote:
> 
> --- Steve Harris <S.W.Harris@ecs.soton.ac.uk> wrote:
>  
> > These are aliasing artifacts in the sidechain
> > though, right? So they will
> > show up as modulations in the output, rather than
> > directly audible
> > aliasing.
> 
> The last thing almost all software compressors do is
> something of the form output = gain * sample; 

It's not quite that simple. But broadly, yes, that's why I said it would
be modulated by the product of the alising. Gain is in the range (0,1] so
it will be amplitude modulated.

The alising is present in the sidechain, right? So a filterted version of
the alising will be present in the output of the gain stage.

- Steve 
From S.W.Harris at ecs.soton.ac.uk  Wed Oct 18 06:57:52 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Wed Oct 18 06:58:43 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018101232.51535.qmail@web27915.mail.ukl.yahoo.com>
References: <20061018095453.GC6398@login.ecs.soton.ac.uk>
	<20061018101232.51535.qmail@web27915.mail.ukl.yahoo.com>
Message-ID: <20061018105752.GG6398@login.ecs.soton.ac.uk>

On Wed, Oct 18, 2006 at 11:12:32 +0100, Dan Mills wrote:
> 
> --- Steve Harris <S.W.Harris@ecs.soton.ac.uk> wrote:
> 
> > > But that puts potentially expensive gain
> > > calculations into the fast sr code, also I was
> rather planning
> > > on using the impulse used for the upsampler to
> > >provide the band limiting for free.
> > 
> > the gain calculations are relativly cheap, its
> > converting those gain
> > levels back into a gain coefficient on the output
> > that's expensive (from
> > what I remember).
> 
> But all that can still be done at 44.1/48, it is only
> the final sample multiplication that needs its inputs
> band limited and thus potentially needs the upsampler.

It's not that simple. The gain coefficient is not calculated for every
sample.

> > I dont think a streaming resampler is more
> > challenging than a correct one
> > that runs on buffers. You just have to preserve
> > state with every call,
> > rather than at the buffer boundaries.
> 
> But that breaks the ability to use the vectorisation
> capability of modern compilers and  besides the call
> and return overhead will end up costing as much as the
> convolution!

The vectorisation point is right, but the call and return is taken care of
by inlining in modern compilers, it's quite cheap.

- Steve 
From S.W.Harris at ecs.soton.ac.uk  Wed Oct 18 07:08:09 2006
From: S.W.Harris at ecs.soton.ac.uk (Steve Harris)
Date: Wed Oct 18 07:08:32 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018111445.GA3016@localhost.localdomain>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
	<1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
	<20061018084457.GA2695@localhost.localdomain>
	<20061018185039.3611aa9b.mle+la@mega-nerd.com>
	<20061018111445.GA3016@localhost.localdomain>
Message-ID: <20061018110809.GH6398@login.ecs.soton.ac.uk>

On Wed, Oct 18, 2006 at 12:14:45 +0100, John Rigg wrote:
> The fact remains that a lot of high end professional users consider many
> of the free software plugins to be "nearly unusable" (see Ben Loftis'
> earlier post in this thread). This isn't intended as a criticism of the
> developers, just an acknowledgement that perhaps more attention needs to be
> paid to some fairly subtle aspects of design that have not been
> considered important up to now, if these high end users are to take
> Linux audio more seriously.

I don't doubt that, (though some professionals are using them in thier
day-to-day jobs) but I think there are more serious tuning issues to be
addressed than these.

E.g. the gain recovery shape in the SC* compressors is all wrong, the
attack is a bit too gentle and the decay is much to quick to decay. This
makes them sound a bit inert, which is fine for clinical AGC, but not good
for the classic compressor effect in musical applications.

Getting the tuning to the level it's at now, with relatively little feedback
effects between the followers and gain curves took me a couple of days, so
it's no simple job to go in and change things. If at some point in the
future I'm not working 14 hour days and I can take a couple of days off I
might feel up to it. It's been on my TODO list for a few years.

- Steve
From mle+la at mega-nerd.com  Wed Oct 18 07:20:57 2006
From: mle+la at mega-nerd.com (Erik de Castro Lopo)
Date: Wed Oct 18 07:21:07 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018111445.GA3016@localhost.localdomain>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
	<1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
	<20061018084457.GA2695@localhost.localdomain>
	<20061018185039.3611aa9b.mle+la@mega-nerd.com>
	<20061018111445.GA3016@localhost.localdomain>
Message-ID: <20061018212057.cd8f87c9.mle+la@mega-nerd.com>

John Rigg wrote:

> On Wed, Oct 18, 2006 at 06:50:39PM +1000, Erik de Castro Lopo wrote:
>
> > But this should only be happening on transients and the clipping
> > should stop as soon as the attack portion of the compression
> > process kicks in.
> 
> Yes but my point is that the resulting aliasing sounds worse than the
> harmonic distortion.

The aliasing is present for 10s of milliseconds. It blurs into the 
instrument attack. Have a look at the attack transient of an acoustic
guitar or a piano. There a bunch of stuff in the first 30 odd 
milliseconds that bears no relationship with the fundamental note
frequencey.

> True, but those are removed by the anti-aliasing filters in
> the ADCs.

I talking about the stuff below half the sample rate.

> > Ok, lets say we're sampling at 44.1kHz, which makes the highest
> > 3rd harmonic we can represent is 22.0/3 kHz which is about 7kHz.
> > Do you really listen to many instruments where the fundamental
> > is at 7kHz?????
> 
> A lead guitarist will often deliberately play a harmonic `squeal'
> in a lead solo (particularly in rock and metal). As a guitarist myself,
> I fairly frequently generate fundamentals of around 4 kHz.

Thats a bit less than an octave below what I'm talking about.

> Deliberate
> use of higher frequencies than that might not be very common, but
> the equipment should at least deal with it gracefully.

I agree completely.

> The fact remains that a lot of high end professional users consider many
> of the free software plugins to be "nearly unusable" (see Ben Loftis'
> earlier post in this thread).

I have no problem whatsoever with the possibility that all current free
software compressors are poorly implemented, but that doesn't prove that
its not possible to implement a good compressor without upsampling.

All the best and most famous compressors were implemented using flawed
1960s and 1970s technology. The Joe Meek compressor uses light depend 
resistors!!!! In order to make a good digital compressor, we need to 
remember that a compressor is lo-tech. Any benchmark DSP implementation 
should also be relatively lo-tech. Once you have a good working lo-tech
DSP implementation then you can start looking to improve it using 
whatever far out DSP techniques you can think of.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Indeed, I am impressed that Google runs an 8,000 node Linux
cluster, 5 data centers, an extensive network, and a rapidly
evolving application all with a staff of 12."
  -- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc
From fons.adriaensen at skynet.be  Wed Oct 18 07:35:26 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Wed Oct 18 07:33:29 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018185039.3611aa9b.mle+la@mega-nerd.com>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
	<1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
	<20061018084457.GA2695@localhost.localdomain>
	<20061018185039.3611aa9b.mle+la@mega-nerd.com>
Message-ID: <20061018113526.GB5950@linux-1.site>

On Wed, Oct 18, 2006 at 06:50:39PM +1000, Erik de Castro Lopo wrote:

> ...
> Its very easy to get carried away with trying to reach some sort
> of audio perfection. Things like upsampling in order to apply 
> compression is over-engineering.

I'd agree. This is a non-problem for a well-designed and properly
used compressor. The only area where it may matter is for heavy
peak limiting with both a very fast attack _and_ release. But if
you do that you already accept to mangle the original sound.


-- 
FA

Lascia la spina, cogli la rosa.

From ladev at sound-man.co.uk  Wed Oct 18 08:24:55 2006
From: ladev at sound-man.co.uk (John Rigg)
Date: Wed Oct 18 08:02:58 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018094502.GA6398@login.ecs.soton.ac.uk>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
	<20061017095620.GC5877@linux-1.site>
	<20061017125340.GA2617@localhost.localdomain>
	<20061018094502.GA6398@login.ecs.soton.ac.uk>
Message-ID: <20061018122455.GA3125@localhost.localdomain>

On Wed, Oct 18, 2006 at 10:45:02AM +0100, Steve Harris wrote:
> > True, but if the audio signal contains significant HF energy near
> > the band limit, it doesn't take a very fast gain change to push it
> > past that. Bear in mind that the ear is _very_ sensitive to aliasing
> > artifacts, so `significant' can be a very small amount.
> 
> These are aliasing artifacts in the sidechain though, right? So they will
> show up as modulations in the output, rather than directly audible
> aliasing.

I was referring to aliasing in the compressed audio. Harmonic distortion
is introduced during the attack (and decay, but usually to a lesser extent
because it's slower).

Consider a sine wave audio input. In the attack, the gain is decreasing,
so the rising parts of each input half-cycle are reduced in slope, and
the falling parts are increased in slope. The audio waveform starts to take
on a sawtooth shape if the rate of gain change is high enough.

This is a form of harmonic distortion and happens with any compressor,
analog or digital. In a digital compressor aliasing will occur if the sample
frequency is insufficient to deal with the introduced harmonics (which
have been added _inside_ the digital domain remember, so no amount
of anti-aliasing filtering on an input ADC will have any effect on it).
It will only last for the duration of the attack/decay, but that doesn't
make it inaudible. A small amount of harmonic distortion on its own is not
objectionable, but when it is accompanied by aliasing it's bad news.

John
From pieterp at joow.be  Wed Oct 18 09:59:46 2006
From: pieterp at joow.be (Pieter Palmers)
Date: Wed Oct 18 09:58:53 2006
Subject: [linux-audio-dev] [ANN] FreeBoB 1.0 released - Firewire Audio for
	Linux
Message-ID: <45363352.5050705@joow.be>

Greetings,

Now that JACK 0.102.20 and QJackCtl 0.2.21 being released, the FreeBoB 
team is proud to present libfreebob 1.0. The FreeBoB project aims to 
provide a generic solution for using Firewire (semi-)pro-audio devices 
in Linux.

This release provides support for the devices based on the BridgeCo 
DM1000 or DM1500 chipset that are running the BeBoB firmware. For a list 
of supported devices, consult our website at freebob.sf.net.

FreeBoB currently provides an interface library that allows firewire 
audio devices to be used with the JACK audio server, using a dedicated 
backend. This backend is included in the official JACK releases, from 
this version on (i.e. 0.102.20). The latest version of QJackCtl also 
includes support for this FreeBoB backend. MIDI support is provided 
through ALSA sequencer.

Feature list:
* Automatic detection & configuration of devices. If there are multiple 
devices attached to the same firewire bus, freebob merges them into one 
big device. The devices have to be synced externally (wordclock/spdif) 
so that they don't drift. Note that this release cannot setup the boxes 
to be synced yet, being synced is a precondition at the moment. (I 
tested this with 2 phase88's connected with wordclock, and this works 
without the need for any special setting because the Phase88 
automatically chooses wordclock slave when there is a wordclock signal 
present. This can be different for other models).
* Audio I/O on all analog channels at all sample rates supported by the 
device. SPDIF/ADAT I/O works in most cases (when presented as analog IO 
by the device). AC3 passthrough doesn't work.
* Midi I/O for all midi ports the device implements, using alsa-sequencer
* Round-trip latency figures around 5ms (depends on system 
configuration). 10ms is achievable on all well-configured machines

Not supported yet:
* Hardware mixing ("zero latency" mixer)
* Device-specific configuration (input gain switches, sync source 
selection, midi control mappings, ...)
* ALSA for audio IO
* Special SPDIF/ADAT stream support

You can download FreeBoB 1.0 at our sourceforge page:
http://sourceforge.net/project/showfiles.php?group_id=117802
more info at freebob.sf.net

What's next?

We are working on the second generation of the FreeBoB codebase. The 1.0 
release is the endpoint for the codebase that dates back to the start of 
the project. The 2.0 codebase is a complete redesign of the system using 
1.0 as a 'golden spec'. While the 1.0 version is BeBoB-only, the 2.0 
codebase is designed as a framework to support all firewire based audio 
boxes. The current level of functionality is almost the same for both 
codebases. The main difference is that 1.0 had one year of testing and 
2.0 doesn't, it's still in the alpha stage. Needless to say that 2.0 
will outperform 1.0 by far ;).

Of course this redesign isn't for the sake of aesthetic beauty or lack 
of things to do... I can announce that we are already working on 
broadening the supported device list. Currently there is support for the 
Motu Traveller and the Motu 828 (through reverse engineering). There are 
also contacts with the DICE-II developers to implement generic support 
for devices based upon their chipset. As an extra, support for Metric 
Halo devices is also in the pipeline. Once all of these devices are 
supported, we will cover a very large part of the Firewire audio device 
spectrum. The most important void will be RME Fireface support, and for 
the real budget users: Behringer and Hercules devices.

That's all folks!

Pieter Palmers
(on behalf of the FreeBoB team)

From krampenschiesser at freenet.de  Wed Oct 18 11:19:04 2006
From: krampenschiesser at freenet.de (krampenschiesser@freenet.de)
Date: Wed Oct 18 10:17:55 2006
Subject: [linux-audio-dev] unsubcribe
In-Reply-To: <dfdb6df00610180304i2e6f59cco71f90e94fc00fc17@mail.gmail.com>
References: <dfdb6df00610180304i2e6f59cco71f90e94fc00fc17@mail.gmail.com>
Message-ID: <20061018171904.cc7af105.krampenschiesser@freenet.de>

goodbye!
From paniq at paniq.org  Wed Oct 18 10:29:41 2006
From: paniq at paniq.org (Leonard "paniq" Ritter)
Date: Wed Oct 18 10:30:04 2006
Subject: [linux-audio-dev] Re: [Freebob-devel] [ANN] FreeBoB 1.0 released -
	Firewire Audio for Linux
In-Reply-To: <45363352.5050705@joow.be>
References: <45363352.5050705@joow.be>
Message-ID: <1161181781.5475.3.camel@localhost>

congratulations, good work!

looking forward to the alsa side of things :)

On Wed, 2006-10-18 at 15:59 +0200, Pieter Palmers wrote:
> Greetings,
> 
> Now that JACK 0.102.20 and QJackCtl 0.2.21 being released, the FreeBoB 
> team is proud to present libfreebob 1.0. The FreeBoB project aims to 
> provide a generic solution for using Firewire (semi-)pro-audio devices 
> in Linux.
> 
> This release provides support for the devices based on the BridgeCo 
> DM1000 or DM1500 chipset that are running the BeBoB firmware. For a list 
> of supported devices, consult our website at freebob.sf.net.
> 
> FreeBoB currently provides an interface library that allows firewire 
> audio devices to be used with the JACK audio server, using a dedicated 
> backend. This backend is included in the official JACK releases, from 
> this version on (i.e. 0.102.20). The latest version of QJackCtl also 
> includes support for this FreeBoB backend. MIDI support is provided 
> through ALSA sequencer.
> 
> Feature list:
> * Automatic detection & configuration of devices. If there are multiple 
> devices attached to the same firewire bus, freebob merges them into one 
> big device. The devices have to be synced externally (wordclock/spdif) 
> so that they don't drift. Note that this release cannot setup the boxes 
> to be synced yet, being synced is a precondition at the moment. (I 
> tested this with 2 phase88's connected with wordclock, and this works 
> without the need for any special setting because the Phase88 
> automatically chooses wordclock slave when there is a wordclock signal 
> present. This can be different for other models).
> * Audio I/O on all analog channels at all sample rates supported by the 
> device. SPDIF/ADAT I/O works in most cases (when presented as analog IO 
> by the device). AC3 passthrough doesn't work.
> * Midi I/O for all midi ports the device implements, using alsa-sequencer
> * Round-trip latency figures around 5ms (depends on system 
> configuration). 10ms is achievable on all well-configured machines
> 
> Not supported yet:
> * Hardware mixing ("zero latency" mixer)
> * Device-specific configuration (input gain switches, sync source 
> selection, midi control mappings, ...)
> * ALSA for audio IO
> * Special SPDIF/ADAT stream support
> 
> You can download FreeBoB 1.0 at our sourceforge page:
> http://sourceforge.net/project/showfiles.php?group_id=117802
> more info at freebob.sf.net
> 
> What's next?
> 
> We are working on the second generation of the FreeBoB codebase. The 1.0 
> release is the endpoint for the codebase that dates back to the start of 
> the project. The 2.0 codebase is a complete redesign of the system using 
> 1.0 as a 'golden spec'. While the 1.0 version is BeBoB-only, the 2.0 
> codebase is designed as a framework to support all firewire based audio 
> boxes. The current level of functionality is almost the same for both 
> codebases. The main difference is that 1.0 had one year of testing and 
> 2.0 doesn't, it's still in the alpha stage. Needless to say that 2.0 
> will outperform 1.0 by far ;).
> 
> Of course this redesign isn't for the sake of aesthetic beauty or lack 
> of things to do... I can announce that we are already working on 
> broadening the supported device list. Currently there is support for the 
> Motu Traveller and the Motu 828 (through reverse engineering). There are 
> also contacts with the DICE-II developers to implement generic support 
> for devices based upon their chipset. As an extra, support for Metric 
> Halo devices is also in the pipeline. Once all of these devices are 
> supported, we will cover a very large part of the Firewire audio device 
> spectrum. The most important void will be RME Fireface support, and for 
> the real budget users: Behringer and Hercules devices.
> 
> That's all folks!
> 
> Pieter Palmers
> (on behalf of the FreeBoB team)
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Freebob-devel mailing list
> Freebob-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freebob-devel
-- 
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org


From dominique.michel at citycable.ch  Wed Oct 18 11:40:00 2006
From: dominique.michel at citycable.ch (Dominique Michel)
Date: Wed Oct 18 11:40:45 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018122455.GA3125@localhost.localdomain>
References: <20061015110514.GA3059@localhost.localdomain>
	<20061016184835.11004.qmail@web27903.mail.ukl.yahoo.com>
	<20061017095620.GC5877@linux-1.site>
	<20061017125340.GA2617@localhost.localdomain>
	<20061018094502.GA6398@login.ecs.soton.ac.uk>
	<20061018122455.GA3125@localhost.localdomain>
Message-ID: <20061018174000.261059ef@localhost>

Le Wed, 18 Oct 2006 13:24:55 +0100,
John Rigg <ladev@sound-man.co.uk> a ?crit :

> On Wed, Oct 18, 2006 at 10:45:02AM +0100, Steve Harris wrote:
> > > True, but if the audio signal contains significant HF energy near
> > > the band limit, it doesn't take a very fast gain change to push it
> > > past that. Bear in mind that the ear is _very_ sensitive to aliasing
> > > artifacts, so `significant' can be a very small amount.
> > 
> > These are aliasing artifacts in the sidechain though, right? So they will
> > show up as modulations in the output, rather than directly audible
> > aliasing.
> 
> I was referring to aliasing in the compressed audio. Harmonic distortion
> is introduced during the attack (and decay, but usually to a lesser extent
> because it's slower).
> 
> Consider a sine wave audio input. In the attack, the gain is decreasing,
> so the rising parts of each input half-cycle are reduced in slope, and
> the falling parts are increased in slope. The audio waveform starts to take
> on a sawtooth shape if the rate of gain change is high enough.
> 
I cut the compressors in 2 classes: limiters as used in broadcasting
equipments, and compressors as used with electric guitars.

For the first ones, It can be true at low frequency, but most limiters will not
react faster as 1 ms or maybe 0.5 ms. And they are very simple. The analog
models are made of some kind of active component (transistor, FET, IC) acting
as a variable resistor on the signal path. The value of this variable
resistor depend on the amplitude of the signal. The signal load a simple
RC,which in turn command the value of the variable resistor. So, they are very
simple in design and it should not be so hard to develop a corresponding
algorithm. From my experience on DSP design, you should completely separate
the part calculation of the amplification factor (or value of the variable
resistor) and the signal processing. To combine the 2, you use the sound output
as source for the calculation of the amplification factor as in a real montage. 

The second ones are made of some kind of active and/or passive components
(vacuum tubes, transistors, FET, IC, diodes) acting in clipping, They can
combine a limiter in the same design. But to deal only with the compressor
part, the analog clipping is not the same as the digital clipping, and I don't
see how it can be possible to reproduce it with a software without to begin
with a signal analysis of a real montage. I think at after this analysis, it
will even be necessary to process by successive approximations and trials until
the algorithm fit with the reality well enough. I know someone that done such a
software on a DSP56k, the result was great, but it take him weeks and even
months of approximations and trials to do it.

-- 
Dominique Michel
From fons.adriaensen at skynet.be  Wed Oct 18 12:37:19 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Wed Oct 18 12:35:27 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018111445.GA3016@localhost.localdomain>
References: <20061018071658.c07d1943.mle+la@mega-nerd.com>
	<20061017215258.4511.qmail@web27909.mail.ukl.yahoo.com>
	<20061018082815.c9e9ab5c.mle+la@mega-nerd.com>
	<1161148992.9224.219.camel@c80-216-124-251.cm-upc.chello.se>
	<20061018084457.GA2695@localhost.localdomain>
	<20061018185039.3611aa9b.mle+la@mega-nerd.com>
	<20061018111445.GA3016@localhost.localdomain>
Message-ID: <20061018163719.GF5950@linux-1.site>

On Wed, Oct 18, 2006 at 12:14:45PM +0100, John Rigg wrote:

> The fact remains that a lot of high end professional users consider many
> of the free software plugins to be "nearly unusable" (see Ben Loftis'
> earlier post in this thread). This isn't intended as a criticism of the
> developers, just an acknowledgement that perhaps more attention needs to be
> paid to some fairly subtle aspects of design that have not been
> considered important up to now, if these high end users are to take
> Linux audio more seriously.

One of the things missing in all the LADSPA compressors I've seen so
far is a feature called 'release gate'. This freezes the release (i.e.
the gain stops rising) if the input signal drops below a set threshold.
It helps a lot in avoiding excessive 'pumping' on some types of signal.

-- 
FA

Lascia la spina, cogli la rosa.

From dmills_00 at yahoo.co.uk  Wed Oct 18 17:10:06 2006
From: dmills_00 at yahoo.co.uk (Dan Mills)
Date: Wed Oct 18 17:10:13 2006
Subject: [linux-audio-dev] Paper on dynamic range compression
In-Reply-To: <20061018163719.GF5950@linux-1.site>
Message-ID: <20061018211006.12521.qmail@web27914.mail.ukl.yahoo.com>


--- Fons Adriaensen <fons.adriaensen@skynet.be> wrote:

> One of the things missing in all the LADSPA
> compressors I've seen so
> far is a feature called 'release gate'. This freezes
> the release (i.e.
> the gain stops rising) if the input signal drops
> below a set threshold.
> It helps a lot in avoiding excessive 'pumping' on
> some types of signal.

It doesn't export it, but the original BSD licensed
code for the 'dyson' compressor does have this
feature. 

Regards, Dan.

Send instant messages to your online friends http://uk.messenger.yahoo.com 
From nedko at arnaudov.name  Fri Oct 20 04:55:55 2006
From: nedko at arnaudov.name (Nedko Arnaudov)
Date: Fri Oct 20 04:56:39 2006
Subject: [linux-audio-dev] jack_mixer - frist release
Message-ID: <87y7rbqsbo.fsf@arnaudov.name>

jack_mixer is GTK (2.x) JACK audio mixer with look similar to it`s
hardware counterparts. It has lot of useful features, apart from being
able to mix multiple JACK audio streams.

Homepage with screenshots: http://home.gna.org/jackmixer/

Download: http://download.gna.org/jackmixer/

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061020/27b103a5/attachment.bin
From simon.barthelme at univ-paris5.fr  Fri Oct 20 08:39:46 2006
From: simon.barthelme at univ-paris5.fr (=?ISO-8859-1?Q?Simon_Barthelm=E9?=)
Date: Fri Oct 20 08:39:33 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
Message-ID: <4538C392.7010109@univ-paris5.fr>

Hi all,

We're in the process of porting an open source Matlab toolbox to Linux 
called the Psychtoolbox. It's a piece of software that's widely used 
within neuroscience and psychophysics, to display graphics and play 
sounds in experiments. It uses OpenGl for its graphics backend, and 
right now the sound support is just matlab's, which is really poor.

A lot of us researchers are interested in audiovisual experiments, where 
we study how the brain combines auditory and visual information (for 
example in speech perception).

Concretely speaking, that means we need to get as precise a timing and 
synchrony as  we can possibly get.  A typical experiment will go 
something like this :
- display a flash and, at the same time, play a beep
- wait for response

The tricky bit is of course getting a flash that's totally synchronous 
with the beep. Absolute synchrony is not achievable without dedicated 
hardware, but we need to get an approximation that's within the few ms 
range.

 From what I've read it seems that Linux is a pretty good platform for 
that, since it has low latency/real time support.
What I need to know is how I should go about implementing some kind of 
FlashAndBeep function, that guarantees that the sound starts playing as 
soon as the display buffer is flipped, with the shortest predictable 
delay possible.

Is ALSA the way to go ?  JACK maybe ? Anything else ?

I'd love to read about any piece of advice you might have. Do ask me if 
you need more details.


Thanks a lot,

Simon Barthelm?
PhD Student
Laboratoire de Psychologie de la Perception
CNRS/Universit? Paris V

lpp.psycho.univ-paris5.fr



From fbar at footils.org  Fri Oct 20 10:36:02 2006
From: fbar at footils.org (Frank Barknecht)
Date: Fri Oct 20 10:37:22 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <4538C392.7010109@univ-paris5.fr>
References: <4538C392.7010109@univ-paris5.fr>
Message-ID: <20061020143602.GA11572@fliwatut.scifi>

Hallo,
Simon Barthelm? hat gesagt: // Simon Barthelm? wrote:

> Concretely speaking, that means we need to get as precise a timing and 
> synchrony as  we can possibly get.  A typical experiment will go 
> something like this :
> - display a flash and, at the same time, play a beep
> - wait for response
> 
> The tricky bit is of course getting a flash that's totally synchronous 
> with the beep. Absolute synchrony is not achievable without dedicated 
> hardware, but we need to get an approximation that's within the few ms 
> range.

Pure Data (Pd)  with one of its video extensions like Gem can tightly
sync audio and video. The usual framerate of Gem is 20fps, but you can
tune that. You can access the triggering of every frame to trigger a
sound immediatly. 

You can also use Pd to collect back the reaction of a human to this
using for example Pd's [hid] objects to acces HID devices. This
hid-input however seems to have a bit more latency. If you search the
archives of the Pd mailing list, you should find a longer thread
regarding this from some weeks ago, where somebody was actually using
Pd this way in psychological research. Maybe these experiences are
useful to you as well.

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__
From dave at pawfal.org  Fri Oct 20 10:51:09 2006
From: dave at pawfal.org (Dave Griffiths)
Date: Fri Oct 20 10:51:31 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <4538C392.7010109@univ-paris5.fr>
References: <4538C392.7010109@univ-paris5.fr>
Message-ID: <27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>

> Hi all,
>
> We're in the process of porting an open source Matlab toolbox to Linux
> called the Psychtoolbox. It's a piece of software that's widely used
> within neuroscience and psychophysics, to display graphics and play
> sounds in experiments. It uses OpenGl for its graphics backend, and
> right now the sound support is just matlab's, which is really poor.
>
> A lot of us researchers are interested in audiovisual experiments, where
> we study how the brain combines auditory and visual information (for
> example in speech perception).
>
> Concretely speaking, that means we need to get as precise a timing and
> synchrony as  we can possibly get.  A typical experiment will go
> something like this :
> - display a flash and, at the same time, play a beep
> - wait for response
>
> The tricky bit is of course getting a flash that's totally synchronous
> with the beep. Absolute synchrony is not achievable without dedicated
> hardware, but we need to get an approximation that's within the few ms
> range.

I do things a bit like this for audiovisual performances. It is impossible
to get it precisely right as you say, but what I tend to do is run
everything slightly ahead of realtime - so you timestamp events to happen
in the future. Of course you can't do this if human input is involved, but
if the timing is machine generated you can tune the audio and visual
independantly so they are close enough for most purposes.

This is also the technique I use for syncing live performances with other
people, it all tends to have to be tuned by hand as there are too many
variables to calculate - gfx card speed, hardware sound card latency etc
etc across different machines.

Technologically speaking I'd recommend using OSC protocol to send messages
to anything that accepts timestamped events.

cheers,

dave

From dominique.michel at citycable.ch  Fri Oct 20 10:55:49 2006
From: dominique.michel at citycable.ch (Dominique Michel)
Date: Fri Oct 20 10:56:45 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <4538C392.7010109@univ-paris5.fr>
References: <4538C392.7010109@univ-paris5.fr>
Message-ID: <20061020165549.72f763b9@localhost>

Le Fri, 20 Oct 2006 14:39:46 +0200,
Simon Barthelm? <simon.barthelme@univ-paris5.fr> a ?crit :

> Hi all,
> 
> We're in the process of porting an open source Matlab toolbox to Linux 
> called the Psychtoolbox. It's a piece of software that's widely used 
> within neuroscience and psychophysics, to display graphics and play 
> sounds in experiments. It uses OpenGl for its graphics backend, and 
> right now the sound support is just matlab's, which is really poor.
> 
> A lot of us researchers are interested in audiovisual experiments, where 
> we study how the brain combines auditory and visual information (for 
> example in speech perception).
> 
> Concretely speaking, that means we need to get as precise a timing and 
> synchrony as  we can possibly get.  A typical experiment will go 
> something like this :
> - display a flash and, at the same time, play a beep
> - wait for response
> 
> The tricky bit is of course getting a flash that's totally synchronous 
> with the beep. Absolute synchrony is not achievable without dedicated 
> hardware, but we need to get an approximation that's within the few ms 
> range.
> 
You will need a realtime kernel, which is basically a vanilla kernel with Ingo
Molnar's patches, and a way to fix the priorities. It can be realtime-lsm
security module (deprecated but simple and well tested) or rlimits (with or
without pam). Such a kernel is called realtime (-rt in short) or multimedia
because multimedia distributions as Demudi ou planet CCRMA use such a
kernel).

It is other implementations of realtime kernel, but this one is free, simple and
good enough to get a sound latency around the ms with a good hardware (even
with a live or audigy). The lowest achievable latency will depend not only of
the hardware but on the software too. Sound synthesis and filtering can use
too much processor power to be able to get the lowest achievable hardware
latency.

It is a few howto on the net on those rt kernels, among them:
http://proaudio.tuxfamily.org/wiki/index.php?title=Realtime_%28RT%29_Kernel
http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto

 
>  From what I've read it seems that Linux is a pretty good platform for 
> that, since it has low latency/real time support.
> What I need to know is how I should go about implementing some kind of 
> FlashAndBeep function, that guarantees that the sound starts playing as 
> soon as the display buffer is flipped, with the shortest predictable 
> delay possible.
> 
> Is ALSA the way to go ?  JACK maybe ? Anything else ?
> 
I think at Jack will be better as alsa, because jack assure you at the
execution of all the clients is synchronous, will use all the realtime
possibilities of the kernel and have the possibility to set the latency.

Install jack-audio-connection-kit and qjackctl and you are done. 

Best,

Dominique Michel
From fons.adriaensen at skynet.be  Fri Oct 20 13:03:08 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Fri Oct 20 13:01:13 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
References: <4538C392.7010109@univ-paris5.fr>
	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
Message-ID: <20061020170308.GB5929@linux-1.site>

On Fri, Oct 20, 2006 at 03:51:09PM +0100, Dave Griffiths wrote:

> > The tricky bit is of course getting a flash that's totally synchronous
> > with the beep. Absolute synchrony is not achievable without dedicated
> > hardware, but we need to get an approximation that's within the few ms
> > range.
> 
> I do things a bit like this for audiovisual performances. It is impossible
> to get it precisely right as you say, but what I tend to do is run
> everything slightly ahead of realtime - so you timestamp events to happen
> in the future. Of course you can't do this if human input is involved, but
> if the timing is machine generated you can tune the audio and visual
> independantly so they are close enough for most purposes.

It *is* possible to get it exactly right (to within one audio sample),
assuming

-  you know the audio round-trip latency of your sound card (jdelay
   will  measure it to less than a microsec precision),
-  you can send triggers from the video to the audio processes with
   a delay less than say 1/4 of the frame time, (not difficult), 

Input the vertical video sync signal via the audio card and analyse
its timing in terms of audio samples (e.g. using a DLL). This will
enable you to predict where the next sync will be in the audio input.
Using the known round trip audio delay, you also know to which sample
that corresponds in the audio output. Now if the video process sends
its  triggers a few frames ahead then the audio process will be able
to work out exactly where to put the corresponding samples.
 
-- 
FA

Lascia la spina, cogli la rosa.

From tim at quitte.de  Fri Oct 20 16:44:48 2006
From: tim at quitte.de (Tim Goetze)
Date: Fri Oct 20 16:47:07 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <20061020170308.GB5929@linux-1.site>
References: <4538C392.7010109@univ-paris5.fr>
	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
	<20061020170308.GB5929@linux-1.site>
Message-ID: <Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>

[Fons Adriaensen]
>Input the vertical video sync signal via the audio card and analyse
>its timing in terms of audio samples (e.g. using a DLL). This will
>enable you to predict where the next sync will be in the audio input.

Back in the 80s, the humble Commodore 64 could be readily programmed 
to fire an interrupt on vertical sync.  Have 20 years of progress 
really deprived us of this fine feature, or is it just missing from X?

Cheers, Tim
From paul at linuxaudiosystems.com  Fri Oct 20 16:53:55 2006
From: paul at linuxaudiosystems.com (Paul Davis)
Date: Fri Oct 20 16:54:13 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
References: <4538C392.7010109@univ-paris5.fr>
	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
	<20061020170308.GB5929@linux-1.site>
	<Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
Message-ID: <1161377635.17041.227.camel@localhost.localdomain>

On Fri, 2006-10-20 at 22:44 +0200, Tim Goetze wrote:
> [Fons Adriaensen]
> >Input the vertical video sync signal via the audio card and analyse
> >its timing in terms of audio samples (e.g. using a DLL). This will
> >enable you to predict where the next sync will be in the audio input.
> 
> Back in the 80s, the humble Commodore 64 could be readily programmed 
> to fire an interrupt on vertical sync.  Have 20 years of progress 
> really deprived us of this fine feature, or is it just missing from X?

it was missing from X until Xorg put it back in as an extension. its
obviously not of much use in a general purpose X app, since the display
may not be the host on which the app runs, making access to the vsync
pulse pretty pointless.


From tim at quitte.de  Fri Oct 20 17:08:26 2006
From: tim at quitte.de (Tim Goetze)
Date: Fri Oct 20 17:11:43 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <1161377635.17041.227.camel@localhost.localdomain>
References: <4538C392.7010109@univ-paris5.fr>
	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
	<20061020170308.GB5929@linux-1.site>
	<Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
	<1161377635.17041.227.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.63.0610202305130.1174@localhost.localdomain>

[Paul Davis]
>On Fri, 2006-10-20 at 22:44 +0200, Tim Goetze wrote:
>> Back in the 80s, the humble Commodore 64 could be readily programmed 
>> to fire an interrupt on vertical sync.  Have 20 years of progress 
>> really deprived us of this fine feature, or is it just missing from X?
>
>it was missing from X until Xorg put it back in as an extension. its
>obviously not of much use in a general purpose X app, since the display
>may not be the host on which the app runs, making access to the vsync
>pulse pretty pointless.

It's good to know it's available when you need it (and can arrange a 
local display). Now I can believe in progress again! :) Thanks.

Cheers, Tim
From James at superbug.co.uk  Fri Oct 20 17:11:39 2006
From: James at superbug.co.uk (James Courtier-Dutton)
Date: Fri Oct 20 17:12:30 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <4538C392.7010109@univ-paris5.fr>
References: <4538C392.7010109@univ-paris5.fr>
Message-ID: <45393B8B.5060408@superbug.co.uk>

Simon Barthelm? wrote:
> Hi all,
> 
> We're in the process of porting an open source Matlab toolbox to Linux 
> called the Psychtoolbox. It's a piece of software that's widely used 
> within neuroscience and psychophysics, to display graphics and play 
> sounds in experiments. It uses OpenGl for its graphics backend, and 
> right now the sound support is just matlab's, which is really poor.
> 
> A lot of us researchers are interested in audiovisual experiments, where 
> we study how the brain combines auditory and visual information (for 
> example in speech perception).
> 
> Concretely speaking, that means we need to get as precise a timing and 
> synchrony as  we can possibly get.  A typical experiment will go 
> something like this :
> - display a flash and, at the same time, play a beep
> - wait for response
> 
> The tricky bit is of course getting a flash that's totally synchronous 
> with the beep. Absolute synchrony is not achievable without dedicated 
> hardware, but we need to get an approximation that's within the few ms 
> range.
> 
>  From what I've read it seems that Linux is a pretty good platform for 
> that, since it has low latency/real time support.
> What I need to know is how I should go about implementing some kind of 
> FlashAndBeep function, that guarantees that the sound starts playing as 
> soon as the display buffer is flipped, with the shortest predictable 
> delay possible.
> 
> Is ALSA the way to go ?  JACK maybe ? Anything else ?
> 
> I'd love to read about any piece of advice you might have. Do ask me if 
> you need more details.
> 
> 
> Thanks a lot,
> 
> Simon Barthelm?
> PhD Student
> Laboratoire de Psychologie de la Perception
> CNRS/Universit? Paris V
> 
> lpp.psycho.univ-paris5.fr
> 
> 
> 

I don't know if you can do much about the video output. The delay from 
sending the frame to it being displayed is quite short, as least short 
enough not to worry movie playing in Linux.
I have done considerable work in xine to get audio lip sync good, and 
being an ALSA kernel developer as well helped.
The best audio/video lip sync is achieved if you have all the content 
ready some time before you wish to play it. I.e. A media file or some 
program that knows in advance when it should play the video.
ALSA has a function call "snd_pcm_delay()"
This returns the number of frames (or samples) between the next one you 
are about to write to ALSA, and the sound card hardware DAC playing the 
sample. So, by using this function, one can accurately determine when 
your sample will reach the speakers, and thus know exactly when to write 
the samples you want to the buffer. You then keep the audio in sync with 
a master system clock.
Separately, you keep the video in sync with a master system clock. The 
end result is the audio and video are kept in perfect sync.

James






From fons.adriaensen at skynet.be  Fri Oct 20 20:47:50 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Fri Oct 20 20:46:05 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
References: <4538C392.7010109@univ-paris5.fr>
	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
	<20061020170308.GB5929@linux-1.site>
	<Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
Message-ID: <20061021004750.GC5929@linux-1.site>

On Fri, Oct 20, 2006 at 10:44:48PM +0200, Tim Goetze wrote:

> Back in the 80s, the humble Commodore 64 could be readily programmed 
> to fire an interrupt on vertical sync.  Have 20 years of progress 
> really deprived us of this fine feature, or is it just missing from X?

Same on the humble BBC and on the ARM based Acorns. Those were the days... 

-- 
FA

Lascia la spina, cogli la rosa.

From gene.heskett at verizon.net  Fri Oct 20 22:25:01 2006
From: gene.heskett at verizon.net (Gene Heskett)
Date: Fri Oct 20 22:25:04 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <20061021004750.GC5929@linux-1.site>
References: <4538C392.7010109@univ-paris5.fr>
	<Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
	<20061021004750.GC5929@linux-1.site>
Message-ID: <200610202225.01892.gene.heskett@verizon.net>

On Friday 20 October 2006 20:47, Fons Adriaensen wrote:
>On Fri, Oct 20, 2006 at 10:44:48PM +0200, Tim Goetze wrote:
>> Back in the 80s, the humble Commodore 64 could be readily programmed
>> to fire an interrupt on vertical sync.  Have 20 years of progress
>> really deprived us of this fine feature, or is it just missing from X?
>
>Same on the humble BBC and on the ARM based Acorns. Those were the
> days...

Likewise the TRS-80 Color Computers and the Amiga's, all had that.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
From rlrevell at joe-job.com  Sat Oct 21 11:59:14 2006
From: rlrevell at joe-job.com (Lee Revell)
Date: Sat Oct 21 11:59:06 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <1161377635.17041.227.camel@localhost.localdomain>
References: <4538C392.7010109@univ-paris5.fr>
	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
	<20061020170308.GB5929@linux-1.site>
	<Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
	<1161377635.17041.227.camel@localhost.localdomain>
Message-ID: <1161446355.15860.393.camel@mindpipe>

On Fri, 2006-10-20 at 16:53 -0400, Paul Davis wrote:
> On Fri, 2006-10-20 at 22:44 +0200, Tim Goetze wrote:
> > [Fons Adriaensen]
> > >Input the vertical video sync signal via the audio card and analyse
> > >its timing in terms of audio samples (e.g. using a DLL). This will
> > >enable you to predict where the next sync will be in the audio input.
> > 
> > Back in the 80s, the humble Commodore 64 could be readily programmed 
> > to fire an interrupt on vertical sync.  Have 20 years of progress 
> > really deprived us of this fine feature, or is it just missing from X?
> 
> it was missing from X until Xorg put it back in as an extension. its
> obviously not of much use in a general purpose X app, since the display
> may not be the host on which the app runs, making access to the vsync
> pulse pretty pointless.
> 

I think any Linux system with DRI can do this.  Check /proc/interrupts -
if your video card is listed, then you should have vsync interrupt
capability.

Lee

From dominique.michel at citycable.ch  Sun Oct 22 09:00:16 2006
From: dominique.michel at citycable.ch (Dominique Michel)
Date: Sun Oct 22 09:01:03 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <1161446355.15860.393.camel@mindpipe>
References: <4538C392.7010109@univ-paris5.fr>
	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
	<20061020170308.GB5929@linux-1.site>
	<Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
	<1161377635.17041.227.camel@localhost.localdomain>
	<1161446355.15860.393.camel@mindpipe>
Message-ID: <20061022150016.7d45eb3e@localhost>

Le Sat, 21 Oct 2006 11:59:14 -0400,
Lee Revell <rlrevell@joe-job.com> a ?crit :

> On Fri, 2006-10-20 at 16:53 -0400, Paul Davis wrote:
> > On Fri, 2006-10-20 at 22:44 +0200, Tim Goetze wrote:
> > > [Fons Adriaensen]
> > > >Input the vertical video sync signal via the audio card and analyse
> > > >its timing in terms of audio samples (e.g. using a DLL). This will
> > > >enable you to predict where the next sync will be in the audio input.
> > > 
> > > Back in the 80s, the humble Commodore 64 could be readily programmed 
> > > to fire an interrupt on vertical sync.  Have 20 years of progress 
> > > really deprived us of this fine feature, or is it just missing from X?
> > 
> > it was missing from X until Xorg put it back in as an extension. its
> > obviously not of much use in a general purpose X app, since the display
> > may not be the host on which the app runs, making access to the vsync
> > pulse pretty pointless.
> > 
> 
> I think any Linux system with DRI can do this.  Check /proc/interrupts -
> if your video card is listed, then you should have vsync interrupt
> capability.
> 
> Lee
> 
I have a nvidia card in my box. If I use the nvidia driver, I get it
in /proc/interrupts, but if I use the nv driver, the card don't use an IRQ.
I am not a gamer, and for me, the nv driver is just better because I can use
this IRQ for another hardware and get a better IRQ setup with my rt kernel and
that already at the PIC level.

If compatibility is a concern, I think at it will be better to use a mechanism
provided by X that will exist on every single linux box, as to rely on a
hardware mechanism that will not be found on every system.

-- 
Dominique Michel
From rlrevell at joe-job.com  Sun Oct 22 11:42:16 2006
From: rlrevell at joe-job.com (Lee Revell)
Date: Sun Oct 22 11:41:59 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <20061022150016.7d45eb3e@localhost>
References: <4538C392.7010109@univ-paris5.fr>
	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>
	<20061020170308.GB5929@linux-1.site>
	<Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>
	<1161377635.17041.227.camel@localhost.localdomain>
	<1161446355.15860.393.camel@mindpipe>
	<20061022150016.7d45eb3e@localhost>
Message-ID: <1161531737.20231.51.camel@mindpipe>

On Sun, 2006-10-22 at 15:00 +0200, Dominique Michel wrote:
> Le Sat, 21 Oct 2006 11:59:14 -0400,
> > I think any Linux system with DRI can do this.  Check /proc/interrupts -
> > if your video card is listed, then you should have vsync interrupt
> > capability.
> > 
> > Lee
> > 
> I have a nvidia card in my box. If I use the nvidia driver, I get it
> in /proc/interrupts, but if I use the nv driver, the card don't use an IRQ.
> I am not a gamer, and for me, the nv driver is just better because I can use
> this IRQ for another hardware and get a better IRQ setup with my rt kernel and
> that already at the PIC level.
> 
> If compatibility is a concern, I think at it will be better to use a mechanism
> provided by X that will exist on every single linux box, as to rely on a
> hardware mechanism that will not be found on every system.
> 

Interrupts are a hardware mechanism by definition.  X cannot provide one
if the hardware lacks this feature (or the driver fails to enable it)

Lee

From a_mulyadi at telkom.net  Mon Oct 23 05:38:57 2006
From: a_mulyadi at telkom.net (Mulyadi Santosa)
Date: Mon Oct 23 05:49:33 2006
Subject: [linux-audio-dev] MIDI is playing but no sound
Message-ID: <200610231638.57633.a_mulyadi@telkom.net>

Hello everybody

Perhaps not directly related with audio development, but I will be glad 
if someone can help me.

I downloaded a free MIDI file from Internet (drum sample MIDI from 
"MIDI" wikipedia entry) and I tried to play it on my FC5. I am using 
both aplaymidi and KMid, but no sound comes out. Other than this 
silence, everything else seems OK i.e no error such as corrupted file. 
I tested the same file with WIndows Media Player and it plays fine. 
What was I doing wrong here?

Here is the specification:
Chip : Realtek ALC 650

ALSA: alsa-lib-devel-1.0.11-3.rc2.2, 
alsa-utils-1.0.11-3.rc2, 
alsa-lib-1.0.11-3.rc2.2

Kernel version: 2.6.16-1.2074_FC5

Desktop environment: KDE 3.5.1

Motherboard and chipset : MSI KT4V using VIA KT 400

Thanks in advance for the help.

regards,

Mulyadi

From simon.barthelme at univ-paris5.fr  Mon Oct 23 10:14:19 2006
From: simon.barthelme at univ-paris5.fr (=?ISO-8859-1?Q?Simon_Barthelm=E9?=)
Date: Mon Oct 23 10:14:06 2006
Subject: [linux-audio-dev] best option for audiovisual synchrony
In-Reply-To: <1161531737.20231.51.camel@mindpipe>
References: <4538C392.7010109@univ-paris5.fr>	<27845.217.18.21.2.1161355869.squirrel@webmail.pawfal.org>	<20061020170308.GB5929@linux-1.site>	<Pine.LNX.4.63.0610202237360.1174@localhost.localdomain>	<1161377635.17041.227.camel@localhost.localdomain>	<1161446355.15860.393.camel@mindpipe>	<20061022150016.7d45eb3e@localhost>
	<1161531737.20231.51.camel@mindpipe>
Message-ID: <453CCE3B.8040809@univ-paris5.fr>

Hi,

Thank you all for the great feedback. It seems there are more options 
available than I imagined. I'll look into your suggestions. I might come 
back to you people with more to the point technical questions.

Thanks again for the help,

Simon Barthelm?

Lee Revell wrote:
> On Sun, 2006-10-22 at 15:00 +0200, Dominique Michel wrote:
>   
>> Le Sat, 21 Oct 2006 11:59:14 -0400,
>>     
>>> I think any Linux system with DRI can do this.  Check /proc/interrupts -
>>> if your video card is listed, then you should have vsync interrupt
>>> capability.
>>>
>>> Lee
>>>
>>>       
>> I have a nvidia card in my box. If I use the nvidia driver, I get it
>> in /proc/interrupts, but if I use the nv driver, the card don't use an IRQ.
>> I am not a gamer, and for me, the nv driver is just better because I can use
>> this IRQ for another hardware and get a better IRQ setup with my rt kernel and
>> that already at the PIC level.
>>
>> If compatibility is a concern, I think at it will be better to use a mechanism
>> provided by X that will exist on every single linux box, as to rely on a
>> hardware mechanism that will not be found on every system.
>>
>>     
>
> Interrupts are a hardware mechanism by definition.  X cannot provide one
> if the hardware lacks this feature (or the driver fails to enable it)
>
> Lee
>
>
>   


-- 
Simon Barthelm?
PhD Student
Laboratoire de Psychologie de la Perception
CNRS/Universit? Paris V
lpp.psycho.univ-paris5.fr

From radarsat1 at gmail.com  Mon Oct 23 10:16:38 2006
From: radarsat1 at gmail.com (Stephen Sinclair)
Date: Mon Oct 23 10:17:06 2006
Subject: [linux-audio-dev] MIDI is playing but no sound
In-Reply-To: <200610231638.57633.a_mulyadi@telkom.net>
References: <200610231638.57633.a_mulyadi@telkom.net>
Message-ID: <9b3e2dc20610230716h3c176968x695d07ca3e91b0ea@mail.gmail.com>

> What was I doing wrong here?

Hi,
I'm pretty sure that KMid and aplaymidi are both just simple players
that direct MIDI output to your soundcard's MIDI interface.  (Someone
correct me if I'm wrong.)  They are not midi _synthesizers_, so you
won't hear any sound unless you have a synthesizer attached to your
soundcard.

Instead, try Timidity++, which is probably in your distribution.
http://timidity.sourceforge.net/#info


Steve
From dominique.michel at citycable.ch  Mon Oct 23 11:09:11 2006
From: dominique.michel at citycable.ch (Dominique Michel)
Date: Mon Oct 23 11:09:57 2006
Subject: [linux-audio-dev] MIDI is playing but no sound
In-Reply-To: <9b3e2dc20610230716h3c176968x695d07ca3e91b0ea@mail.gmail.com>
References: <200610231638.57633.a_mulyadi@telkom.net>
	<9b3e2dc20610230716h3c176968x695d07ca3e91b0ea@mail.gmail.com>
Message-ID: <20061023170911.51f4ee11@localhost>

Le Mon, 23 Oct 2006 10:16:38 -0400,
"Stephen Sinclair" <radarsat1@gmail.com> a ?crit :

> > What was I doing wrong here?
> 
> Hi,
> I'm pretty sure that KMid and aplaymidi are both just simple players
> that direct MIDI output to your soundcard's MIDI interface.  (Someone
> correct me if I'm wrong.)  They are not midi _synthesizers_, so you
> won't hear any sound unless you have a synthesizer attached to your
> soundcard.
> 

Kmid and aplaymidi just read a midi file and send it to an output. If a
synthesizer is connected to that output, or if this output correspond to
timidity++ running as a server or to the synth of a sound card like a live or an
audigy, you will hear the music.

> Instead, try Timidity++, which is probably in your distribution.
> http://timidity.sourceforge.net/#info
> 
> 
> Steve

The big difference between windows and linux is at windows will install by
default a software synthesizer when most in not all the linux distribution do
not do that, even if timidity++ is included with most of them. So many windows
users are not aware at they don't have a synth in their sound card.

Timidity is a great software, you can configure it as a MIDI server that will
appear as a MIDI synth in alsa and use sf2 soundfonts with it. You can even
play midi file directly with it. Just run
timidity <file.mid>

-- 
Dominique Michel

--
N.B.: Tous les emails que je re?ois sont filtr?s par spamassassin avant de me
parvenir.

Si vous attendez une r?ponse de ma part et que vous ne la recevez pas, cela
signifie qu'en toute vraisemblance, votre courrier ne m'est pas parvenu car
vous figurez sur une des listes de http://www.spamhaus.org.
From mr.spoon21 at gmail.com  Tue Oct 24 05:46:21 2006
From: mr.spoon21 at gmail.com (Carlo Trimarchi)
Date: Tue Oct 24 05:46:38 2006
Subject: [linux-audio-dev] USB keyboard on Linux
Message-ID: <8f67b6f80610240246g33485af5l5952b19938172f43@mail.gmail.com>

Hi, I'm new here.

I'd like to buy a USB Keyboard and I was thinking to a M-AUDIO Keystation 49E.

http://www.m-audio.com/products/en_us/Keystation49e-main.html

Do you know if it is compatible with linux? Have you ever tried it?

Thanks, bye.
From lars.luthman at gmail.com  Tue Oct 24 05:53:17 2006
From: lars.luthman at gmail.com (Lars Luthman)
Date: Tue Oct 24 05:53:29 2006
Subject: [linux-audio-dev] USB keyboard on Linux
In-Reply-To: <8f67b6f80610240246g33485af5l5952b19938172f43@mail.gmail.com>
References: <8f67b6f80610240246g33485af5l5952b19938172f43@mail.gmail.com>
Message-ID: <1161683597.11587.19.camel@c213-100-20-9.swipnet.se>

On Tue, 2006-10-24 at 11:46 +0200, Carlo Trimarchi wrote:
> Hi, I'm new here.
> 
> I'd like to buy a USB Keyboard and I was thinking to a M-AUDIO Keystation 49E.
> 
> http://www.m-audio.com/products/en_us/Keystation49e-main.html
> 
> Do you know if it is compatible with linux? Have you ever tried it?

I have one. It's USB class compliant, works perfectly with the
snd-usb-audio module.

-- 
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061024/85782b4c/attachment.bin
From a_mulyadi at telkom.net  Tue Oct 24 06:52:32 2006
From: a_mulyadi at telkom.net (Mulyadi Santosa)
Date: Tue Oct 24 07:08:52 2006
Subject: [linux-audio-dev] MIDI is playing but no sound
In-Reply-To: <20061023170911.51f4ee11@localhost>
References: <200610231638.57633.a_mulyadi@telkom.net>
	<9b3e2dc20610230716h3c176968x695d07ca3e91b0ea@mail.gmail.com>
	<20061023170911.51f4ee11@localhost>
Message-ID: <200610241752.32549.a_mulyadi@telkom.net>

Hi....

> Kmid and aplaymidi just read a midi file and send it to an output. If
> a synthesizer is connected to that output, or if this output
> correspond to timidity++ running as a server or to the synth of a
> sound card like a live or an audigy, you will hear the music.

Thanks a lot, it works by using Timidity++ (in fact it is in FC5, i am 
just not aware of it).

regards,

Mulyadi

From gene.heskett at verizon.net  Tue Oct 24 10:20:31 2006
From: gene.heskett at verizon.net (Gene Heskett)
Date: Tue Oct 24 10:21:00 2006
Subject: [linux-audio-dev] MIDI is playing but no sound
In-Reply-To: <200610241752.32549.a_mulyadi@telkom.net>
References: <200610231638.57633.a_mulyadi@telkom.net>
	<20061023170911.51f4ee11@localhost>
	<200610241752.32549.a_mulyadi@telkom.net>
Message-ID: <200610241020.31327.gene.heskett@verizon.net>

On Tuesday 24 October 2006 06:52, Mulyadi Santosa wrote:
>Hi....
>
>> Kmid and aplaymidi just read a midi file and send it to an output. If
>> a synthesizer is connected to that output, or if this output
>> correspond to timidity++ running as a server or to the synth of a
>> sound card like a live or an audigy, you will hear the music.
>
>Thanks a lot, it works by using Timidity++ (in fact it is in FC5, i am
>just not aware of it).
>
Sometimes its even easier than that.  My audigy 2 is not a ca106 card, but 
an emu10k1 card.  I can load, useing sfxload, a file containing the 
general midi voices at bootup, one such file is on the cd that came with 
the card, and then all the software has to do it feed the midi file to the 
card and it does all the processing.  Timidity can do this too of course, 
but needs reasonably heavy iron in the cpu to do it comfortably.

>regards,
>
>Mulyadi

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
From krampenschiesser at freenet.de  Tue Oct 24 18:11:35 2006
From: krampenschiesser at freenet.de (krampenschiesser@freenet.de)
Date: Tue Oct 24 16:55:45 2006
Subject: [linux-audio-dev] USB keyboard on Linux
In-Reply-To: <1161683597.11587.19.camel@c213-100-20-9.swipnet.se>
References: <8f67b6f80610240246g33485af5l5952b19938172f43@mail.gmail.com>
	<1161683597.11587.19.camel@c213-100-20-9.swipnet.se>
Message-ID: <20061025001135.f5dff908.krampenschiesser@freenet.de>

If someone wants to know: KeyControl 25 works also.

-- 
[Family is sitting at Table. After Apocalypse. Eating eggs on random pieces of metal] 
Lois Griffin:  It's Ok. Right before the Apocalypse, Peter bought a year's worth of food. [Camera Goes to Peter. He's just finishing off the last of the food] 
Lois Griffin:  PETER. You just finished off a years supply of food. 
Peter Griffin:  What a waste. I'm still hungry. [Peter drinks a glass of water and gets really bloated] 
Peter Griffin:  Everyone leave. I have to poop. [Everyone looks at him] 
Peter Griffin:  NOW.
From capocasa at gmx.net  Tue Oct 24 16:56:57 2006
From: capocasa at gmx.net (Carlo Capocasa)
Date: Tue Oct 24 17:05:16 2006
Subject: [linux-audio-dev] Re: [ANN] FreeBoB 1.0 released - Firewire Audio
	for Linux
In-Reply-To: <45363352.5050705@joow.be>
References: <45363352.5050705@joow.be>
Message-ID: <ehlula$ijr$1@sea.gmane.org>

Congratulations, Pieter. I had an opportunity to test it and it has far 
surpassed my expectations. Meaning, it compiles, and it works! Kudos!
Carlo

Pieter Palmers wrote:
> Greetings,
> 
> Now that JACK 0.102.20 and QJackCtl 0.2.21 being released, the FreeBoB 
> team is proud to present libfreebob 1.0. The FreeBoB project aims to 
> provide a generic solution for using Firewire (semi-)pro-audio devices 
> in Linux.
> 
> This release provides support for the devices based on the BridgeCo 
> DM1000 or DM1500 chipset that are running the BeBoB firmware. For a list 
> of supported devices, consult our website at freebob.sf.net.
> 
> FreeBoB currently provides an interface library that allows firewire 
> audio devices to be used with the JACK audio server, using a dedicated 
> backend. This backend is included in the official JACK releases, from 
> this version on (i.e. 0.102.20). The latest version of QJackCtl also 
> includes support for this FreeBoB backend. MIDI support is provided 
> through ALSA sequencer.
> 
> Feature list:
> * Automatic detection & configuration of devices. If there are multiple 
> devices attached to the same firewire bus, freebob merges them into one 
> big device. The devices have to be synced externally (wordclock/spdif) 
> so that they don't drift. Note that this release cannot setup the boxes 
> to be synced yet, being synced is a precondition at the moment. (I 
> tested this with 2 phase88's connected with wordclock, and this works 
> without the need for any special setting because the Phase88 
> automatically chooses wordclock slave when there is a wordclock signal 
> present. This can be different for other models).
> * Audio I/O on all analog channels at all sample rates supported by the 
> device. SPDIF/ADAT I/O works in most cases (when presented as analog IO 
> by the device). AC3 passthrough doesn't work.
> * Midi I/O for all midi ports the device implements, using alsa-sequencer
> * Round-trip latency figures around 5ms (depends on system 
> configuration). 10ms is achievable on all well-configured machines
> 
> Not supported yet:
> * Hardware mixing ("zero latency" mixer)
> * Device-specific configuration (input gain switches, sync source 
> selection, midi control mappings, ...)
> * ALSA for audio IO
> * Special SPDIF/ADAT stream support
> 
> You can download FreeBoB 1.0 at our sourceforge page:
> http://sourceforge.net/project/showfiles.php?group_id=117802
> more info at freebob.sf.net
> 
> What's next?
> 
> We are working on the second generation of the FreeBoB codebase. The 1.0 
> release is the endpoint for the codebase that dates back to the start of 
> the project. The 2.0 codebase is a complete redesign of the system using 
> 1.0 as a 'golden spec'. While the 1.0 version is BeBoB-only, the 2.0 
> codebase is designed as a framework to support all firewire based audio 
> boxes. The current level of functionality is almost the same for both 
> codebases. The main difference is that 1.0 had one year of testing and 
> 2.0 doesn't, it's still in the alpha stage. Needless to say that 2.0 
> will outperform 1.0 by far ;).
> 
> Of course this redesign isn't for the sake of aesthetic beauty or lack 
> of things to do... I can announce that we are already working on 
> broadening the supported device list. Currently there is support for the 
> Motu Traveller and the Motu 828 (through reverse engineering). There are 
> also contacts with the DICE-II developers to implement generic support 
> for devices based upon their chipset. As an extra, support for Metric 
> Halo devices is also in the pipeline. Once all of these devices are 
> supported, we will cover a very large part of the Firewire audio device 
> spectrum. The most important void will be RME Fireface support, and for 
> the real budget users: Behringer and Hercules devices.
> 
> That's all folks!
> 
> Pieter Palmers
> (on behalf of the FreeBoB team)
> 
> 

From a_mulyadi at telkom.net  Wed Oct 25 07:35:47 2006
From: a_mulyadi at telkom.net (Mulyadi Santosa)
Date: Wed Oct 25 07:40:10 2006
Subject: [linux-audio-dev] about MIDI timing...
Message-ID: <200610251835.47909.a_mulyadi@telkom.net>

Hello list...

I am curious to research further about MIDI timing and here is something 
I want to ask...

I wonder, if we missed the (MIDI?) event a bit (perhaps 1 miliseconds?), 
what would happen? I guess it will be underrun? Or technically, do we 
determine a playback as "choppy" by calculating the time difference 
between sending two successive MIDI events? I don't know much about 
this issue, so I will gladly receive any thoughts.

On the other hand, last night I observed how timidity++ works by using 
strace and I found no *sleep() (nanosleep, msleep and friends). Does it 
mean, major MIDI software synthesizers use non system sleep mechanism 
for the timing? I also read that not all Linux kernel sound card driver 
enable the internal card timer, thus the software must rely on system 
timer. Is it correct?

thanks in advance for your help and attention.

regards,

Mulyadi

From a_mulyadi at telkom.net  Wed Oct 25 07:35:47 2006
From: a_mulyadi at telkom.net (Mulyadi Santosa)
Date: Wed Oct 25 07:41:35 2006
Subject: [linux-audio-dev] about MIDI timing...
Message-ID: <200610251835.47909.a_mulyadi@telkom.net>

Hello list...

I am curious to research further about MIDI timing and here is something 
I want to ask...

I wonder, if we missed the (MIDI?) event a bit (perhaps 1 miliseconds?), 
what would happen? I guess it will be underrun? Or technically, do we 
determine a playback as "choppy" by calculating the time difference 
between sending two successive MIDI events? I don't know much about 
this issue, so I will gladly receive any thoughts.

On the other hand, last night I observed how timidity++ works by using 
strace and I found no *sleep() (nanosleep, msleep and friends). Does it 
mean, major MIDI software synthesizers use non system sleep mechanism 
for the timing? I also read that not all Linux kernel sound card driver 
enable the internal card timer, thus the software must rely on system 
timer. Is it correct?

thanks in advance for your help and attention.

regards,

Mulyadi

From radarsat1 at gmail.com  Wed Oct 25 08:29:34 2006
From: radarsat1 at gmail.com (Stephen Sinclair)
Date: Wed Oct 25 08:29:42 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <200610251835.47909.a_mulyadi@telkom.net>
References: <200610251835.47909.a_mulyadi@telkom.net>
Message-ID: <9b3e2dc20610250529r70feeb73v3d3fb906e9ef6857@mail.gmail.com>

> On the other hand, last night I observed how timidity++ works by using
> strace and I found no *sleep() (nanosleep, msleep and friends). Does it
> mean, major MIDI software synthesizers use non system sleep mechanism
> for the timing?

I believe Timidity++ just uses its synthesizer to convert the MIDI
information into an audio stream, which it then either writes to a
file or plays through the soundcard.  So it doesn't need precise
timing, since the audio callback it uses is already timed by the sound
system.

When dealing with real MIDI, timing is more critical, though usually
you simply use timestamps which tell the sound system when a MIDI
event should be played, instead of dealing with the timing yourself.
(At least I know this is the case with PortMidi, I've never programmed
with ALSA directly.)

By the way, there are more ways to time things than just *sleep().
For example, using sigalrm and setitimer.


> I also read that not all Linux kernel sound card driver
> enable the internal card timer, thus the software must rely on system
> timer. Is it correct?

Don't know anything about that.  I think all soundcards use an
built-in timer for playing their FIFO.  As for interrupting the
computer to tell it when it needs more data, I guess it's possible
that sometimes it uses the card's timer and sometimes uses the system
timer.  Someone more informed may have something to say.


Steve
From cladisch at fastmail.net  Wed Oct 25 09:19:12 2006
From: cladisch at fastmail.net (Clemens Ladisch)
Date: Wed Oct 25 09:19:21 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <200610251835.47909.a_mulyadi@telkom.net>
References: <200610251835.47909.a_mulyadi@telkom.net>
Message-ID: <1161782352.22897.274184138@webmail.messagingengine.com>

Mulyadi Santosa wrote:
> I also read that not all Linux kernel sound card driver enable the
> internal card timer, thus the software must rely on system timer.

Most sound cards don't have an internal timer that could be used for
MIDI timing.  ALSA uses whatever timer is configured, the default for
this is the RTC timer.


HTH
Clemens
From smcameron at yahoo.com  Wed Oct 25 10:02:51 2006
From: smcameron at yahoo.com (Stephen Cameron)
Date: Wed Oct 25 10:04:01 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <9b3e2dc20610250529r70feeb73v3d3fb906e9ef6857@mail.gmail.com>
Message-ID: <20061025140251.53545.qmail@web33010.mail.mud.yahoo.com>

--- Stephen Sinclair <radarsat1@gmail.com> wrote:

[...]
> 
> By the way, there are more ways to time things than just *sleep().
> For example, using sigalrm and setitimer.

>From the sleep(3) man page:

BUGS
       sleep()  may be implemented using SIGALRM; mixing calls to alarm() and
       sleep() is a bad idea.

Not that there aren't more ways, just that using sleep() and 
and using SIGALRM aren't necessarily different ways.  It says
"may be", but on linuxes I know, sleep() _is_ implemented
via SIGALRM, I'm pretty sure.  (Somebody correct me if I'm
wrong about that.)

And setitimer also uses SIGALRM, if you use it for real
(wall clock) time, so it's not really a different way 
either.

Well, I guess there is the difference that the process isn't
necessarily put to sleep if you don't call sleep(), but the
timing mechanism is, so far as I know, the same in all three.

-- steve


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
From chris.cannam at ferventsoftware.com  Wed Oct 25 11:05:00 2006
From: chris.cannam at ferventsoftware.com (Chris Cannam)
Date: Wed Oct 25 11:09:38 2006
Subject: [linux-audio-dev] about MIDI timing...
Message-ID: <1005301277-1161788970-cardhu_blackberry.rim.net-4853-@engine42.bwc.produk.on.blackberry>

Clemens:
> Most sound cards don't have an internal timer that could be used for
> MIDI timing.  ALSA uses whatever timer is configured, the default for
> this is the RTC timer.

It is?  For ALSA sequencer queues?  I thought the 
default was system timer.  Maybe it just depends on 
the modules you have loaded. 

My impression from Rosegarden users' reports has 
been that trying to use the ALSA sequencer with the 
RTC timer (something I've never bothered with myself: 
I always use a 1000Hz system timer) is a reliable way 
to lock up your system completely, with most kernels 
from about 2.6.13 or so onwards.

I've been meaning to investigate with the latest ALSA 
source and at least make a decent bug report for 
ages, but you know the way it is, there are only
sixty hours in the day.  It would be wonderful if some 
excellent person had fixed it in the meantime.


Chris
From rlrevell at joe-job.com  Wed Oct 25 11:17:39 2006
From: rlrevell at joe-job.com (Lee Revell)
Date: Wed Oct 25 11:18:01 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <1005301277-1161788970-cardhu_blackberry.rim.net-4853-@engine42.bwc.produk.on.blackberry>
References: <1005301277-1161788970-cardhu_blackberry.rim.net-4853-@engine42.bwc.produk.on.blackberry>
Message-ID: <1161789461.3982.260.camel@mindpipe>

On Wed, 2006-10-25 at 15:05 +0000, Chris Cannam wrote:
> Clemens:
> > Most sound cards don't have an internal timer that could be used for
> > MIDI timing.  ALSA uses whatever timer is configured, the default for
> > this is the RTC timer.
> 
> It is?  For ALSA sequencer queues?  I thought the 
> default was system timer.  Maybe it just depends on 
> the modules you have loaded. 
> 
> My impression from Rosegarden users' reports has 
> been that trying to use the ALSA sequencer with the 
> RTC timer (something I've never bothered with myself: 
> I always use a 1000Hz system timer) is a reliable way 
> to lock up your system completely, with most kernels 
> from about 2.6.13 or so onwards.
> 
> I've been meaning to investigate with the latest ALSA 
> source and at least make a decent bug report for 
> ages, but you know the way it is, there are only
> sixty hours in the day.  It would be wonderful if some 
> excellent person had fixed it in the meantime.

This is/was a bug or multiple bugs in the kernel's RTC driver.  It
started to appear around 2.6.13 because that was the kernel release
where they regressed the default timer granularity from 1ms to 2.5ms,
forcing apps like Rosegarden to switch to RTC based timing.

Should be fixed in the latest kernels.

Lee

From cladisch at fastmail.net  Wed Oct 25 11:26:47 2006
From: cladisch at fastmail.net (Clemens Ladisch)
Date: Wed Oct 25 11:28:01 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <1005301277-1161788970-cardhu_blackberry.rim.net-4853-@engine42.bwc.produk.on.blackberry>
References: <1005301277-1161788970-cardhu_blackberry.rim.net-4853-@engine42.bwc.produk.on.blackberry>
Message-ID: <1161790007.7720.274195393@webmail.messagingengine.com>

Chris Cannam wrote:
> Clemens:
> > Most sound cards don't have an internal timer that could be used for
> > MIDI timing.  ALSA uses whatever timer is configured, the default for
> > this is the RTC timer.
> 
> It is?  For ALSA sequencer queues?  I thought the 
> default was system timer.

Since 1.0.11, the RTC timer is used, if available.

> Maybe it just depends on the modules you have loaded. 

Timer modules are loaded automatically.

> My impression from Rosegarden users' reports has 
> been that trying to use the ALSA sequencer with the 
> RTC timer (something I've never bothered with myself: 
> I always use a 1000Hz system timer) is a reliable way 
> to lock up your system completely, with most kernels 
> from about 2.6.13 or so onwards.

Kernels >= 2.6.15 work.  The configure script checks for older kernels.


HTH
Clemens
From chris.cannam at ferventsoftware.com  Wed Oct 25 12:15:47 2006
From: chris.cannam at ferventsoftware.com (Chris Cannam)
Date: Wed Oct 25 12:20:31 2006
Subject: [linux-audio-dev] about MIDI timing...
Message-ID: <1949972918-1161793219-cardhu_blackberry.rim.net-18273-@engine23.bwc.produk.on.blackberry>

Lee:
> This is/was a bug or multiple bugs in the kernel's RTC driver.  It
> started to appear around 2.6.13 because that was the kernel release
> where they regressed the default timer granularity from 1ms to 2.5ms,
> forcing apps like Rosegarden to switch to RTC based timing.

No, it genuinely went from working to broken - it's 
not a case of always being broken but never 
previously being necessary.  It broke first in RT 
kernels, so I'm guessing it broke in mainline with an 
RT patch merge. 

I'm not aware of anyone these days successfully 
using Rosegarden with snd-rtctimer - if anyone out 
there is, do say so.  Either you get a 1000Hz kernel
or you suffer with crap timing. 

Clemens:
> Kernels >= 2.6.15 work.

The most recent such report we had was from a 
user of OpenSUSE 10.1 (with 2.6.16 I think?).  I 
suggested trying an ALSA driver upgrade; apparently it didn't help.  The thread should be easily found in
the Rosegarden list archives by searching for rtc 
and opensuse.

I don't have a computer here to test it on at all 
myself at the moment, I'm afraid.  I will do later.  Honest. 


Chris
From chris.cannam at ferventsoftware.com  Wed Oct 25 12:28:28 2006
From: chris.cannam at ferventsoftware.com (Chris Cannam)
Date: Wed Oct 25 12:33:41 2006
Subject: [linux-audio-dev] about MIDI timing...
Message-ID: <409841777-1161793993-cardhu_blackberry.rim.net-9458-@engine55.bwc.produk.on.blackberry>

Me:
> I'm not aware of anyone these days successfully 
> using Rosegarden with snd-rtctimer - if anyone out
> there is, do say so.

To test:

* start RG (version 1.0 or newer)
* go to Settings -> Configure Rosegarden -> Sequencer -> Synchronisation
* change the sequencer timing source option to RTC
* close configuration window, press play. 

It probably doesn't matter whether you have a file
loaded or not. 

Success -> play pointer moves smoothly
Failure -> system locks up solid, reboot required. 

If it does lock up, you may need to edit your 
rosegardenrc to restore the timer setting before 
you can run RG again. 


Chris
From chris.cannam at ferventsoftware.com  Wed Oct 25 12:42:35 2006
From: chris.cannam at ferventsoftware.com (Chris Cannam)
Date: Wed Oct 25 12:47:19 2006
Subject: [linux-audio-dev] about MIDI timing...
Message-ID: <1672521682-1161794826-cardhu_blackberry.rim.net-11063-@engine43.bwc.produk.on.blackberry>

Me:
> No, it genuinely went from working to broken

And actually, I think my recollection is wrong.  I think 
it probably broke in 2.6.8-rt, and in mainline in either 
2.6.9 or 2.6.10.  Before that it worked fine, but we 
always used the system timer instead for RG because it 
seemed simpler (it was always 1000Hz then) and we
stuck with that as the default and I guess rather 
abandoned the RTC option.  Sorry for being so lax. 

If it does work now, then of course, that's great. 


Chris
From rlrevell at joe-job.com  Wed Oct 25 12:59:00 2006
From: rlrevell at joe-job.com (Lee Revell)
Date: Wed Oct 25 12:59:30 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <1672521682-1161794826-cardhu_blackberry.rim.net-11063-@engine43.bwc.produk.on.blackberry>
References: <1672521682-1161794826-cardhu_blackberry.rim.net-11063-@engine43.bwc.produk.on.blackberry>
Message-ID: <1161795541.3982.282.camel@mindpipe>

On Wed, 2006-10-25 at 16:42 +0000, Chris Cannam wrote:
> Me:
> > No, it genuinely went from working to broken
> 
> And actually, I think my recollection is wrong.  I think 
> it probably broke in 2.6.8-rt, and in mainline in either 
> 2.6.9 or 2.6.10.  Before that it worked fine, but we 
> always used the system timer instead for RG because it 
> seemed simpler (it was always 1000Hz then) and we
> stuck with that as the default and I guess rather 
> abandoned the RTC option.  Sorry for being so lax. 
> 
> If it does work now, then of course, that's great. 

You need to get the users having the problem to retest with kernel
2.6.18 or 2.6.19-rc*.  Older kernels can't be fixed so what's the point?

Lee

From mista.tapas at gmx.net  Wed Oct 25 14:26:47 2006
From: mista.tapas at gmx.net (Florian Schmidt)
Date: Wed Oct 25 14:26:34 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <409841777-1161793993-cardhu_blackberry.rim.net-9458-@engine55.bwc.produk.on.blackberry>
References: <409841777-1161793993-cardhu_blackberry.rim.net-9458-@engine55.bwc.produk.on.blackberry>
Message-ID: <200610252026.47905.mista.tapas@gmx.net>

On Wednesday 25 October 2006 18:28, Chris Cannam wrote:
> Me:
> > I'm not aware of anyone these days successfully
> > using Rosegarden with snd-rtctimer - if anyone out
> > there is, do say so.
>
> To test:
>
> * start RG (version 1.0 or newer)
> * go to Settings -> Configure Rosegarden -> Sequencer -> Synchronisation
> * change the sequencer timing source option to RTC
> * close configuration window, press play.
>
> It probably doesn't matter whether you have a file
> loaded or not.
>
> Success -> play pointer moves smoothly
> Failure -> system locks up solid, reboot required.
>
> If it does lock up, you may need to edit your
> rosegardenrc to restore the timer setting before
> you can run RG again.

It doesn't lock up here running 2.6.18-rt7 with tickless kernel, hi res timers 
and some debugging enabled. Interesting enough though, the second time i 
tried to run ti from a terminal to be able to observe output i got a kernel 
BUG ;)

Sadly my kernel is tested with the NVIDIA binary only driver, so this tells us 
exactly nothing :) Except that i should reboot and not load the nvidia 
driver ;)

Flo

------------[ cut here ]------------
kernel BUG at kernel/rtmutex.c:673!
invalid opcode: 0000 [#1]
PREEMPT 
Modules linked in: snd_rtctimer nvidia iptable_nat ip_tables snd_intel8x0 
ppdev parport_pc lp parport snd_seq_dummy snd_seq_oss snd_seq_midi 
snd_seq_midi_event snd_seq kqemu usb_storage scsi_mod ipt_MASQUERADE ip_nat 
x_tables ip_conntrack bsd_comp ppp_deflate zlib_deflate ppp_async ppp_generic 
slhc crc_ccitt snd_ice1712 snd_ice17xx_ak4xxx snd_cs46xx snd_ak4xxx_adda 
snd_cs8427 gameport snd_i2c snd_ac97_codec snd_ac97_bus snd_mpu401_uart 
snd_pcm_oss snd_mixer_oss snd_rawmidi snd_seq_device snd_pcm snd_timer 
i2c_sis630 snd evdev ohci_hcd epic100 i2c_sis96x sis900 mii usbcore crc32 
snd_page_alloc sis_agp agpgart i2c_core soundcore
CPU:    0
EIP:    0060:[<c02d72af>]    Tainted: P      VLI
EFLAGS: 00010082   (2.6.18-rt7 #3) 
EIP is at rt_spin_lock_slowlock+0x19f/0x1e0
eax: 00000020   ebx: 00000282   ecx: 00000001   edx: 00000000
esi: c0336fe0   edi: c41bf600   ebp: f7d22e94   esp: f7d22e30
ds: 007b   es: 007b   ss: 0068   preempt: 00000002
Process IRQ 8 (pid: 651, ti=f7d22000 task=f7d202b0 task.ti=f7d22000)
Stack: c02ed14d c02f14dd 000002a1 c02d7264 f7d22e64 0000008c f7d22e48 f7d22e48 
       f7d22e50 f7d22e50 00000000 0000008c f7d22e60 f7d22e60 f7d22e68 f7d22e68 
       00000000 00000000 11111111 11111111 11111111 11111111 c0336fe0 00000000 
Call Trace:
 [<c02d7a0e>] rt_spin_lock+0xe/0x50
 [<c0233e0a>] rtc_control+0x3a/0x80
 [<f89cc02b>] rtctimer_stop+0x2b/0x50 [snd_rtctimer]
 [<f88f5470>] snd_timer_interrupt+0x2b0/0x2f0 [snd_timer]
 [<f89cc139>] rtctimer_interrupt+0x19/0x20 [snd_rtctimer]
 [<c0234122>] rtc_interrupt+0x72/0x120
 [<c013e49e>] handle_IRQ_event+0x6e/0x100
 [<c013ea62>] thread_simple_irq+0x62/0xa0
 [<c013f377>] do_irqd+0x2a7/0x310
 [<c012a7c9>] kthread+0xe9/0xf0
 [<c0100e05>] kernel_thread_helper+0x5/0x10
DWARF2 unwinder stuck at kernel_thread_helper+0x5/0x10
Leftover inexact backtrace:
 [<c0103b49>] show_stack_log_lvl+0xa9/0xd0
 [<c0103d56>] show_registers+0x1e6/0x270
 [<c0103f02>] die+0x122/0x2e0
 [<c0104158>] do_trap+0x98/0x100
 [<c0104b50>] do_invalid_op+0xa0/0xb0
 [<c010337d>] error_code+0x39/0x40
 [<c02d7a0e>] rt_spin_lock+0xe/0x50
 [<c0233e0a>] rtc_control+0x3a/0x80
 [<f89cc02b>] rtctimer_stop+0x2b/0x50 [snd_rtctimer]
 [<f88f5470>] snd_timer_interrupt+0x2b0/0x2f0 [snd_timer]
 [<f89cc139>] rtctimer_interrupt+0x19/0x20 [snd_rtctimer]
 [<c0234122>] rtc_interrupt+0x72/0x120
 [<c013e49e>] handle_IRQ_event+0x6e/0x100
 [<c013ea62>] thread_simple_irq+0x62/0xa0
 [<c013f377>] do_irqd+0x2a7/0x310
 [<c012a7c9>] kthread+0xe9/0xf0
 [<c0100e05>] kernel_thread_helper+0x5/0x10
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c02d856d>] .... __spin_lock_irqsave+0x1d/0x60
.....[<c02d7134>] ..   ( <= rt_spin_lock_slowlock+0x24/0x1e0)
.. [<c02d856d>] .... __spin_lock_irqsave+0x1d/0x60
.....[<c0103e22>] ..   ( <= die+0x42/0x2e0)

Code: 25 00 f0 ff ff 8b 00 c7 00 00 00 00 00 eb b7 c7 44 24 08 a1 02 00 00 c7 
44 24 04 dd 14 2f c0 c7 04 24 4d d1 2e c0 e8 81 ef e3 ff <0f> 0b a1 02 dd 14 
2f c0 e9 b6 fe ff ff 89 cf c7 45 a8 00 00 00 
EIP: [<c02d72af>] rt_spin_lock_slowlock+0x19f/0x1e0 SS:ESP 0068:f7d22e30
 <6>note: IRQ 8[651] exited with preempt_count 1
BUG: sleeping function called from invalid context IRQ 8(651) at 
fs/inode.c:247
in_atomic():1 [00000001], irqs_disabled():1
 [<c0103a8c>] show_trace_log_lvl+0x1ec/0x200
 [<c010420b>] show_trace+0x1b/0x20
 [<c0104276>] dump_stack+0x26/0x30
 [<c0110416>] __might_sleep+0xd6/0xf0
 [<c017dd9f>] clear_inode+0x1f/0x160
 [<c0198164>] proc_delete_inode+0x94/0xc0
 [<c017df5e>] generic_delete_inode+0x7e/0x120
 [<c017d88d>] iput+0x6d/0xa0
 [<c017b61b>] dentry_iput+0x7b/0xd0
 [<c017c592>] prune_one_dentry+0x62/0x90
 [<c017c83c>] prune_dcache+0x16c/0x190
 [<c017c98c>] shrink_dcache_parent+0xdc/0x120
 [<c019ab72>] proc_flush_task+0x62/0x210
 [<c0117d83>] release_task+0x1f3/0x3c0
 [<c011934d>] do_exit+0x71d/0xb10
 [<c01040b5>] die+0x2d5/0x2e0
DWARF2 unwinder stuck at die+0x2d5/0x2e0
Leftover inexact backtrace:
 [<c010420b>] show_trace+0x1b/0x20
 [<c0104276>] dump_stack+0x26/0x30
 [<c0110416>] __might_sleep+0xd6/0xf0
 [<c017dd9f>] clear_inode+0x1f/0x160
 [<c0198164>] proc_delete_inode+0x94/0xc0
 [<c017df5e>] generic_delete_inode+0x7e/0x120
 [<c017d88d>] iput+0x6d/0xa0
 [<c017b61b>] dentry_iput+0x7b/0xd0
 [<c017c592>] prune_one_dentry+0x62/0x90
 [<c017c83c>] prune_dcache+0x16c/0x190
 [<c017c98c>] shrink_dcache_parent+0xdc/0x120
 [<c019ab72>] proc_flush_task+0x62/0x210
 [<c0117d83>] release_task+0x1f3/0x3c0
 [<c011934d>] do_exit+0x71d/0xb10
 [<c01040b5>] die+0x2d5/0x2e0
 [<c0104158>] do_trap+0x98/0x100
 [<c0104b50>] do_invalid_op+0xa0/0xb0
 [<c010337d>] error_code+0x39/0x40
 [<c02d7a0e>] rt_spin_lock+0xe/0x50
 [<c0233e0a>] rtc_control+0x3a/0x80
 [<f89cc02b>] rtctimer_stop+0x2b/0x50 [snd_rtctimer]
 [<f88f5470>] snd_timer_interrupt+0x2b0/0x2f0 [snd_timer]
 [<f89cc139>] rtctimer_interrupt+0x19/0x20 [snd_rtctimer]
 [<c0234122>] rtc_interrupt+0x72/0x120
 [<c013e49e>] handle_IRQ_event+0x6e/0x100
 [<c013ea62>] thread_simple_irq+0x62/0xa0
 [<c013f377>] do_irqd+0x2a7/0x310
 [<c012a7c9>] kthread+0xe9/0xf0
 [<c0100e05>] kernel_thread_helper+0x5/0x10
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c02d856d>] .... __spin_lock_irqsave+0x1d/0x60
.....[<c02d7134>] ..   ( <= rt_spin_lock_slowlock+0x24/0x1e0)

prev->state: 2 != TASK_RUNNING??
IRQ 8/651[CPU#0]: BUG in __schedule at kernel/sched.c:3783
 [<c0103a8c>] show_trace_log_lvl+0x1ec/0x200
 [<c010420b>] show_trace+0x1b/0x20
 [<c0104276>] dump_stack+0x26/0x30
 [<c0116e3e>] __WARN_ON+0x5e/0x70
 [<c02d610d>] __schedule+0x61d/0x750
 [<c011923b>] do_exit+0x60b/0xb10
 [<c01040b5>] die+0x2d5/0x2e0
DWARF2 unwinder stuck at die+0x2d5/0x2e0
Leftover inexact backtrace:
 [<c010420b>] show_trace+0x1b/0x20
 [<c0104276>] dump_stack+0x26/0x30
 [<c0116e3e>] __WARN_ON+0x5e/0x70
 [<c02d610d>] __schedule+0x61d/0x750
 [<c011923b>] do_exit+0x60b/0xb10
 [<c01040b5>] die+0x2d5/0x2e0
 [<c0104158>] do_trap+0x98/0x100
 [<c0104b50>] do_invalid_op+0xa0/0xb0
 [<c010337d>] error_code+0x39/0x40
 [<c02d7a0e>] rt_spin_lock+0xe/0x50
 [<c0233e0a>] rtc_control+0x3a/0x80
 [<f89cc02b>] rtctimer_stop+0x2b/0x50 [snd_rtctimer]
 [<f88f5470>] snd_timer_interrupt+0x2b0/0x2f0 [snd_timer]
 [<f89cc139>] rtctimer_interrupt+0x19/0x20 [snd_rtctimer]
 [<c0234122>] rtc_interrupt+0x72/0x120
 [<c013e49e>] handle_IRQ_event+0x6e/0x100
 [<c013ea62>] thread_simple_irq+0x62/0xa0
 [<c013f377>] do_irqd+0x2a7/0x310
 [<c012a7c9>] kthread+0xe9/0xf0
 [<c0100e05>] kernel_thread_helper+0x5/0x10
---------------------------
| preempt count: 00000004 ]
| 4-level deep critical section nesting:
----------------------------------------
.. [<c02d856d>] .... __spin_lock_irqsave+0x1d/0x60
.....[<c02d7134>] ..   ( <= rt_spin_lock_slowlock+0x24/0x1e0)
.. [<c02d5b45>] .... __schedule+0x55/0x750
.....[<c011923b>] ..   ( <= do_exit+0x60b/0xb10)
.. [<c02d84a6>] .... __spin_lock_irq+0x16/0x60
.....[<c02d5be9>] ..   ( <= __schedule+0xf9/0x750)
.. [<c02d856d>] .... __spin_lock_irqsave+0x1d/0x60
.....[<c0116df1>] ..   ( <= __WARN_ON+0x11/0x70)





-- 
Palimm Palimm!
http://tapas.affenbande.org
From mista.tapas at gmx.net  Wed Oct 25 17:37:59 2006
From: mista.tapas at gmx.net (Florian Schmidt)
Date: Wed Oct 25 17:37:48 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <1161782352.22897.274184138@webmail.messagingengine.com>
References: <200610251835.47909.a_mulyadi@telkom.net>
	<1161782352.22897.274184138@webmail.messagingengine.com>
Message-ID: <200610252337.59259.mista.tapas@gmx.net>

On Wednesday 25 October 2006 15:19, Clemens Ladisch wrote:
> Mulyadi Santosa wrote:
> > I also read that not all Linux kernel sound card driver enable the
> > internal card timer, thus the software must rely on system timer.
>
> Most sound cards don't have an internal timer that could be used for
> MIDI timing.  ALSA uses whatever timer is configured, the default for
> this is the RTC timer.

if snd_rtctimer gets loaded, which for example isn't the case here on my 
debianbox. I suppose a modules.conf et.al entry should fix this though..

Flo


-- 
Palimm Palimm!
http://tapas.affenbande.org
From green at redhat.com  Wed Oct 25 18:15:42 2006
From: green at redhat.com (Anthony Green)
Date: Wed Oct 25 18:15:47 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <409841777-1161793993-cardhu_blackberry.rim.net-9458-@engine55.bwc.produk.on.blackberry>
References: <409841777-1161793993-cardhu_blackberry.rim.net-9458-@engine55.bwc.produk.on.blackberry>
Message-ID: <1161814543.2900.86.camel@localhost.localdomain>

On Wed, 2006-10-25 at 16:28 +0000, Chris Cannam wrote:
> Success -> play pointer moves smoothly
> Failure -> system locks up solid, reboot required. 

Success on Fedora Core 6 with the standard Fedora kernel, rosegarden4,
etc.

AG


From green at redhat.com  Thu Oct 26 11:24:01 2006
From: green at redhat.com (Anthony Green)
Date: Thu Oct 26 11:25:06 2006
Subject: [linux-audio-dev] Re: [ANN] FreeBoB 1.0 released - Firewire
	Audio for Linux
In-Reply-To: <ehlula$ijr$1@sea.gmane.org>
References: <45363352.5050705@joow.be>  <ehlula$ijr$1@sea.gmane.org>
Message-ID: <1161876241.2889.11.camel@localhost.localdomain>

On Tue, 2006-10-24 at 20:56 +0000, Carlo Capocasa wrote:
> Congratulations, Pieter. I had an opportunity to test it and it has far 
> surpassed my expectations. Meaning, it compiles, and it works! Kudos!

Agreed!  I've been using it with my presonus firebox. 

We've also packaged it up in Fedora Extras repository.  Fedora Core 6
users can just "yum install libfreebob", or let it come automatically as
a dependency of the jack-audio-connection-kit package.

AG


From dominique.michel at citycable.ch  Fri Oct 27 16:58:18 2006
From: dominique.michel at citycable.ch (Dominique Michel)
Date: Fri Oct 27 16:59:14 2006
Subject: [linux-audio-dev] about MIDI timing...
In-Reply-To: <409841777-1161793993-cardhu_blackberry.rim.net-9458-@engine55.bwc.produk.on.blackberry>
References: <409841777-1161793993-cardhu_blackberry.rim.net-9458-@engine55.bwc.produk.on.blackberry>
Message-ID: <20061027225818.75b5e2d6@localhost>

Le Wed, 25 Oct 2006 16:28:28 +0000 GMT,
"Chris Cannam" <chris.cannam@ferventsoftware.com> a ?crit :

> Me:
> > I'm not aware of anyone these days successfully 
> > using Rosegarden with snd-rtctimer - if anyone out
> > there is, do say so.
> 
> To test:
> 
> * start RG (version 1.0 or newer)
> * go to Settings -> Configure Rosegarden -> Sequencer -> Synchronisation
> * change the sequencer timing source option to RTC
> * close configuration window, press play. 
> 
> It probably doesn't matter whether you have a file
> loaded or not. 
> 
> Success -> play pointer moves smoothly
> Failure -> system locks up solid, reboot required. 
> 
> If it does lock up, you may need to edit your 
> rosegardenrc to restore the timer setting before 
> you can run RG again. 
> 
> 
> Chris

No problem with 2.6.16-rt29 and the realtime-lsm on gentoo 2006.1
I try both with the NVIDIA driver (1.9.9626) and with the nv driver (1.2.0,
xorg 7.1), same success.

I know from other peoples using the gentoo pro-audio overlay at it was a
stability problem with the 2.6.17-rt8, but it was no such report with the other
2.6.17-rt* or the 2.6.18-rt* kernels.

The 2.6.16-rt29 work just fine for me, and I am not stressed to upgrade it.

-- 
Dominique Michel

--
N.B.: Tous les emails que je re?ois sont filtr?s par spamassassin avant de me
parvenir.

Si vous attendez une r?ponse de ma part et que vous ne la recevez pas, cela
signifie que, en toute vraisemblance, votre courrier ne m'est pas parvenu car
vous figurez sur une des listes de http://www.spamhaus.org.
From fons.adriaensen at skynet.be  Sun Oct 29 18:57:48 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Sun Oct 29 18:55:46 2006
Subject: [linux-audio-dev] Multiplexing 4 channels on SPDIF
Message-ID: <20061029235748.GF6000@linux-1.site>

Hello all,

Core Sound <http://www.core-sound.com/default.php> willsoon
be offering a tetrahedral (Ambisonic) microphone at a very
reasonable price. They are also working on a combined preamp
+ AD converter unit for this mic. This will be able to multiplex
the 4 channels over a single SPDIF link, by using it a the
double sample frequency.

I'm currently working on a software controller unit for this
microphone. It will perform A-format to B-format conversion,
and allow measured impulse responses to be used for calibrating
the four mics. The result should be a very high quality portable
surround recording system at a reasonable price (compared to other
solutions which cost easily five times as much).

The remaining problem is the demultiplexing of the two double
speed SPDIF channels to four channels. It could either be done
within the ALSA layer, or in JACK's ALSA backend. Doing this
in a JACK client will not work unless it would be the only
client - all others would get the wrong idea of the sample
frequency and buffer size. 

So here's my question to both the ALSA and JACK teams: what
would be your idea of a solution for this ?

-- 
FA

Lascia la spina, cogli la rosa.

From jussi.laako at pp.inet.fi  Mon Oct 30 06:40:16 2006
From: jussi.laako at pp.inet.fi (Jussi Laako)
Date: Mon Oct 30 06:40:42 2006
Subject: [linux-audio-dev] Re: [Jackit-devel] Multiplexing 4 channels on
	SPDIF
In-Reply-To: <20061029235748.GF6000@linux-1.site>
References: <20061029235748.GF6000@linux-1.site>
Message-ID: <4545E4A0.1030606@pp.inet.fi>

Fons Adriaensen wrote:
> Core Sound <http://www.core-sound.com/default.php> willsoon
> be offering a tetrahedral (Ambisonic) microphone at a very
> reasonable price. They are also working on a combined preamp
> + AD converter unit for this mic. This will be able to multiplex

Sounds nice :)

> So here's my question to both the ALSA and JACK teams: what
> would be your idea of a solution for this ?

Some ALSA plugin? Of course, doing it in JACK's ALSA backend is also
reasonably simple, but would require small changes in many places to
override samplerates, etc.


	- Jussi
From ico at vt.edu  Mon Oct 30 08:58:37 2006
From: ico at vt.edu (Ivica Ico Bukvic)
Date: Mon Oct 30 08:58:58 2006
Subject: [linux-audio-dev] Linuxaudio.org -- call for new member projects
Message-ID: <001d01c6fc2b$814c1c80$0302a8c0@64BitBadass>

Apologies for cross-posting. Please forward the announcement to your
respective lists (if applicable).

Yes, it's that time of the year. In our continued bi-monthly track of
membership drives, I would like to extend an open invitation to all Linux
audio projects who are not already a member of the consortium to consider
joining and therefore help us continue our efforts at consolidation of Linux
audio resources. The membership is free and the consortium's structure
allows members to gauge their level of involvement and subsequently the time
overhead it bears.

In the recent months there have been a number of exciting new projects
introduced to the Linux audio scene. This is very encouraging as it suggests
not only continued, but also growing vitality of our platform of choice.
Linuxaudio.org's mission is to help maintain this vitality by offering
various programs to its membership base as well as the entire Linux audio
community. Perhaps one of the most important programs is our mission to
consolidate Linux audio resources and by doing so foster collaboration as
well as connections with the commercial industry and outside investors. For
this reason, I sincerely hope that you will consider joining the consortium.

For more info on the membership, benefits, etc. please visit linuxaudio.org.
We have our next new member announcement set for this coming Thursday
November 2nd.

Should you happen to have any additional questions and/or concerns, please
do not hesitate to contact me.

Best wishes,

Ivica Ico Bukvic, D.M.A.
Linuxaudio.org Director
Virginia Tech
Department of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
ico@linuxaudio.org
http://www.music.vt.edu/people/faculty/bukvic



From k.s.matheussen at notam02.no  Mon Oct 30 09:39:12 2006
From: k.s.matheussen at notam02.no (Kjetil S. Matheussen)
Date: Mon Oct 30 09:39:28 2006
Subject: [linux-audio-dev] [ANN] Vmwaredspjack 1.3,
	Snd-ls 0.9.7.6 and Jack_capture V0.3.8
Message-ID: <Pine.LNX.4.64.0610301527160.6583@ttleush>


Vmwaredspjack
=============
This is the vmwaredsp program, made by Petr Vandrovec, which makes vmware 
work with esd or arts. This version adds jack support as well.
(Unfortunately, jacklaunch (which is a similar program) doesn't work with 
vmware, but I think Gunter is working on it... :-) .)

The program isn't always working that well, but if used with care 
(don't trust the output too much) and proper tuning, you can use 
professional windows audio software in vmware using jack for audio 
communication.

Download from http://www.notam02.no/arkiv/src/



Snd-ls v0.9.7.6
===============
Snd-ls is a distribution of Bill Schottstaedt's sound editor SND.
Its target is people that don't know scheme very well, and don't want
to spend too much time configuring Snd. It can also serve
as a quick introduction to Snd and how it can be set up.

Changes 0.9.7.1 -> 0.9.7.6:
---------------------------
-Proper debug output in case startup fails.
-Fixed bug in jack audio.
-Temporary remove the fft menu because its not working with the 26.9.2006
  version of Snd. Bug found by Dragan Noveski.
-Check for the existence of the sndfile.h header file before compiling.
  If it doesn't exist, snd-ls will refuse to run. Problem reported by
  Krzusztof Gawlas.
-Make sure snd starts up even if no file was loaded during startup. Bug
  found by Dragan Noveski.
-Really apply the workaround for the menu problem.

Download from http://www.notam02.no/arkiv/src/snd/




Jack_capture V0.3.8
===================
jack_capture is a small program to capture whatever
sound is going out to your speakers into a file.

This is the program I always wanted to have for jack, but no
one made. So here it is.

Changes 0.3.7 -> 0.3.8:
-----------------------
*Added the --recording-time option to stop recording after a certain
  number of seconds.
*Quitting with CTRL-C/SIGINT writes remaining buffer to disk before
  ending program.

Download from http://www.notam02.no/arkiv/src/


From rlrevell at joe-job.com  Mon Oct 30 10:07:06 2006
From: rlrevell at joe-job.com (Lee Revell)
Date: Mon Oct 30 10:07:02 2006
Subject: [linux-audio-dev] Re: [Jackit-devel] Multiplexing 4 channels
	on SPDIF
In-Reply-To: <4545E4A0.1030606@pp.inet.fi>
References: <20061029235748.GF6000@linux-1.site> <4545E4A0.1030606@pp.inet.fi>
Message-ID: <1162220827.14733.113.camel@mindpipe>

On Mon, 2006-10-30 at 13:40 +0200, Jussi Laako wrote:
> Fons Adriaensen wrote:
> > Core Sound <http://www.core-sound.com/default.php> willsoon
> > be offering a tetrahedral (Ambisonic) microphone at a very
> > reasonable price. They are also working on a combined preamp
> > + AD converter unit for this mic. This will be able to multiplex
> 
> Sounds nice :)
> 
> > So here's my question to both the ALSA and JACK teams: what
> > would be your idea of a solution for this ?
> 
> Some ALSA plugin? Of course, doing it in JACK's ALSA backend is also
> reasonably simple, but would require small changes in many places to
> override samplerates, etc.

I don't think it even needs to be a plugin, just tell ALSA about the
audio format.  Where can the detailed specs be downloaded?

Lee

From fons.adriaensen at alcatelaleniaspace.com  Mon Oct 30 11:35:46 2006
From: fons.adriaensen at alcatelaleniaspace.com (Alfons Adriaensen)
Date: Mon Oct 30 11:36:17 2006
Subject: [linux-audio-dev] Re: [Jackit-devel] Multiplexing 4 channels on
	SPDIF
In-Reply-To: <1162220827.14733.113.camel@mindpipe>
References: <20061029235748.GF6000@linux-1.site> <4545E4A0.1030606@pp.inet.fi>
	<1162220827.14733.113.camel@mindpipe>
Message-ID: <20061030163546.GB9886@bth05w.ABSp.alcatel.be>

On Mon, Oct 30, 2006 at 10:07:06AM -0500, Lee Revell wrote:

> > Some ALSA plugin? Of course, doing it in JACK's ALSA backend is also
> > reasonably simple, but would require small changes in many places to
> > override samplerates, etc.
> 
> I don't think it even needs to be a plugin, just tell ALSA about the
> audio format.

How can you tell ALSA that an SPDIF input is 4 channels ?

> Where can the detailed specs be downloaded?

According to the Core Sound website this thing is still in development,
and the specs there are incomplete. 

What they want to do is trick  hardware 2-ch recorders into accepting
the 4-ch signal. So what is in reality 4 channels at 48 kHz will be
presented as 2 channels at 96 kHz.

 
-- 
FA

Lascia la spina, cogli la rosa.
From rlrevell at joe-job.com  Mon Oct 30 11:41:36 2006
From: rlrevell at joe-job.com (Lee Revell)
Date: Mon Oct 30 11:41:34 2006
Subject: [Jackit-devel] [linux-audio-dev] Re: Multiplexing 4 channels
	on SPDIF
In-Reply-To: <20061030163546.GB9886@bth05w.ABSp.alcatel.be>
References: <20061029235748.GF6000@linux-1.site>
	<4545E4A0.1030606@pp.inet.fi> <1162220827.14733.113.camel@mindpipe>
	<20061030163546.GB9886@bth05w.ABSp.alcatel.be>
Message-ID: <1162226496.27037.9.camel@mindpipe>

On Mon, 2006-10-30 at 17:35 +0100, Alfons Adriaensen wrote:
> On Mon, Oct 30, 2006 at 10:07:06AM -0500, Lee Revell wrote:
> 
> > > Some ALSA plugin? Of course, doing it in JACK's ALSA backend is also
> > > reasonably simple, but would require small changes in many places to
> > > override samplerates, etc.
> > 
> > I don't think it even needs to be a plugin, just tell ALSA about the
> > audio format.
> 
> How can you tell ALSA that an SPDIF input is 4 channels ?
> 

The ALSA code would have to be extended... I'm not sure exactly where.

I don't think it should be called SPDIF because SPDIF implies two
channels.

> > Where can the detailed specs be downloaded?
> 
> According to the Core Sound website this thing is still in development,
> and the specs there are incomplete. 
> 
> What they want to do is trick  hardware 2-ch recorders into accepting
> the 4-ch signal. So what is in reality 4 channels at 48 kHz will be
> presented as 2 channels at 96 kHz.
> 

I don't think it's useful to discuss further until technical details are
available.

When specs are available, this thread should probably be re-started on
alsa-devel.

Lee

From fons.adriaensen at skynet.be  Mon Oct 30 12:52:34 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Mon Oct 30 12:50:32 2006
Subject: [Jackit-devel] [linux-audio-dev] Re: Multiplexing 4 channels	on
	SPDIF
In-Reply-To: <1162226496.27037.9.camel@mindpipe>
References: <20061029235748.GF6000@linux-1.site> <4545E4A0.1030606@pp.inet.fi>
	<1162220827.14733.113.camel@mindpipe>
	<20061030163546.GB9886@bth05w.ABSp.alcatel.be>
	<1162226496.27037.9.camel@mindpipe>
Message-ID: <20061030175233.GA5949@linux-1.site>

On Mon, Oct 30, 2006 at 11:41:36AM -0500, Lee Revell wrote:

> On Mon, 2006-10-30 at 17:35 +0100, Alfons Adriaensen wrote:
>
> > What they want to do is trick  hardware 2-ch recorders into accepting
> > the 4-ch signal. So what is in reality 4 channels at 48 kHz will be
> > presented as 2 channels at 96 kHz.
> > 
> I don't think it's useful to discuss further until technical details are
> available.

What do you need more than what is available on http://www.core-sound.com/4Mic/2.php ?

It doesn't say how the multiplexing is done, but that's probably easy enough to
find out and is not the real problem. Probably it's just alternating channels,
but I will ask them. Everything else is there AFAICS.

The real question is how to fit this into the existing architecture:

  -  hardware presents itself as 2 * 96 kHz
  -  user wants to see a device with 4 * 48 kHz.

Is there any online documentation on how to write ALSA plugins ?

-- 
FA

Lascia la spina, cogli la rosa.

From rlrevell at joe-job.com  Mon Oct 30 13:30:53 2006
From: rlrevell at joe-job.com (Lee Revell)
Date: Mon Oct 30 13:30:54 2006
Subject: [Jackit-devel] [linux-audio-dev] Re: Multiplexing 4
	channels	on SPDIF
In-Reply-To: <20061030175233.GA5949@linux-1.site>
References: <20061029235748.GF6000@linux-1.site>
	<4545E4A0.1030606@pp.inet.fi> <1162220827.14733.113.camel@mindpipe>
	<20061030163546.GB9886@bth05w.ABSp.alcatel.be>
	<1162226496.27037.9.camel@mindpipe>
	<20061030175233.GA5949@linux-1.site>
Message-ID: <1162233053.27037.27.camel@mindpipe>

On Mon, 2006-10-30 at 18:52 +0100, Fons Adriaensen wrote:
> The real question is how to fit this into the existing architecture:
> 
>   -  hardware presents itself as 2 * 96 kHz
>   -  user wants to see a device with 4 * 48 kHz.

> Is there any online documentation on how to write ALSA plugins ? 

No, ask on the ALSA list.

Lee

From paul at linuxaudiosystems.com  Mon Oct 30 14:55:33 2006
From: paul at linuxaudiosystems.com (Paul Davis)
Date: Mon Oct 30 14:56:14 2006
Subject: [Jackit-devel] [linux-audio-dev] Re: Multiplexing 4	channels	on
	SPDIF
In-Reply-To: <20061030175233.GA5949@linux-1.site>
References: <20061029235748.GF6000@linux-1.site>	<4545E4A0.1030606@pp.inet.fi>
	<1162220827.14733.113.camel@mindpipe>
	<20061030163546.GB9886@bth05w.ABSp.alcatel.be>
	<1162226496.27037.9.camel@mindpipe>
	<20061030175233.GA5949@linux-1.site>
Message-ID: <1162238133.2714.41.camel@localhost.localdomain>

On Mon, 2006-10-30 at 18:52 +0100, Fons Adriaensen wrote:

> 
>   -  hardware presents itself as 2 * 96 kHz
>   -  user wants to see a device with 4 * 48 kHz.

interestingly, ADAT devices do the opposite to get to SR's above 48kHZ:

	- hardware runs as N * 48 kHz channels
        - data is multiplexed across 2 channels at once
	- user sees N/2 channels at 96kHz

this is not done with ALSA plugins, but in the driver.

note that JACK wants if possible to sit close to the h/w, so an ALSA
plugin is not ideal. JACK uses mmap to read/write data from/to the
device, so the work of an ALSA plugin is hard ...

--p


From fons.adriaensen at skynet.be  Mon Oct 30 15:26:58 2006
From: fons.adriaensen at skynet.be (Fons Adriaensen)
Date: Mon Oct 30 15:24:55 2006
Subject: [Jackit-devel] [linux-audio-dev] Re: Multiplexing 4	channels	on
	SPDIF
In-Reply-To: <1162238133.2714.41.camel@localhost.localdomain>
References: <20061029235748.GF6000@linux-1.site> <4545E4A0.1030606@pp.inet.fi>
	<1162220827.14733.113.camel@mindpipe>
	<20061030163546.GB9886@bth05w.ABSp.alcatel.be>
	<1162226496.27037.9.camel@mindpipe>
	<20061030175233.GA5949@linux-1.site>
	<1162238133.2714.41.camel@localhost.localdomain>
Message-ID: <20061030202658.GB5949@linux-1.site>

On Mon, Oct 30, 2006 at 02:55:33PM -0500, Paul Davis wrote:
> On Mon, 2006-10-30 at 18:52 +0100, Fons Adriaensen wrote:
> 
> > 
> >   -  hardware presents itself as 2 * 96 kHz
> >   -  user wants to see a device with 4 * 48 kHz.
> 
> interestingly, ADAT devices do the opposite to get to SR's above 48kHZ:
> 
> 	- hardware runs as N * 48 kHz channels
>         - data is multiplexed across 2 channels at once
> 	- user sees N/2 channels at 96kHz
> 
> this is not done with ALSA plugins, but in the driver.
> 
> note that JACK wants if possible to sit close to the h/w, so an ALSA
> plugin is not ideal. JACK uses mmap to read/write data from/to the
> device, so the work of an ALSA plugin is hard ...

Yes, there should be as little as possible between JACK and the
hardware. But providing a memory mapped interface should not be
too difficult. Maybe it's even easier than any other one - all
the plugin needs to do is provide a pointer to its own buffers
using ALSA's mmapped API. 

BTW, it has for long been my opinion that there is no need for
ALSA to provide anything else than the mmapped interface. 

The other solution (which I would not dislike) is to do the
demuxing in JACK's backend. 

-- 
FA

Lascia la spina, cogli la rosa.