[linux-audio-dev] linux audio apps on OSX: successes and failures

Stéphane Letz letz at grame.fr
Thu Oct 6 09:24:19 UTC 2005


Le 5 oct. 05 à 19:48, Derek Holzer a écrit :

> Dear Developers,
>
> I've just spent the last couple days trying to get some of my  
> favorite Linux
> audio apps running on OSX with various degrees of success or  
> failure. I'm
> posting this report in the hopes that some of you could give me  
> pointers on
> finishing the job, and possibly to start a dicussion of expanding  
> some more
> support to OSX. Thanks for getting us this far and please read on!
>
> 1) System:
>
> * OSX Tiger 10.4 with all developers packages installed
> * Fink was used for most dependencies
>
> 2) Apps which I used DMG packages for with no real problems:
>
> * Ardour 0.9beta30
> * JackOSX 0.71
> * SooperLooper 1.0.7
> * SuperCollider3 bin-20050916
> * Pure Data 0.36test2-extended-RC0
>
> 3) Apps I compiled with different degrees of success:
>
> * Jack Audio Connection Kit 0.100.0
> * Jack-Rack 1.4.4
> * JackEQ 0.4.0
> * QJackctl 0.2.18
> * Jamin 0.95.0
> * Rezound 0.12.2beta
> * Jack Timemachine 0.3.1
> * MCP Plugins 0.3.0
> * REV Plugins 0.3.1
> * BLOP Plugins 0.2.8
> * CAPS Plugins 0.2.3
> * CMT Plugins 1.15
> * SWH Plugins 0.4.14
> * TAP Plugins 0.7.0
>
> 4) Results and Notes:
>
> * Jack Audio Connection Kit 0.100.0
> Apparently successful. Starts from the command line without  
> problem, and is
> installed in a different location than the JackOSX package so I  
> don't beleive
> there to be a conflict.

Hum... I think compiling Jack Audio Connection Kit 0.100.0 will  
install everything in /usr/local by default, the same place use by  
the JackOSX installer.
Thus compiling/installing  Jack Audio Connection Kit 0.100.0 will  
overwrite the JackOSX install, but this will not prevent JackOSX to  
work later.
>
>
> * Jack-Rack 1.4.4
> Compiles without any real difficulty. However, when run it gives  
> the following
> error for each plugin installed in /usr/local/lib/ladspa:
>
> plugin_mgr_get_object_file_plugins: error opening shared object file
> '/usr/lib/ladspa/zm1_1428.so': dlopen(/usr/lib/ladspa/zm1_1428.so,  
> 10): Symbol
> not found: _libintl_dgettext
>   Referenced from: /usr/local/lib/ladspa/zm1_1428.so
>   Expected in: flat namespace
>
> After which I get a GTK message stating that Jack-Rack could not  
> find any LADSPA
> plugins and I should check my path (which is correct, BTW). Ardour  
> gives the
> same error, so I assume it has something to do with my SWH compile.
>
> * JackEQ 0.4.0
> Compiles fine. Gives runtime error:
>
> Fontconfig warning: line 251: invalid edit binding "same"
> Fontconfig warning: line 263: invalid edit binding "same"
> Registering as jackEQ
> Bus error
>
> and exits. Probably to do with SWH plugins.
>
> * QJackctl 0.2.18
> Compiles and runs fine. Only problem is with initializing the  
> CoreAudio device.
> My CoreAudio device has the identifier "-n Apple03DBDMAAudio:i2s-a: 
> 0", however
> there is no way to get QJackctl to enter that string in the startup  
> command.
> Seems it can't handle CoreAudio/OpenFirmware(?) ID strings (QJackctl
> identitifes my card as "128" in the select menu). If Jackd or  
> JackOSX are
> already running, QJackctl recognizes them and I can use the  
> Connections menu.
> MIDI support is not there, of course, due to lack of ALSA.


The way to identify coraudio  driver has been changed recently. It  
was a "user frendly" name, but was changed to an internal (more  
persistant) ID.
I don't think QJackctl has been updated to handle this new way.



