The open Master Hearing Aid Forum

Moving github issue #35 to the openMHA forum:

sbashford has asked:

Do you have any recommendations on creating a pipeline for developing a plugin? How might one consume this project for plugin development?

I believe a plugin developer needs to include mha_plugin.hh and link to libopenmha.*, correct?

Am I correct that neither the pre-compiled binary package nor the install target exposes mha_plugin.hh? If so, would you recommend that a plugin developer explicitly includes ${openmha_root}/mha/libmha/src in their build-system?

Do you have any recommendations on creating a pipeline for developing a plugin? How might one consume this project for plugin development?

I believe a plugin developer needs to include mha_plugin.hh and link to libopenmha.*, correct?

Yes, you need that header and that shared library to derive your own plugin class from the base class MHAPlugin::plugin_t<>. More headers from libmha are needed if you make use of the functions and classes declared in them.

Am I correct that neither the pre-compiled binary package nor the install target exposes mha_plugin.hh?

For Linux, we provide the libopenmha-dev package which installs all headers in /usr/include/openmha/, which you can add to the include path of the compiler in a plugin development project. You need to ensure that you are using the same compiler for compiling your plugin as was used for openMHA, otherwise there may be linker and/or runtime incompatibilities.

Because of this, it is easier to develop your own plugins inside the openMHA source tree as cloned from git: Add a new directory below mha/plugins, copy the Makefile and the source file of one of the example plugins into that directory, rename the source file from my_new_plugin/example2.cpp to my_new_plugin/my_new_plugin.cpp and start with your modifications. Your new plugin directory will be detected and compiled by the Make based build system. See COMPILATION.md for instructions how to compile openMHA on the different plattforms. You can adapt compiler flags as desired in the top-level file config.mk after it has been created by ./configure.

If so, would you recommend that a plugin developer explicitly includes ${openmha_root}/mha/libmha/src in their build-system?

My current recommendation is to develop new plugin inside the git workspace right next to all other plugins as described above, but it is certainly possible to adapt the include and linker paths in separate plugin projects. In this case, you would add the /mha/libmha/src to the include path, yes.

Thanks for your help.

Suppose I was interested in cross-compiling a plugin for the beaglebone black running mahalia. I think I would first need to , correct? Then make would invoke arm-linux-gnueabihf-gcc.

Also the libmha source appears to depend on libsndfile, are there any apt packages of libsndfile targeting the armhf architecture? Or would you recommend building libsndfile from source?

You can install the packages for multiple arches in parallel. See https://wiki.debian.org/Multiarch/HOWTO.
I however use https://github.com/dockcross/dockcross for my cross-compiling needs.

For our own release and development builds, we do not regularly cross compile at the moment. Instead, we build natively on Linux ARM to be able to execute our octave tests and unit tests on ARM, and to use the same make-based build system.

Yes, you can cross-compile for ARM after configuring with --arch=armhf. The build system then expects to be able to call the cross-compiler as arm-linux-gnueabihf-g++-<version> on the PATH. You need to install at least the libraries libsndfile and its dependencies, libportaudio and its dependencies libasound, libjack in your cross-build environment so that you can compile and link ARM binaries against these libraries.
Configure the openMHA build as ./configure --arch=armhf --with-osc=no --with-lsl=no and call make. (You could also install liblo and liblsl in the cross-build environment and omit the --with...=no parameters).

Cross-compiling is for advanced developers who know what they are doing. We are interested to learn about your cross-compilation experiences and suggestions, but will not ourselves put more effort into it right now, because native building on ARM works for us.