11. Performance

11.1. Memory footprint

The memory impact of the DSpotter library on the VAD project is presented in the table below.

Table 3 DSpotter memory requirements

Memory space	Section	Size / KB	Address space	Name	Comments
FLASH	.text	38k	0x3a264	libDSpotter	The word spotting library
FLASH	.text	95k|	0x10f50	Model/CybModel1.o	This is the model size with fixed size of keywords (Currently 8)
RAM	.bss	6k	0x2001b078	g_byaRingBuffer	Cyberon ring buffer to handle audio samples
RAM	.bss	2k	0x2001a8f4	analog_mic_buffer	Ring buffer for SYS_AUDIO_MGR
RAM		22k		Working memory	Dynamically allocated from DSpotter software, part of heap.

11.2. System Power consumption

The equipment and electrical conditions that have been used to perform power consumption measurements were the following:

• Daughterboard: D3107_T0, 2206_00038

• Motherboard: 500-05-D (RevD)

• VLDO set at 3.3v

• LCD disconnected

• LED functionality disabled

• MIC powered at 1.8v

• SmartSnippets toolbox

Sleep current for project (all disabled VAD+MIC+LEDs) is ~23uA.

Please consider the sleep current as typical. Users will most likely get different measurements due to slight variations on hw components and hw versions thus measuring other “Sleep current” values.

Sleep current when the VAD and microphone are enabled rises to ~75uA, an increase of ~53uA. The VAD consumes ~5uA, the rest of the increase is caused by the analog microphone (CMM-3729AT-42308-TR), which according to manual has a typical current consumption of 80 µA when powered from VDD = 2.0V.

Figure 20 Power consumption VAD Mic enabled

Consumption during audio sampling is 7.5mA while during word spotting & audio sampling it raises at 17.4mA.

Figure 21 Power consumption during Audio Sampling Word spotting

The table below summarizes these results:

Table 4 Power consumption

VAD peripheral	MIC powered	M33 awake & sampling audio	M33 awake & sampling audio & running DSpotter lib
+5uA	+48uA	+7.5mA	+10mA

11.3. Timing considerations

11.3.1. DSpotter processing time

For DSpotter library to work properly, a 16KHz sampling rate input is essential. In this application the audio manager is configured to provide 480 samples every ~30ms, thus resulting in a 16k audio data stream. It is valuable to know during the 30ms time period how much time the library word processing consumes. These findings will help to understand why the 160MHz master clock setting was selected for this project.

Figure 22 DSpotter processing time

The signal labeled as “AudioCB” is the callback from the DMA buffer, indicating that samples are ready for processing. The signal “DSpotter” measures the time period the lib consumes to process these audio data.

Table 5 Processing time with DSpotter & Serial Debug

Master CLK	Audio Sampling	DSpotter processing time	Serial output	Total processing time
160 MHz	30ms	9ms	15ms	24 ms
96 MHz	30ms	12ms	15ms	27 ms
64 MHz	30ms	18ms	15ms	33 ms

If “SUPPORT_UART_DUMP_RECORD” macro is enabled the audio samples are printed on serial port. This is an usefull feature during the debugging period of the project. The user can capture the processed audio with the Cyberon tool and compare with the audio input. The table above presents the total processing time including the serial dump of audio samples.

Since a 64MHz master clock would cause an overlapping on Audio sampling periods and total processing time we propose to use at least the 96MHz or even better the 160Mhz to further reduce the possibility of overlapping between sampling periods.

Figure 23 UART Debug processing

As an example, a capture of both events is presented in the above figure. The audio dump (white signal) on serial port trails the DSpotter processing (orange signal). The remaining time until next set of samples is available is 5.7ms.

11.3.2. Wakeup word truncation

As mentioned in the previous chapter, if the “SUPPORT_UART_DUMP_RECORD” macro is enabled, the audio that is processed by DSpotter lib can also be recorded. If the user plays a tune with fixed length into the microphone. The truncated length can be calculated by simply subtracting the fixed length from the recorded length. The difference for this configuration is 10ms.

The 10ms latency is due to the following reasons:

• VAD Minimum Event Duration.

• Wake-up of the DA1470x system after VAD IRQ is generated

• Audio Manager startup

Another factor that should be considered is the DSpotter behavior on startup is that the first samples are treated as initialization data. The next set will be used for word spotting, thus introducing an extra latency to the system of 30ms. The total latency for this particular project would sum-up to 40ms minimum.

11.3.3. VAD related improvements

During tests several false interrupts are to be expected particularly during low ambient noise (quiet) conditions. Majority of these were noise and not actual voice events. To reduce these false events certain parameters can be configured and the overall behavior concerning Noise Detected as Voice (NDVs) can be managed.

• Power Level Sensitivity: It is obvious that increasing this value improves the performance of the system on false triggers. The level of the event to be detected is raised compared to ambient noise and therefore less NDV are produced. In a noisy environment this approach might cause a problem since a high PWR could make actual VDV very hard.

• Minimum Event Duration: Increasing the event cycle improves false trigger problem. It seems that higher values on “min event” parameter allow the VAD to better calculate if the energy detected is actually background noise or voice. High values might also have the risk on increasing the detection latency as well, that would result in poor performance of a word detection algorithm (DSpotter).

• NFI Detection: As expected lowering the NFI value would trigger the system much easier. Values lower that 0x20 would in fact trigger interrupts so fast and so frequently that make any software implementation unusable.

NFI_STATUS register: This register holds the Noise Floor Information (NFI) which is the ambient noise reference level used in the VAD. This information is not used in this implementation but in future applications could enable the user to:

• To optimize the performances of the AppADC.

• To optimize the efficiency of the speech recognition algorithm.

• To optimize the sensitivity threshold of the VAD (VDV vs. NDV) during its usage in real condition.

11.4. DSpotter related improvements

Voice recognition will engage after the system wakes-up and the audio manager starts sampling audio. These preceding actions add a delay that might affect the DSpotter performance. The wakeup word in particular might be processed with some phonemes being truncated. For this reason, the user might need to create a model with more than one versions of the wakeup word considering this issue. For example:

• Hello Renesas

• ello Renesas

• llo Renesas

It is obvious that there are limitations to this approach if a single word is chosen as a wakeup word. In that case truncating this word might lead to several false detections.