>
> * Jamin 0.95.0
> Compiles and runs fine, after some work to get it to recognize the  
> LADSPA_PATH.
> Exits with the same "Bus error" message on startup, possibly due to  
> SWH Plugins
> problem.
>
> * Rezound 0.12.2beta
> I've heard people using this on OSX, and I've even seen a  
> commercial package for
> OSX using it, but I'll be damned if I can get it to compile. Here's  
> as far as I
> got:
>
>  g++ -DHAVE_CONFIG_H -I. -I. -I../../../config -I../../../src/misc
> -I../../../src/misc/missing/generated -I../../../src/PoolFile -g -Wall
> -Wno-unused-function -Wno-unused-variable -Wno-unused -MT  
> CNestedDataFile.lo
> -MD -MP -MF .deps/CNestedDataFile.Tpo -c CNestedDataFile.cpp -o
> CNestedDataFile.o
> CNestedDataFile.cpp:21:2: warning: #warning parseFile doesnt need  
> to set the
> filename, only the constructor and setFilename should do that
> CNestedDataFile.cpp:22:2: warning: #warning see about retaining the  
> order that
> things were parsed in the file
> In file included from ../../../config/common.h:72,
>                  from CNestedDataFile.h:24,
>                  from CNestedDataFile.cpp:36:
> ./../../config/platform/platform.h:10:3: warning: #warning no platform
> determined!
> In file included from CNestedDataFile.cpp:45:
> ./../../src/misc/CPath.h:302:5: error: #error CPath::which needs to be
> implemented on this platform
> make[3]: *** [CNestedDataFile.lo] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all-recursive] Error 1
>
> [More spew available on request]. Also cannot get ./configure to  
> recognize
> fftw.h and the other FFTW headers, no matter how many PATH  
> combinations I try.
>
> * Jack Timemachine 0.3.1
> Compiles and starts without problem. A half an hour ago I was  
> getting the
> following: "Cannot open file for writing: Bad file descriptor", but  
> just now
> when I tried again, apparently it wrote a proper w64 file. Who  
> knew! ;-)
>
> * MCP Plugins 0.3.0
> These lack a proper ./configure file, and I did not edit the  
> Makefile at all.
> Compile ends with:
>
> g++ -shared  mvclpf24.o mvclpf24_if.o exp2ap.o -o mvclpf24.so
> powerpc-apple-darwin8-g++-4.0.0: unrecognized option '-shared'
> /usr/bin/ld: Undefined symbols:
> _main
> collect2: ld returned 1 exit status
> make: *** [mvclpf24.so] Error 1
>
> * REV Plugins 0.3.1
> Same as MCP plugs. No ./configure and ends with:
>
> g++ -shared greverb.o g2reverb.o g2reverb_if.o exp2ap.o -o g2reverb.so
> powerpc-apple-darwin8-g++-4.0.0: unrecognized option '-shared'
> /usr/bin/ld: Undefined symbols:
> _main
> collect2: ld returned 1 exit status
> make: *** [g2reverb.so] Error 1
>
> * BLOP Plugins 0.2.8
>
> Compile ends with:
>
> gcc -DHAVE_CONFIG_H -I. -I. -I..  -I/usr/local/include -Iinclude -I.
> -DLOCALEDIR=\"/usr/local/share/locale\"   -pipe -Wall -O3 -Wno-unused
> -DNO_DEBUG -DPIC -fPIC             -ffast-math -fomit-frame-pointer
> -funroll-loops -nostartfiles -shared -lc -o adsr_1653.so   
> adsr_1653.so.o
> powerpc-apple-darwin8-gcc-4.0.0: unrecognized option '-shared'
> /usr/bin/ld: Undefined symbols:
> _libintl_bindtextdomain
> _libintl_gettext
> _libintl_textdomain
> dyld_stub_binding_helper
> collect2: ld returned 1 exit status
> make[3]: *** [adsr_1653.so] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> This unrecognized option '-shared' is becoming a theme, isn't it? I  
> also wonder
> if there is a problem with my Fink-installed gettext, as that is  
> the error
> which the SWH plugins give when a client tries to use them.

