Hello @Sans__0_0
@Sans__0_0 wrote:
Should I convert the ADC output signal to a signed format? This is important because when using DMA, the internal ADC does not provide a signed output, yet the middleware (Acoustic_SL) requires a signed input.
Yes. Shift the ADC output signal. AcousticSL input data must be signed input, so you must shift ADC output around 0.
@Sans__0_0 wrote:
Additionally, I have another question regarding the Middleware folder you provided. It contains three source files: AcousticSL.c, libSoundSourceLoc.c, and doa_via_block_sparsity.c, along with one header file, acoustic_sl.h. Are all these files necessary, or can I remove doa_via_block_sparsity.c? I would appreciate it if you could clarify the purpose of these files as well. In libSoundSourceLoc.c, it states that the number of samples to process is fixed, and if a different value is provided, the default value will be used. If I specify a higher value, will I gain any speed benefits?
AcousticSL.c is the unique entry point for the application. The other files are then linked from AcousticSL.c, so they are included into the project. Simply add AcousticSL.c in your project and everything should work properly.
If you'd like to remove the doa_via_block_sparsity.c file, you must manually modify libSoundSourceLoc.c accordingly to remove any reference to methods and variables used in doa_via_block_sparsity.c. It's not straightforward.
Regarding samples to process value, are you referring to this portion of code?
if ((SLocInternal->Type == ACOUSTIC_SL_ALGORITHM_GCCP) || (SLocInternal->Type== ACOUSTIC_SL_ALGORITHM_BMPH))
{
if( (SLocInternal->Sample_Number_To_Process == 32U) ||
(SLocInternal->Sample_Number_To_Process == 64U) ||
(SLocInternal->Sample_Number_To_Process == 128U) ||
(SLocInternal->Sample_Number_To_Process == 256U) ||
(SLocInternal->Sample_Number_To_Process == 512U) ||
(SLocInternal->Sample_Number_To_Process == 1024U) ||
(SLocInternal->Sample_Number_To_Process == 2048U) ||
(SLocInternal->Sample_Number_To_Process == 4096U))
{
}
else
{
SLocInternal->Sample_Number_To_Process = 256; /*Set default Value*/
SLocInternal->Sample_Number_To_Store = 256; /*Set default Value*/
ret |= ACOUSTIC_SL_NUM_OF_SAMPLES_ERROR;
}
}
If so, it states that the sample to process must be a specific value. If the user doesn't select a valid value, the library will restore the default one and will return the configuration error also. This parameter is used by frequency-based algorithms. So, the higher is the value, the longer is the window used for the processing in the frequency domain. You should have better results at the cost of slower output result updates.
Remember that the library is for evaluation only. The goal is to showcase how audio signal processing can be done with ST products, thus isn't optimized in memory footprint. Furthermore, it’s released AS IS, with no support from ST in a final product.
@Sans__0_0 wrote:
Lastly, I am encountering an issue with getting the ADC to function at 32kHz. The library only supports three frequencies: 16kHz, 32kHz, and 48kHz. Therefore, the number of samples stored in the buffer, which contains 1ms of data, should be exactly 32, 8 converted data from each microphone.
Are you sure the ADC setup is working properly? If you're acquiring audio data at 32kHz, you must have 32 samples for each millisecond for each microphone. Check the ADC settings in your setup.
Best regards,
Simone
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
