Maix mic_lib.a >> mic_lib.c


I’m working through to see if I can understand how the program works.

I understand from a review of the code in MaixPy\ports\k210-freertos\mpy_support\Maix\Maix_mic_array.c that the process involves converting an image representing the highest sound levels in the region between and around the 6 mics on the 6+1 mic array board. This is in a 256 deep, 8 bit array so the map is 16x16 bytes. The image is obtained from a call to lib_mic_init, which is prototyped in MaixPy\ports\k210-freertos\platform\api\include\lib_mic.h, but I can’t find a matching lib_mic.c to see how the image is generated.

Digging further I can see that the functionaility is wrapped up in a precompiled binary, MaixPy\ports\k210-freertos\platform\api\lib_mic.a, and a dump of the symbol table in that file (riscv64-unknown-elf-objdump -t lib_mic.a) shows that there actually is a lib_mic.c source file… somwehere! I’ve looked everywhere for this with no luck.

Is there any reason why this file can’t be also included in the source tree for MaixPy? It would be great to understand how this module works and maybe opening it to the public up would results in code improvements.

Thanks for listening!


Hi, thank you for your testing, we didn’t open it yet, as it usually commerce functions.
And the arithmetic need some mathematics skill, we think there have little man can understand it.
If you have knowledge of Audio process like BF, and have ability to improve it, you can send email to to require it.
the code contains many “Magic” number calculate from mathematics, I’m not sure you can understand it.

Are these the same ‘magic’ numbers as here?

I do not claim to understand them, but I think some are related to the mic-array geometry, isn’t it?

I don’t know how I missed the standalone APU demo! You found the source of the source :grinning:

I see how the 4 I2S channels are configured including the sample rate…

i2s_set_sample_rate(I2S_DEVICE_0, 44100);

It looks like the init_bf function initializes coefficients for filters used by the beamformer so I don’t think that is related to the mic-array geometry. There’s a section of commented code that would seem to be geometry related though…

// uint8_t offsets[16][8] = {
// {0, 1, 5, 7, 7, 5, 1, 4, },
// {0, 0, 3, 6, 7, 6, 3, 4, },

I thought that the 3cm comment was for the mic spacing/radius but I measured it on the 6+1 board and it is actually 4cm. I thought that was just a typo but after exploring the Kendryte-Standalone-SDK I found related files:

  • apu.h
  • apu.c

… which include lots of detail on the BF. The 16x8 array offsets, which is commented out in /kendryte-standalone-demo/blob/develop/apu/init.c, is built programmatically in Kendryte-Standalone-SDK/lib/drivers/apu.c (see apu_set_delay function). I believe the commented out array in init.c was a temporary array that was replaced by the calculated version. Makes sense to me anyway.

The function template for apu_set_delay indicates three parameters:

  1. @param[in] radius radius
  2. @param[in] mic_num_a_circle the num of mic per circle
  3. @param[in] center 0: no center mic, 1:have center mic

The call to this function from the APU demo file (init.c) is as follows

  • apu_set_delay(3, 7, 1);

So this suggests a 3cm radius ( which must be incorrect… should be 4cm), 7 mic’s (6+1=7 so correct) and with a center mic (correct).

This is all great as it shows where the lib_mic.c (& another lib_mic.h) source originated but it doesn’t tell us what might have changed as the code was migrated into MaixPy. Maybe the radius parameter was corrected or maybe it wasn’t. We can’t tell if we can’t see it.

Please include mic-lib.c and mic_lib.h in the MaixPy repo. It would be best to include all revision tracking so it will be easier to follow logic of the changes that were made. The original APU demo doesn’t include the heat map functions like Maix_mic_array_get_map found in Maix_mic_array.c so following the evolution of that source file would be very instructive.


1 Like

Hi, the standard APU code is only for direction detection, not for sound field imaging.
APU hardware can use to do direction detection, but sound field imaging need much more soft math work.
The code in lib_mic.c is totally different, as it is hand written by us, not use kendyte sdk driver.

Thank you for the explaination. Is there any reason you cannot share the code with me? I know I’ll learn something from it.

1 Like

Please, open it! I need it to develop my product!

To see HOW you work through the demo would help a lot of us. If typing it up in a Instructable or something is to much work work, how about a video on youtube?

Are you specifically asking me HOW I work through the demo? If so then don’t expect an instructable or video. Start at the entry point in the Python script and understand that. Then search the SDK for all Python function calls from the script. Then study each function call you find to understand them and trace your way further back until you understand how it all works. Simple right?

mic_lib.c isn’t available so don’t waste your time. I moved on from the Python example. Look at the apu demo in the Kendryte-Standalone-Demo repo.

Happy hunting!


Code should never contain any magic numbers, it is better to use variables or other language features like define.

If code is hard to understand it is hard to debug, maintain and extend. Perhaps comments would be appropriate.