-shared must be replaced by -bundle on OSX

>
> * CAPS Plugins 0.2.3
> No ./configure at all, I had to symlink a malloc.h to a place where  
> it could
> find it, and it all ends as such:
>
> g++ -O6 -ffast-math -funroll-loops -Wall  -I/usr/local/include -c  
> Amp.cc
> Amp.cc:169: error: explicit specialization of 'void  
> Descriptor<AmpIII>::setup()'
> must be introduced by 'template <>'
> Amp.cc:169: error: template-id 'setup<>' for 'void  
> Descriptor<AmpIII>::setup()'
> does not match any template declaration
> Amp.cc:169: error: invalid function declaration
> Amp.cc:303: error: explicit specialization of 'void  
> Descriptor<AmpIV>::setup()'
> must be introduced by 'template <>'
> Amp.cc:303: error: template-id 'setup<>' for 'void  
> Descriptor<AmpIV>::setup()'
> does not match any template declaration
> Amp.cc:303: error: invalid function declaration
> make: *** [Amp.o] Error 1
>
> * CMT Plugins 1.15
> No ./configure at all. Issuing a "make" in the src directory yields:
> g++ -I/usr/local/include/ -Wall -Werror -O3 -fPIC   -c -o analogue.o
> analogue.cpp
> cc1plus: warnings being treated as errors
> analogue.cpp: In static member function 'static void Analogue::run 
> (void*, long
> unsigned int)':
> analogue.cpp:259: warning: 'a' may be used uninitialized in this  
> function
> analogue.cpp:259: warning: 'b' may be used uninitialized in this  
> function
> analogue.cpp:259: warning: 'c' may be used uninitialized in this  
> function
> make: *** [analogue.o] Error 1
>
> * SWH Plugins 0.4.14
> Compiled and installed to /usr/local/lib/ladspa without a hitch,  
> but as you can
> see they have caused problems for all the LADSPA hosts so far with the
> following:
>
> plugin_mgr_get_object_file_plugins: error opening shared object file
> '/usr/lib/ladspa/zm1_1428.so': dlopen(/usr/lib/ladspa/zm1_1428.so,  
> 10): Symbol
> not found: _libintl_dgettext
>   Referenced from: /usr/local/lib/ladspa/zm1_1428.so
>   Expected in: flat namespace
>
> or simply a quieter "Bus error". Too bad, it was looking good so  
> far...
>
> Incidentally, I also used Taybin's swh-plugins and tap-plugins DMG  
> files and
> they gave me the same results. So if these DMG packages are working  
> for someone
> else, then I know it's something specific to my system here  
> (gettext perhaps?)
>
> * TAP Plugins 0.7.0
> No ./configure. Compile ends with:
> lsgcc -I. -O3 -Wall -fomit-frame-pointer -fstrength-reduce -funroll- 
> loops
> -ffast-math -c -fPIC -DPIC tap_autopan.c -o tap_autopan.o
> gcc -nostartfiles -shared -Wl,-Bsymbolic -lc -lm -lrt -o  
> tap_autopan.so
> tap_autopan.o
> powerpc-apple-darwin8-gcc-4.0.0: unrecognized option '-shared'
> /usr/bin/ld: unknown flag: -Bsymbolic
> collect2: ld returned 1 exit status
> make: *** [tap_autopan.so] Error 1
>
> 5) Conclusion
>
> While writing this report I tried Taybin's pair of LADSPA DMG  
> packages, hoping
> for the best, but getting the same results. So I'm hoping I've  
> provided enough
> info for some of you to point me in the right direction.
>
> I'd be happy to run a "gdb" on anything you all would like to hear  
> more about,
> and I'd love to hear some feedback about how to get through all this.
> Particularly the Rezound and SWH problems, as those are the two  
> biggest
> sticking points.
>
> thx + best wishes,
> derek
>
> http://umatic.nl
>

Stephane





More information about the Linux-audio-dev mailing list