Hi, I have a simple speaker output/microphone input system on ADSP-21489, and I'd like to measure the impulse response between them.
It seems that the most straightforward approach is to use the "measurement" block in the library. However, I have some trouble getting the impulse response out of it.
It seems that the output pin should be connected to the speaker output, and the input pin on the "measurement" block should be connected with the microphone readings. Once I toggled the trigger, I could hear the speaker playing the pre-determined noise, but I can't find a place where I can get neither the raw reading nor the estimated impulse response in the block.
Can you please work with me to figure out how I can get the readings out of that block?
Also, if this is not the right module for the job, can you please work with me to figure out the best way to measure the impulse response (recording the raw data and post-process it, or running LMS )?
Thanks
Shane
5:11pm
Hey Shane.
Since you have the Pro version of Designer you can use Matlab to access the response buffer from the module. Follow these steps to plot the impulse response you're looking for.
1) Run the layout in Designer
2) While running, check the trigger box on the measurement inspector. The module will will generate repetitions of the stimulus waveform and average the response.
3) Get the running layout's structure in Matlab:
>> GSYS = get_gsys();
4) Next read out the stimulus and response in Matlab command window:
>> x = GSYS.SYS.Measurement1.response;
>> z = GSYS.SYS.Measurement1.stimulus;
5) Next compute the transfer function and plot it
for example, if you have the signal processing toolbox you can do
> > [tf, f] = tfestimate(z,x,[],[],[],48000);
>> plot(f,abs(tf));shg
Hope this helps!
-Axel
12:43pm
Thanks Axel, I followed your instruction, and I'm able to obtain the values. I have some follow-up questions, hoping that you can help me with:
The block diagram looks like this:
where the input is a microphone, and output is a speaker. They are physically stick together, so that the latency should be mostly contributed from the board.
Thanks
Shane
12:43pm
Thanks Axel, I followed your instruction, and I'm able to obtain the values. I have some follow-up questions, hoping that you can help me with:
The block diagram looks like this:
where the input is a microphone, and output is a speaker. They are physically stick together, so that the latency should be mostly contributed from the board.
Thanks
Shane
12:45pm
re-attaching the images:
block diagram:
impulse response:
3:52pm
Hey Shane,
The latency of 160 samples looks reasonable since you are measuring the latency through the BSP and the DMA for both the input and output streams. 160 samples is 5 audio blocks at 32 samples per block.
As for the reverberation, your response signal doesn't look like it has any significant reverb in it. If it did, the impulse response would be wider (aka, non-zero over a longer interval). But if you are concerned about reverb then you can increase the length of the stimulus signal.
-Axel
5:58pm
Thanks Axel, is there anything we can do to on the software side to improve the latency, or the only thing we can do is to swap the codec?
As of the averaging question I had, in this case, for example, the reverberation lasts at least 20 samples. Does it mean the first 20 samples of the averaged response are contaminated? It seems that it can be taken care of when raw data is averaged, so I just want to make sure it really is.
Thanks
Shane
4:43pm
Hi Shane,
To reduce the latency, you can reduce the fundamental block size of your system to 16 or even 8. The audio path has several double-buffers, both at the DMA side and the Audio Weaver processing side, so a total latency of 5x fundamental block size is expected.
To remove the effects of the reverberation, you can pad the stimulus signal with zeros so there is no bleed over into the next stimulus.
-Axel
2:52pm
Thanks Axel, zero-padding the stimulus sounds like a good idea.
I also tried to reduce the frame size below 32, but an error message was thrown out saying that I can't go below that fundamental frame size.
Shane
4:31pm
The SHARC BSPs are set up to have a fundamental block size of 32 samples. To process anything smaller than this, the BSP code has to be updated and recompiled.
11:25am
Thanks Axel, is this something you can help me with? If not, can you point me to the right people to work this out please?
Shane
12:14pm
Hey Shane,
To change the fundamental block size on the 21489 target, change the value of SAMPS_PER_TICK on line 36 of AudioDriver.c to '(16u)' instead of '(32u)', and then recompile the whole project. This should allow you to set the block size in your Designer layout to 16.
Thanks
-Axel
6:19pm
Thanks Axel, I found the line, changed it to 16u, and ran the command:
cldp -proc ADSP-21489 -emu KIT ^
-driver "C:\Users\thsu\Desktop\AWE_BSP_adsp-21489_v1.2_Ref\ADI_21489_EZKit\Vendor\Lib\VendorLib\CCES\21489_m29w320_dpia.dxe" ^
-cmd prog -erase all -format hex ^
-file "C:\Users\thsu\Desktop\AWE_BSP_adsp-21489_v1.2_Ref\ADI_21489_EZKit\Bin\CCES\21489_EZKIT_RS232.ldr"
The fundamental block size is still 32. Does it mean that I need to recompile the files somewhere? Can you walk me through the steps of doing that please?
Please bear with me, I'm new to this world.
Shane
11:28am
Hi Shane,
Did you recompile the project with CCES or VDSP before flashing the new image? There are premade CCES and VDSP projects in the Build folder of the BSP.
Note that if you are using the free BSP from our website, it does not include the AWE Core libraries or project files so you won't be able to recompile the project with this smaller fundamental block size. If you're interested in getting the AWE Core libraries for the SHARC 21489, please email info@dspconcepts.com.
Thanks
-Axel
10:25am
Hi Shane, here are more details on your request. You'll also need to change AWE_FRAME_SIZE on line 37 of Platform.h from 32 to 16. This is the information which is returned to the PC and shown on the Server window. This number is referred to as the "Fundamental Block Size" in our document and training materials.
When building audio processing using Audio Weaver, the input wire size has to be a multiple of the fundamental block size. When it is 32, you can process at 32, 64, 96, etc. But no smaller. To test out lower latency processing you'll need to reduce this. We typically don't go lower than 16 because the overhead of ISRs and processing adds up.
If you want to do a quick and dirty estimate of the processing load at a smaller block size you can do the following. Keep the fundamental block size at 32. Then in your code decimate from 48 kHz / 32 samples to 24 kHz / 16 samples. (You can decimate by any power of 2). Your processing will then run at 24 kHz with a block size of 16 samples. Profile the processing. Then double the reported amount because it is running at 24 kHz. Similarly, if you really wanted to, you could decimate from 48 kHz / 32 samples to 1500 Hz / 1 sample. Profile the resulting system and then multiple by 32 to get the actual amount used. Note that decimating in the Layout does not increase the overhead of the ISR so it only shows you the change in the audio processing load.