Hi,
I'm trying to do a simple effect in the frequency domain, nothing extraordinary.
I need to apply various gains to specific frequencies.
For this purpose, I want to process a 16bit audio input stream, block by block,
apply a hanning window, do a fft, now apply my effect, and then an inverse fft,
followed by overlap and add buffering.
For now, I'm simply trying to do all of this without applying any effect, just
to see if my time to frequency and back conversion is correct.
I managed to do this in Octave. Now, I'm trying to do it in C with fftw and the
sound I obtain is like "shivering". It's recognizable but severely altered. I've
spent hours on this, it just won't work.
Attached :
- freqfilter.m: my working octave version
- transform.h and transform.c: time -> frequency -> time routines
- transformtest.c: test program
Could anyone tell me what's wrong with this C code?
Thanks in advance
--
Olivier
Hi Nedko :)
today I tried to compile LADI, but it failed for openSuse 11.2 x86_64
and 64 Studio 3.0-beta3 x86_64. Please take a look at the attachments.
Cheers,
Ralf
suse11-2:/usr/src/ladish-0.1/flowcanvas # ./waf configure
Checking for program gcc : ok /usr/bin/gcc
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for gcc : ok
Checking for program g++ : ok /usr/bin/g++
Checking for g++ : ok
Checking for libgvc >= 2.8 : ok
Checking for gtkmm-2.4 >= 2.10.0 : ok
Checking for libgnomecanvasmm-2.6 >= 2.6.0 : ok
Checking for header boost/shared_ptr.hpp : ok
Checking for header boost/weak_ptr.hpp : ok
Global configuration
Install prefix : /usr/local
Debuggable build : False
Strict compiler flags : False
Build documentation : False
FlowCanvas Configuration
Auto-arrange : True
Anti-Aliasing : True
'configure' finished successfully (0.730s)
suse11-2:/usr/src/ladish-0.1/flowcanvas # ./waf
[snip]
'build' finished successfully (15.788s)
suse11-2:/usr/src/ladish-0.1/flowcanvas # ./waf install
[snip]
'install' finished successfully (0.074s)
suse11-2:/usr/src/ladish-0.1/flowcanvas # cd ..
suse11-2:/usr/src/ladish-0.1 # ./waf configure
[snip]
Install prefix : /usr/local
Build liblash : no
WARNING: D-Bus session services directory as reported by pkg-config is
WARNING: /usr/share/dbus-1/services
WARNING: but service file will be installed in
WARNING: /usr/local/share/dbus-1/services
WARNING: You may need to adjust your D-Bus configuration after installing jackdbus
WARNING: You can override dbus service install directory
WARNING: with --enable-pkg-config-dbus-service-dir option to this script
'configure' finished successfully (1.034s)
suse11-2:/usr/src/ladish-0.1 # ./waf configure --prefix=/usr
Checking for program gcc : ok /usr/bin/gcc
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for gcc : ok
Checking for program g++ : ok /usr/bin/g++
Checking for g++ : ok
Checking for dbus-1 >= 1.0.0 : ok
Retrieving D-Bus services dir : ok
Checking for uuid : ok
Checking for header expat.h : ok
Checking for glib-2.0 : ok
Checking for dbus-glib-1 : ok
Checking for gtk+-2.0 : ok
Checking for libglade-2.0 : ok
Checking for flowcanvas >= 0.4.0 : ok
boost headers : Version 1_39 (/usr/include)
==================
ladish-0.1 exported from 0d1ac13dd396785602ea157b5acb12f81da17b63
Install prefix : /usr
Build liblash : no
'configure' finished successfully (0.745s)
suse11-2:/usr/src/ladish-0.1 # ./waf
Waf: Entering directory `/usr/src/ladish-0.1/build'
[ 1/41] cxx: gui/canvas.cpp -> build/default/gui/canvas_3.o
[ 2/41] copy: daemon/dbus.service.in -> build/default/org.ladish.service
[ 3/41] git_ver: -> build/default/version.h
tarball from git revision 0d1ac13dd396785602ea157b5acb12f81da17b63
[ 4/41] cc: jack_proxy.c -> build/default/jack_proxy_1.o
[ 5/41] cc: catdup.c -> build/default/catdup_1.o
cc1: warnings being treated as errors
../jack_proxy.c: In function ‘jack_proxy_set_parameter_value’:
../jack_proxy.c:588: error: ‘type’ may be used uninitialized in this function
Waf: Leaving directory `/usr/src/ladish-0.1/build'
Build failed
-> task failed (err #1):
{task: cc jack_proxy.c -> jack_proxy_1.o}
suse11-2:/usr/src/ladish-0.1 #
root@64studio:/usr/src/ladish-0.1/flowcanvas# ./waf configure
Checking for program gcc : ok /usr/bin/gcc
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for gcc : ok
Checking for program g++ : ok /usr/bin/g++
Checking for g++ : ok
Checking for libgvc >= 2.8 : ok
Checking for gtkmm-2.4 >= 2.10.0 : ok
Checking for libgnomecanvasmm-2.6 >= 2.6.0 : ok
Checking for header boost/shared_ptr.hpp : ok
Checking for header boost/weak_ptr.hpp : ok
Global configuration
Install prefix : /usr/local
Debuggable build : False
Strict compiler flags : False
Build documentation : False
FlowCanvas Configuration
Auto-arrange : True
Anti-Aliasing : True
'configure' finished successfully (1.610s)
root@64studio:/usr/src/ladish-0.1/flowcanvas# ./waf
Waf: Entering directory `/usr/src/ladish-0.1/flowcanvas/build'
[1/9] cxx: src/Canvas.cpp -> build/default/src/Canvas_2.o
[2/9] cxx: src/Connectable.cpp -> build/default/src/Connectable_2.o
In file included from /usr/include/graphviz/gvc.h:20,
from ../src/Canvas.cpp:32:
/usr/include/graphviz/types.h:26:1: warning: "FALSE" redefined
In file included from /usr/lib/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:30,
from /usr/include/glib-2.0/glib/galloca.h:30,
from /usr/include/glib-2.0/glib.h:30,
from /usr/include/glib-2.0/gobject/gtype.h:26,
from /usr/include/glib-2.0/gobject/gboxed.h:26,
from /usr/include/glib-2.0/glib-object.h:25,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:31,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:24,
from /usr/include/glibmm-2.4/glibmm.h:27,
from /usr/include/gtkmm-2.4/gtkmm.h:29,
from /usr/include/libgnomecanvasmm-2.6/libgnomecanvasmm.h:29,
from ../flowcanvas/Canvas.hpp:24,
from ../src/Canvas.cpp:27:
/usr/include/glib-2.0/glib/gmacros.h:167:1: warning: this is the location of the previous definition
In file included from /usr/include/graphviz/gvc.h:20,
from ../src/Canvas.cpp:32:
/usr/include/graphviz/types.h:27:1: warning: "TRUE" redefined
In file included from /usr/lib/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:30,
from /usr/include/glib-2.0/glib/galloca.h:30,
from /usr/include/glib-2.0/glib.h:30,
from /usr/include/glib-2.0/gobject/gtype.h:26,
from /usr/include/glib-2.0/gobject/gboxed.h:26,
from /usr/include/glib-2.0/glib-object.h:25,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:31,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:24,
from /usr/include/glibmm-2.4/glibmm.h:27,
from /usr/include/gtkmm-2.4/gtkmm.h:29,
from /usr/include/libgnomecanvasmm-2.6/libgnomecanvasmm.h:29,
from ../flowcanvas/Canvas.hpp:24,
from ../src/Canvas.cpp:27:
/usr/include/glib-2.0/glib/gmacros.h:171:1: warning: this is the location of the previous definition
[3/9] cxx: src/Connection.cpp -> build/default/src/Connection_2.o
[4/9] cxx: src/Ellipse.cpp -> build/default/src/Ellipse_2.o
[5/9] cxx: src/Item.cpp -> build/default/src/Item_2.o
[6/9] cxx: src/Module.cpp -> build/default/src/Module_2.o
[7/9] cxx: src/Port.cpp -> build/default/src/Port_2.o
[8/9] copy: flowcanvas.pc.in -> build/default/flowcanvas.pc
[9/9] vnum_cxx_link: build/default/src/Canvas_2.o build/default/src/Connectable_2.o build/default/src/Connection_2.o build/default/src/Ellipse_2.o build/default/src/Item_2.o build/default/src/Module_2.o build/default/src/Port_2.o -> build/default/libflowcanvas.so build/default/libflowcanvas.so.2
Waf: Leaving directory `/usr/src/ladish-0.1/flowcanvas/build'
'build' finished successfully (14.397s)
root@64studio:/usr/src/ladish-0.1/flowcanvas#
Building LADI and installing LADI tools for 64 Studio 3.0-beta3 seems to
be fine, *when ignoring the warnings for flowcanvas*, but I had no time
to check if the installs will work. So compiling only for Suse failed.
Recent discussion on LAU morphed into an idea for an Ethernet driven
sound card, and as this is now becoming a real development the
suggestion was made that it would be better to transfer the discussion
here.
The rationale in brief:
No proprietry hardware soundcard needed.
Almost all modern computers have reasonably fast Ethernet connections.
Potentially up to 20 channels per card - reality will probably be a lot
different!
FOSS drivers to connect Ethernet to whatever audio server is on the
computer - looking at jack right now.
FOSS within the soundcard module so that protocols/algorythings can be
tuned for best results.
FOSH design enabling hardware to be developed and inproved by anyone.
A number of people have shown interest in this, and we are at the stage
of starting to knock together some basic hardware for a feasibility
study.
State of play:
On Mon, 23 Nov 2009 14:39:48 +0100 (CET)
karl(a)aspodata.se (Karl Hammar) wrote:
> Folderol:
> > On Sat, 21 Nov 2009 12:25:36 +0100 (CET)
> > karl(a)aspodata.se (Karl Hammar) wrote:
> >
> > <snip>
> >
> > > Would this project plan be ok:
> > >
> > > software and hw: Karl
> > > testing and spec's: Folderol
> > > publication via web: anyone??
> > >
> > > git repo: git://aspodata.se/openhw.git
> > > mailing list: hopefully this list, else I put one up at my site
> > > web site: ??
> > >
> > > intial platforms (both by Atmel):
> > > . ATNGW100 (cheap), and
> > > . AT91SAM9260-EK (expensive)
> > >
> > > Next step:
> > > . set up development platform
> > > . simple test with spi and shift registers
> > >
> > > Regards,
> > > /Karl
> >
> > This is all fine by me, but I would make quite clear that if someone
> > comes along with access to a {loadsamoney} spectrum analyser I'd be
> > perfectly happy to step back and take a more supporting role.
>
> Ok, I should get starting then.
>
> Regards,
> /Karl
Others would be welcome to come on board - pardon the pun!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Wow! A lot been said since I opened my mouth :o
First an apology!
When I started this thread I CC'd LAU hoping to just bring interested
people over. I didn't expect the cross-post deluge that followed -
Sorry. I won't do it again :(
For those in doubt the original discussion started over on LAU as a
complaint about the state of USB support on Linux.
My take is very much like Karl's in many respects.
I want to keep well clear of any propriety issues such as patents,
licenses etc. You can't get much more 'free' that real analog audio,
and Ethernet is a pretty much universal and unencumbered standard. If
all the software and hardware remains open then I think we're pretty
much covered.
Another reason for going for a nuts & bolts build is that it will be a
*fun* challenge. I certainly do not expect broadcast standard feeds from
our first attempt, but if we can produce something that is reliable and
repeatable then I'm sure those that are more experienced than myself
will be able to point us in the right direction for fine tuning both
the hardware and software, but we really need a brick in place first.
Karl and I and some others I think more or less agreed that the first
step was to produce a simple development board with just two inputs as
a starter. The unit that Karl though most promising already has 16bit
DACs on board so a complete 2 in 2 out should be realisable fairly
quickly. For this first test, I'm not at all concerned about noise
levels. I think getting a reasonably low distortion conversion without
any discontinuities is the first target.
If the triggering of fast ADCs is controlled by a reasonably accurate
Xtal standard is doesn't really matter if the computer end drifts
about a bit, the odd lost packet should be recoverable and jack really
won't care as long as it's buffers are filled and emptied within the
overall time frame.
I know very little about networking, but the Wikipedia link very
much confirms my early thoughts that there aren't
any effective standards in place.
UDP also looks the way to go. Everything is permanently listening to
everything else, but only the master controller sends out polling
messages dictating which slaves will 'speak'. To me, this keeps the
protocol as simple, fast and flexible as possible and should completely
avoid collisions. It would seem other people have come to a similar
conclusion.
As we are working FOSS, everything is open for scrutiny and later
development of the messaging system is not a great hardship. Practical
experience can dictate what *really* is good and what isn't.
A little bit of sad news.
I decided to fire up my ancient valve voltmeter, notch filters etc. and
have a look at the distortion products from a mathematically generated
1kHz sinewave spat out by my 2496 sound card, just to give some form of
reference. Unfortunately the meter has gone to that great repair shop in
the sky :(
So...
My immediate project is now to build myself a battery operated digital
AC millviltmeter with true RMS volts and dB scaling based around Analog
Devices AD636.
Parts are on order :D
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
"Gabriel M. Beddingfield":
> So you see, by using a mutex... you have to consider
> those sections of code as being a part of your
> process() function.
Great explanation, but you forgot to explicitly mention
that those sections of code also has to run with higher
or equal priority as the jack process to avoid priority
inversion.
Arnold Krille:
> Locks and waits are not realtime save.
Not always true. But usually: yes. :-)
>
> And how many of them are open standards?
>
>
> Flo
The only "usefull" would be AES50-2005 because it is royalty-free.
([..] SuperMAC provides 48 channels bi-directionally over Cat 5 cable,
while HyperMAC provides up to 384 channels bi-directionally over Cat 5 or Cat 6 or fibre.
The signal format includes embedded clocks in the same way that AES3 does. [...] )
There is association AES50 Trade Association http://www.aes50ta.org/http://www.supermac-hypermac.com/
For non commercial usage they are planning to give free SDK for dsp platforms.
([...] Software Development Kits (SDKs) for use with Xilinx Spartan-3E and -3S series field programmable gate arrays (FPGAs) [...])
http://www.prosoundweb.com/article/klark_teknik_announces_several_aes50_pro…http://www.techietalk.co.uk/news/klark-teknik-announces-major-aes50-develop…
For commercial usage they charge £500 towards administration costs.
Details of licensing can be found here http://www.supermac-hypermac.com/licensing.php
Nevertheless, I can support open protocol development with my work since I am writing right no my theses on audio networking.
Pawel
----------------------------------------------------------------------
Wygraj pobyt w Alpach dla ca�ej rodziny
Kliknij >>> http://link.interia.pl/f2446
Dear reader,
as has been announced here 2 days ago by Marc Groenewegen, the next Linux
Audio Conference (LAC#8) will take place at the HKM in Utrecht, Netherlands,
from May 1st - 4th, 2010 (see http://lac.linuxaudio.org/2010).
We have now opened the Website that accepts paper submissions. Please direct your
browser to http://lac.linuxaudio.org/2010/openconf
For those who have been following the LAC activities in the past years: It's
the same used&tested "OpenConf" web-based system that allows us to easily collect
paper submissions, review them and create a programme from accepted papers.
The available categories for paper submission looks like this:
* Ambisonics
* Education
* Live performance
* Audio Hardware Support
* Signal Processing
* Music Composition
* Audio Languages
* Sound Synthesis
* Audio Plugins
* MIDI
* Music Production
* Linux Kernel
* Physical Computing
* Interface Design
* Linux Distributions
* Networked Audio
* Video
* Games
* Media Art
* Licensing
Note that "Video" is also in the list. Yes, that's not strictly Audio :-), but
we feel that the two disciplines are close enough to one another to allow
opening up the conference scope a bit here. After all, we have already had
several very nice audio/video gigs in the past (some might remember the YUE
concert in Karlsruhe 2006 with a remote VJ live from Italy, which was pretty
groundbreaking at that time).
Also, we very much welcome practical papers resp. software demos ("how I use
Linux Audio applications to create my music/media art").
The web page also holds the paper templates that have to be used for submissions.
Pick one of the two provided templates (LaTeX or OpenOffice), author your paper
and convert it to PDF, then upload that PDF. Make sure you are using A4 as
paper size.
Some constraints:
- The conference is held in English, so the paper has to be in English too.
- Length of a paper is 4-8 pages. Papers have to include an abstract (50-100
words). Also, papers should include up to 5 keywords.
- The copyright of the paper remains with you (of course), but we reserve the
right to create printed proceedings from all submitted (and accepted) papers.
- We have fixed the following dates:
- Deadline for paper submissions: February 14th, 2010
- Notification of paper acceptance: March 14th, 2010
- Deadline for final version of paper: April 4th, 2010
Please note that the OpenConf system is only to be used for paper submissions;
for concert pieces ("Call for Music") or sound installation proposals, please
contact us directly by email ("lac -at- linuxaudio -dot- org ").
We are looking forward to many interesting submissions for the 8th
Linux Audio Conference and we hope to see you in Utrecht in 2010!
Please feel free to forward this e-mail to anybody who might be
interested - mailing lists, blogs, Linux portals, magazines, you name them.
Public relation work for this conference is something we need, and where
everybody can easily help.
Thanks for reading.
On behalf of the LAC2010 organisation team,
Frank Neumann
Kevin Cosgrove wrote:
>> Yes, there is an overview over protocols here:
>> http://en.wikipedia.org/wiki/Audio_over_Ethernet
> Seems like the latter reference is quite far ahead of the IEEE
> thoughts.
And how many of them are open standards?
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net