Happy new year to you all!
I just wanted to remind you all that the deadline (8th of January) for the
LAC2007 is getting nearer, so now is the time to still write that paper, mail
that cd, or make that proposition for that tutorial.
Detailed info:
http://www.kgw.tu-berlin.de/~lac2007/index.shtml
Sincerely,
On behalf of the Linux Audio Conference 2007 Orga Team,
Marije Baalman
Hello all,
First of all, my best wishes for 2007 to all Linux Audio Developers !
2007 will be a special year for me. As some of you already know, I said goodbey
at Alcatel Space two months ago, and starting 8 Jan 2007 I'll be working at LAE
- Laboratorio di Acustica ed Elettroacustica - <http://www.laegroup.org/> in
Parma, Italy. LAE is an acoustics and electro-acoustics research and consultancy
lab operated by the university of Parma and by three companies active in the area
of acoustics and audio. My activities in LAD will continue of course, after maybe
a short break while the dust of moving to Italy settles.
Looking forward to meet you all at LAC2007 in Berlin !
--
FA
Lascia la spina, cogli la rosa.
Hi.
I just tried to get sound working on a LinkSys NSLU2 (ARM) running
Debian Etch using a USB sound card.
What I discovered I find pretty strange, and would like to know some
more details. Apparently, all ALSA native clients don't
manage to play sound click-free, they actually have underruns all the
time. However, if I use OSS (via the snd-pcm-oss module) and set
libao to use the oss driver, I get perfect playback with about
20% CPU use at maxiumum by the user-space app playing/decoding files.
This is a bit strange, isn't it. OSS-emulation actually uses the same
kernel code to access the actual hardware. I am just very vaguely
familiar with the whole ALSA architecture, but it feels as if
the problem here actually lies inside the user-space alsa libraries?
Did anyone ever see such an effect, and investigate more closely
what is the reason for the difference?
--
CYa,
Mario | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang(a)db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
Greetings:
My ancient 800 MHz machine has dead PS/2 ports so I plugged my mouse and
keyboard into its available USB ports. Alas, the keyboard disappears
after selecting my kernel image (Demudi) in grub. I'm away from the
machine right now so I don't have the exact text of the error message.
However, I do recall that it refers to a USB-related IRQ error.
I tried to install the 32-bit version of 64Studio, but the error occurs
during the configuration process: As soon as I press Enter at the boot
prompt the keyboard is no longer present to the system. :(
I Googled for some more information regarding the problem and found that
it is in fact a known issue. However, none of the proposed solutions
worked for me. I also sent messages to the 64Studio dev list and to Free
and Daniel, but I've heard nothing back from them or the list (I think
my email to the list isn't getting there).
One thing does work: Dynebolic includes a nohid boot parameter that does
the trick ('linux nohid'), so I can still boot into the machine and
access my data. So, my question is: What's Dynebolic doing that the
other distros aren't ? I'd surely like to boot directly into my system,
and I'd like to install 32-bit 64Studio, but I can't do either until I
solve this problem.
Any suggestions ?
Best,
dp
I understand that LADSPA and friends specifically exclude any
functionality around how to find and load plugins, but it seems that a
lot can be gained by introducing some standards in this area.
As a package of audio apps/plugins for a Linux distro, here are two of
the problems I see:
1. Applications are often hard-coded to look in /usr/lib/ladspa (for
instance), when many systems may require that libraries live somewhere
else (like /usr/lib64/ladspa for x86-64, or /usr/lib32/ladspa for
n32-ABI MIPS Linux). I've had to patch a lot of apps for x86-64 Fedora.
2. We build binaries for the lowest common denominator, so the plugins
you'll find in Fedora, for instance, don't take advantage of SSE
hardware or instruction scheduling for different processors. This can
make a huge difference. What would be nice is if we could distribute an
RPM containing a plurality of plugin builds, and then have the
application load the plugin matching the capabilities the execution
platform.
Has there been any discussion around creating a plugin locator/loader
library? It would be nice if one could be written and then widely
adopted by app writers. (I'm not volunteering!)
AG
> Message: 3
> Date: Thu, 21 Dec 2006 21:19:04 +0000
> From: iain(a)g7iii.net (Iain Young)
> Subject: [linux-audio-dev] LADSPA_Data audio values
> To: linux-audio-dev(a)music.columbia.edu
> Message-ID: <20061221211903.GA14158(a)g7iii.net>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
>
> I'm trying to write a LADSPA plugin to do the following:
>
> Given n inputs (lets say 4), and one output, It should present the
> highest "priority" input on the output. Input 1 is the lowest priority,
> with Input 4 being the highest.
>
> In order to write this in code, within the runPriomux function, I do
> this:
>
> y=-1;
> for (i=0; i<=3; i++)
> {
> pfBuffer=*(pfInput[i]++);
> if (pfBuffer > -1.0f)
> y=i;
> }
> if (y!=-1)
> *(pfOutput++)=pfBuffer;
>
>
Hi Iain,
I don't know your application, but this looks wrong. If you are trying
to choose between various microphones, and only output the microphone
with the highest priority that has audio on it, (i.e. an automixer),
then you're going to have to do a bit more work than this.
Here are the immediate problems I see (Chris Cannam already indicated
the first 2)
1) 0.0f indicates silence, not -1.0f
2) A microphone input will have some noise on it, you'll need an
adjustable threshold value which separates the "on" state from the "off"
3) You can't do this on a sample-by-sample basis, you need some time
averaging:
3a) you need to implement a rectified, running average value of all 4
inputs
3b) you'll need to mix the values of all four buffers into the output,
with a smoothly changing level control on each input controlled by the logic
4) Make sure the "decay" of the envelope is kinda long ...this will
keep a speaker from getting cut off if someody else coughs or whatever
There are other subtleties that apply to an automixer, but this is
enough to get started.
-Ben Loftis
Download from http://www.notam02.no/arkiv/src/
das_watchdog 0.2.5
==================
Whenever a program locks up the machine, das_watchdog will temporarily
sets all realtime process to non-realtime for 8 seconds. You will get an
xmessage window up on the screen whenever that happens.
Changes 0.2.4->0.2.5
--------------------
*Let the test thread run with SCHED_FIFO priority using the
lowest priority. Should hopefully stop all the unnecessary reports.
(This change has been tested quite thoroughly)
jack_capture v0.9.3
===================
jack_capture is a program for recording soundfiles with jack. Its default
operation is to capture whatever sound is going out to your speakers into
a file. This is the program I always wanted to have for jack, but no
one made. So here it is.
Note: Anyone using 0.9.2 should upgrade to 0.9.3! 0.9.2 will most likely
hang during startup. :-(
(I'm going to start testing my software before releasing from now
on, this one was very embarrasing.)
Distros: If there is a system for doing so, you should mark 0.9.2 as
unusable.
Changes 0.3.9 -> 0.9.3
-----------------------
*Fixed horrible deadlock in 0.9.2. Bug found by Ken Restivo.
*Fix for a potensional deadlock.
*Added the --silent/-s argument.
*Some smaller fixes.
*If recording to wav (the default) and the the 4GB limitation is reached,
automatically close the file and continue writing to a new file with an
autogenerated name.
*Added the --version/-v argument.
*Changed default number of zeros in the autogenerated filename to 1.
*Better error output.
*Autogenerate code to check if various formats are supported by sndlibfile.
*Bumped version up to 0.9. jack_capture should reach a 1.0 state quite
soon.
*Changed the name of --recording-time to --duration to match -d.
Hi All,
I'm trying to write a LADSPA plugin to do the following:
Given n inputs (lets say 4), and one output, It should present the
highest "priority" input on the output. Input 1 is the lowest priority,
with Input 4 being the highest.
In order to write this in code, within the runPriomux function, I do
this:
y=-1;
for (i=0; i<=3; i++)
{
pfBuffer=*(pfInput[i]++);
if (pfBuffer > -1.0f)
y=i;
}
if (y!=-1)
*(pfOutput++)=pfBuffer;
i is the input channel (0-3, not 1-4, but you know what I mean)
y is what is supposed to be the highest priority channel with audio
on it.
Now..here's where Im confused. I thought the values for audio samples
in LADSPA were -1.0f...1.0f (with -1.0f being infinity). This doesn't
seem to work, as the above code always appears to think that the 4th
input (i=3) has data on it, even if it's muted in ardour (via another
bus that's single output is connected to input 4...)
I've also looked at the code of meterbridge, and tried using -70.0f,
but with the same problem...Anyone want to plant me a clue on what
I'm doing wrong ?
I've attached the entire plugin source below. It's really been ripped
off of the example amp in the LADSPA SDK I'm afraid....
Thanks in advance for any help, this last bit is driving me mad, now
I've worked out how to code plugins!
All the Best
Iain
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
31st International AES Conference - New Directions in High Resolution Audio
June 25-27, 2007
London, UK
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Submissions site now open! Please let the conference organizers know of your
intent to contribute or attend. Further detail available at
http://www.aes.org/events/31/
The 31st International Audio Engineering Society Conference, entitled New
Directions in High Resolution Audio, will be held at Queen Mary, University
of London, from June 25th-27th, 2007.
This Conference is concerned with the promotion and delivery of high
resolution audio, by maintaining quality throughout the recording and
playback chain with current and future technologies. It reflects the
tremendous recent growth of high resolution audio techniques and products
intended for use throughout the audio recording and playback chain. However,
issues remain on how to avoid bottlenecks where quality is compromised, and
how to maintain and encourage high resolution audio in an everchanging
marketplace. These concerns are of interest to the audio engineering,
recording and production industries, as well as to education and academia.
We aim to provide a place for the exchange of news, issues and results, by
bringing together researchers , developers, educators, students and
professional users, working in fields that contribute to high resolution
audio, to present original theoretical or practical work. It also serves as
a discussion forum, provides introductory and in-depth information in
specific domains, and showcases current products.
The 31st AES Conference solicits contributions to the field of high
resolution audio, including, but not limited to, the following domains and
topics:
High resolution recording issues
* Bandwidth, sampling rate, dynamic resolution and spatial representation.
* Analog and digital recording equipment
Processing, manipulation and preparation of high resolution signals
* High quality analog design
* A/D and D/A conversion
* Format and sample rate interconversions
* High-resolution signal processing, 1 to n bit paradigms
* Spatial audio, virtual and acoustic spaces, virtual image manipulation
Storage of high resolution audio
* Current and future storage technology for high-density audio data
* Overview of high resolution consumer formats
* Copy protection
* Access speed, data reliability, bit packing and compression
* Professional archival formats and future-proofing
Electronic delivery of high resolution audio
* Network (wired and wireless) systems/delivery of high quality audio
content
* Current and future formats for streaming and file delivery of high
resolution audio
* Bandwidth
* Digital radio and broadcast applications including multichannel audio
Maintaining quality at playback
* Evolving technology for multiformat players
* PC-based playback: configuration and interfacing
* Converter technologies
* Jitter/interface/power supplies and other related forms of noise
* Digital amplification e.g., Class-D amplifiers
Perception
* Perceptual modeling.
* Objective evaluation and subjective performance of high-resolution audio
* Objective measurement and resolution issues
* Subjective procedures and evaluation psychology
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SUBMISSIONS
Submissions, which will be peer-reviewed, may be in the following
categories:
- paper (to be presented in the main sessions)
- poster or demonstration (to be presented in the poster sessions)
- original composition demonstrating features of high resolution audio (to
be showcased throughout the conference)
- tutorial, panel or workshop proposals (see conference web site for
details)
Recording companies. publishers, software and hardware developers, etc., are
invited to contact the programme committee regarding exhibition space.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DEADLINES
Deadline for submissions of tutorials, panels and workshops: Feb. 2nd 2007.
Deadline for submissions of papers and posters/demos: Feb. 2nd 2007.
Deadline for exhibitor space: June 1st 2007.
Please see the conference website for more information;
http://www.aes.org/events/31/