Testing ADC+DAC Pro mic input/line output with RASPA


Mainly I think this is a question for @Stefano or @Gustav…?

I am trying to test the audio IO for Hifiberry ADC+DAC Pro in a non-plugin context, which seems to be best done via RASPA.

Firstly, I wonder what are the equivalents to the configuration documentation Hifiberry provides here:

My understanding is that since nothing is going through alsa, this documentation is not relevant for Elk. How can I do the following?

  • Select left and right inputs (built-in or J4 pins?)
  • Control input gain for microphones
  • Control output level
  • Mic bias on/off (not sure if I will need this, but this is the only remaining parameter I think)

My other question concerns doing a simple loopback test to route input to output to check everything is working and levels are good.

Hifiberry recommends alsaloop here:

But again it will not be available. I see the equivalent here:

But it does not seem to come as a compiled executable on the platform OOB? What is the easiest way to compile/run it?

Finally I am wondering if there is some example code anywhere to using RASPA to build applications on Elk (rather than plug-ins which seem to have more examples).


To give a more clear sense of where I am currently - I was able to confirm line level passthrough is working just fine using the tip from @Ilias here:

But of course the main difference is that I want to use mic level with controllable gain, and in app context rather than a plugin.

HI @kcoul,
you got it right, the RASPA example loopback should be a good starting point for your needs.

It should build easily if you use our cross-compiling SDK and the included CMake project:

With a HiFiBerry, you should get two channel inputs / two channel output in the callback that you can expose to RASPA. It’s a very similar API to ALSA or similar low-level audio HW abstractions framework.

Thanks! Any advice regarding my first questions, regarding setting the hardware parameter options for the inputs?

I can get started with line level input, which may even be more convenient for now as a test signal, but pretty soon I will need to be able to handle both balanced and unbalanced mic input, set gain levels appropriately, etc.

Thanks again for your help!

that’s trickier and more a question for @Nitin I guess, who wrote the driver.

That will require some modifications on the driver here:

where right now some of the parameters are hardcoded and will be needed to be exposed as Kernel sysfs parameters. I think it should be possible to get more info by comparing the mainline ALSA driver for the same codec, if that one exposes those kind of controls.