hi there. i have just tried to run the latest ffado build (rev 1348)
and keep getting an 'input in flex scanner failed' error when trying
to run ffado-dbus-server. the exact error is:
02522143147: Debug (ffado-dbus-server.cpp)[ 251] main: verbose level = 6
02522143184: Debug (ffado-dbus-server.cpp)[ 252] main: Using ffado
library version: libffado 2.0.900-1348
input in flex scanner failed
no message buffer overruns
i have completely removed any old copies of ffado and checked out the
build from scratch in case it was something corrupting with an older
version's files being left behind or something, but still the same
error.
thanks for any help
porl
"Loki Davison":
>
> you get a lot more useful hits on google with WAVE_FORMAT_EXTENSIBLE
> than wavex it seems.
Thanks. That was a lot more information.
I wonder though, if aiff would be a better choice than wavex?
Does the endian mismatch matter anymore with todays machines?
I have embedded python as a midi scripting language in my audio
thread, and need to migrate the calls to libpython to a new process
per each audio thread to avoid acquiring python's the global
interpreter lock (GIL). Does anyone know what the theoretical
reliability of basic memory-based IPC mechanisms are like with respect
to realtime audio threads? Will I be causing even bigger performance
problems with just the IPC overhead to make some function calls, or is
it negligible?
Thanks
Hi all,
I'm having trouble getting a working compile of the freeverb3 plugin from the
CMT plugin set. I remember that a while back it had issues with de-normals.
However, I thought those issues got worked out. Furthermore, I was under the
impression that the whole de-normals problem was specific to Intel
processors. (Is that incorrect?)
The output sounds the same as what people described when having denormal
issues. i.e. sounds like a crappy plate reverb, with no control over tail
length.
It used to work, so I'm wondering if this might be an issue to do with using
newer versions of gcc?
-Reuben
Fons Adriaensen:
>
> On Wed, Sep 10, 2008 at 05:02:12PM +0200, Kjetil S. Matheussen wrote:
>
>> jack_capture
>> ============
>> jack_capture is a program for recording soundfiles with jack. Its default
>> operation is to capture whatever sound is going out to your speakers into
>> a file. (But it can do a number of other operations as well...)
>
> Very useful, just one remark: for more than 2 channels
> the default should be WAVEX instead of WAV (easy enough
> if you use libsndfile). WAVs with more than 2 channels
> are technically illegal and refused by some software.
>
Thanks for the input. But do you think ch>2 wavex
files are supported by more software than ch>2 wav
files? Because I haven't even heard of wavex files
before... (wavex files are supported in jack_capture
though, "-f wavex" should do the job, thanks to libsndfile)
I posted this exact message to the Vamp forum, noticed the dates of the
last posts, there, and decided to try here instead.
I'm having a most unusual problem compiling the Vamp-SDK on my machine.
This has actually been an on-going problem for some time now. Looking
over the Vamp forums, I see one other person seems to have successfully
compiled and installed Vamp on his 64-bit Ubuntu install, so I'm
wondering what keeps going wrong here.
The first thing I did was to edit the Makefile to install to /usr
instead of /usr/local. That was simple enough. Then when I run make, I
get the following output (notice the error at the end):
-----
g++ -O2 -Wall -I. -fPIC -c -o vamp-sdk/PluginAdapter.o
vamp-sdk/PluginAdapter.cpp
g++ -O2 -Wall -I. -fPIC -c -o vamp-sdk/RealTime.o vamp-sdk/RealTime.cpp
ar r vamp-sdk/libvamp-sdk.a vamp-sdk/PluginAdapter.o vamp-sdk/RealTime.o
g++ -O2 -Wall -I. -fPIC -c -o vamp-sdk/PluginHostAdapter.o
vamp-sdk/PluginHostAdapter.cpp
g++ -O2 -Wall -I. -fPIC -c -o
vamp-sdk/hostext/PluginBufferingAdapter.o
vamp-sdk/hostext/PluginBufferingAdapter.cpp
g++ -O2 -Wall -I. -fPIC -c -o vamp-sdk/hostext/PluginChannelAdapter.o
vamp-sdk/hostext/PluginChannelAdapter.cpp
g++ -O2 -Wall -I. -fPIC -c -o
vamp-sdk/hostext/PluginInputDomainAdapter.o
vamp-sdk/hostext/PluginInputDomainAdapter.cpp
g++ -O2 -Wall -I. -fPIC -c -o vamp-sdk/hostext/PluginLoader.o
vamp-sdk/hostext/PluginLoader.cpp
g++ -O2 -Wall -I. -fPIC -c -o vamp-sdk/hostext/PluginWrapper.o
vamp-sdk/hostext/PluginWrapper.cpp
ar r vamp-sdk/libvamp-hostsdk.a vamp-sdk/PluginHostAdapter.o
vamp-sdk/hostext/PluginBufferingAdapter.o
vamp-sdk/hostext/PluginChannelAdapter.o
vamp-sdk/hostext/PluginInputDomainAdapter.o
vamp-sdk/hostext/PluginLoader.o vamp-sdk/hostext/PluginWrapper.o
vamp-sdk/RealTime.o
ranlib vamp-sdk/libvamp-sdk.a
ranlib vamp-sdk/libvamp-hostsdk.a
g++ -static-libgcc -shared -Wl,-Bsymbolic -Wl,-soname=libvamp-sdk.so.1
-o vamp-sdk/libvamp-sdk.so vamp-sdk/PluginAdapter.o vamp-sdk/RealTime.o
g++ -static-libgcc -shared -Wl,-Bsymbolic
-Wl,-soname=libvamp-hostsdk.so.2 -o vamp-sdk/libvamp-hostsdk.so
vamp-sdk/PluginHostAdapter.o vamp-sdk/hostext/PluginBufferingAdapter.o
vamp-sdk/hostext/PluginChannelAdapter.o
vamp-sdk/hostext/PluginInputDomainAdapter.o
vamp-sdk/hostext/PluginLoader.o vamp-sdk/hostext/PluginWrapper.o
vamp-sdk/RealTime.o
g++ -O2 -Wall -I. -fPIC -c -o examples/SpectralCentroid.o
examples/SpectralCentroid.cpp
g++ -O2 -Wall -I. -fPIC -c -o examples/PercussionOnsetDetector.o
examples/PercussionOnsetDetector.cpp
g++ -O2 -Wall -I. -fPIC -c -o examples/AmplitudeFollower.o
examples/AmplitudeFollower.cpp
g++ -O2 -Wall -I. -fPIC -c -o examples/ZeroCrossing.o
examples/ZeroCrossing.cpp
g++ -O2 -Wall -I. -fPIC -c -o examples/plugins.o examples/plugins.cpp
g++ -static-libgcc -shared -Wl,-Bsymbolic
-Wl,--version-script=vamp-plugin.map -o examples/vamp-example-plugins.so
examples/SpectralCentroid.o examples/PercussionOnsetDetector.o
examples/AmplitudeFollower.o examples/ZeroCrossing.o examples/plugins.o
vamp-sdk/libvamp-sdk.a /usr/lib/gcc/x86_64-linux-gnu/4.2.3/libstdc++.a
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can not
be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/libstdc++.a: could not read symbols:
Bad value
collect2: ld returned 1 exit status
make: *** [examples/vamp-example-plugins.so] Error 1
-----
Is it trying to tell me that libstdc++ is compiled incorrectly on my
machine? It's the one that comes with every Ubuntu 64-bit system. Any
help would be greatly appreciated. Thank you!
My system:
AMD64 X2 with Kubuntu 64-bit, 2.4.24-19-rt kernel, 2GB DDR-800 RAM,
SATA2 hard disks.
Regards,
Darren Landrum
Hi all,
Does anyone else get clicks which occur continuously after getting a
single xrun in jack? (i.e no further xruns are reported, but the audio is
crackling).
I'm setting up an art installation which has to run for hours on end
without intervention, and this seems to be happening after some time
(running jack in realtime mode). I'm using a stock kernel in OpenSuse -
would it help to use a lowlatency one? The audio doesn't need lowlat - I'm
using a buffer size of 1024.
I don't care about the odd xrun - as long as the audio goes back to normal
afterwards, any help gratefully received. This is running in my own
software so there is more than a chance it's something I'm doing wrong.
cheers,
dave
Hi, sorry for the double post, but maybe a user
knows the answer to this...
What is the right way to call fst_init() ?
I have installed fst-1.9 (tried 1.7 - 1.9), and
it runs standalone and loads vst's OK.
However, from within a simple 'hello world' app,
when I call fst_init(), it causes a seg fault.
The seg fault happens early within fst, in the 'wine_premain'
code, at getModuleHandleA().
I have tried that trick of reserving and initializing 1,000,000
stack bytes (taken from from jfst_reserve_memory()). No luck.
I really would like to get this working. Can you help?
Thanks. Tim.
terminator356 <at> users <dot> sourceforge <dot> net.
(Using a different computer)
On Wed, Sep 10, 2008 at 05:02:12PM +0200, Kjetil S. Matheussen wrote:
> jack_capture
> ============
> jack_capture is a program for recording soundfiles with jack. Its default
> operation is to capture whatever sound is going out to your speakers into
> a file. (But it can do a number of other operations as well...)
Very useful, just one remark: for more than 2 channels
the default should be WAVEX instead of WAV (easy enough
if you use libsndfile). WAVs with more than 2 channels
are technically illegal and refused by some software.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
i would like to have solution where i can use any headphones and where
there is no bigger latency then 10ms (at least ;).... all pro
solutions are so f* expensive....
