6
This commit is contained in:
+49
-18
@@ -47,9 +47,9 @@
|
||||
\acronymused{ANR}
|
||||
\acronymused{SNR}
|
||||
\acronymused{ANR}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Evaluation of the computational load for a fixed update implementation}{62}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Evaluation of a a fixed update implementation}{62}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.3.1}Full-Update implementation}{62}{}\protected@file@percent }
|
||||
\newlabel{equation_computing_calculation_full_update}{{32}{63}{}{}{}}
|
||||
\newlabel{equation_computing_calculation_full_update}{{32}{62}{}{}{}}
|
||||
\acronymused{PCM}
|
||||
\acronymused{DSP}
|
||||
\acronymused{DSP}
|
||||
@@ -64,7 +64,7 @@
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.3.2}Reduced-update implementation for the benchmark case}{63}{}\protected@file@percent }
|
||||
\acronymused{DSP}
|
||||
\acronymused{SNR}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {52}{\ignorespaces Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the update rate of the ANR algorithm for the benchmark case. The baseline of 100\% is the full update implementation. The marked dots represent the results of the simulation for an explicit setup.}}{64}{}\protected@file@percent }
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {52}{\ignorespaces Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the update rate for the benchmark case. The baseline of 100\% is the full update implementation. The marked dots represent the results of the simulation for an explicit setup.}}{64}{}\protected@file@percent }
|
||||
\newlabel{fig:fig_snr_update_rate.png}{{52}{64}{}{}{}}
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
@@ -89,27 +89,58 @@
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.3.4}Computational load for reduced-update implementation}{66}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Evaluation of the computational load for an error driven implementation}{66}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.1}Error threshold implementation for the benchmark case}{66}{}\protected@file@percent }
|
||||
\newlabel{equation_update_1}{{39}{66}{}{}{}}
|
||||
\newlabel{equation_update_2}{{40}{66}{}{}{}}
|
||||
\acronymused{DSP}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {55}{\ignorespaces Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the fixed error threshold. The baseline is the full update variant the complex usecase. The marked dots represent the results of the simulation for an explicit setup.}}{67}{}\protected@file@percent }
|
||||
\newlabel{fig:fig_snr_error_threshold.png.png}{{55}{67}{}{}{}}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.2}Error threshold implementaion for multiple noise signals}{67}{}\protected@file@percent }
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {56}{\ignorespaces Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the fixed error threshold. The baseline is the full update variant the complex usecase. The marked dots represent the results of the simulation for an explicit setup.}}{68}{}\protected@file@percent }
|
||||
\newlabel{fig:fig_gain_error_threshold.png.png}{{56}{68}{}{}{}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {57}{\ignorespaces Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the fixed error threshold. The baseline is the full update variant the complex usecase. The marked dots represent the results of the simulation for an explicit setup.}}{68}{}\protected@file@percent }
|
||||
\newlabel{fig:fig_load_error_threshold.png.png}{{57}{68}{}{}{}}
|
||||
\newlabel{equation_computing_calculation_reduced_update_3}{{41}{66}{}{}{}}
|
||||
\newlabel{equation_load_calculation_reduced_update_3}{{42}{66}{}{}{}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Evaluation of an error driven implementation}{66}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.1}Error threshold implementation for the benchmark case}{67}{}\protected@file@percent }
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {55}{\ignorespaces Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the error threshold for the benchmark case. The baseline of 100\% is the full update implementation. The marked dots represent the results of the simulation for an explicit setup.}}{67}{}\protected@file@percent }
|
||||
\newlabel{fig:fig_snr_error_threshold.png}{{55}{67}{}{}{}}
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
\newlabel{equation_computing_calculation_error threshold_1}{{43}{68}{}{}{}}
|
||||
\newlabel{equation_load_calculation_error threshold_1}{{44}{68}{}{}{}}
|
||||
\acronymused{DSP}
|
||||
\acronymused{SNR}
|
||||
\newlabel{equation_computing_calculation_error_threshold}{{39}{69}{}{}{}}
|
||||
\newlabel{equation_load_calculation_error_threshold}{{40}{69}{}{}{}}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.2}Error threshold implementaion for multiple noise signals}{68}{}\protected@file@percent }
|
||||
\acronymused{SNR}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {56}{\ignorespaces Performance gain (distance between relative SNR-Gain and needed relative cycles/sample) in relation to the error threshold for different noise signals.}}{68}{}\protected@file@percent }
|
||||
\newlabel{fig:fig_gain_error_threshold.png}{{56}{68}{}{}{}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {57}{\ignorespaces Absolute \ac {DSP} load in relation to the error threshold for different noise signals.}}{69}{}\protected@file@percent }
|
||||
\acronymused{DSP}
|
||||
\newlabel{fig:fig_load_error_threshold.png}{{57}{69}{}{}{}}
|
||||
\acronymused{DSP}
|
||||
\acronymused{DSP}
|
||||
\newlabel{equation_computing_calculation_error_threshold_2}{{45}{69}{}{}{}}
|
||||
\newlabel{equation_load_calculation_error_threshold_2}{{46}{69}{}{}{}}
|
||||
\acronymused{DSP}
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.4.3}Computational load for error threshold implementation}{69}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {5.5}Summary of the performance evaluation}{69}{}\protected@file@percent }
|
||||
\newlabel{equation_update_3}{{47}{70}{}{}{}}
|
||||
\acronymused{DSP}
|
||||
\newlabel{equation_computing_calculation_error_threshold_3}{{48}{70}{}{}{}}
|
||||
\newlabel{equation_load_calculation_error_threshold_3}{{49}{70}{}{}{}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {5.5}Summary of the performance evaluation}{70}{}\protected@file@percent }
|
||||
\acronymused{ANR}
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
\acronymused{DSP}
|
||||
\acronymused{SNR}
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
\acronymused{DSP}
|
||||
\acronymused{DSP}
|
||||
\acronymused{SNR}
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
\acronymused{ANR}
|
||||
\acronymused{CI}
|
||||
\@setckpt{chapter_05}{
|
||||
\setcounter{page}{70}
|
||||
\setcounter{equation}{40}
|
||||
\setcounter{page}{72}
|
||||
\setcounter{equation}{49}
|
||||
\setcounter{enumi}{0}
|
||||
\setcounter{enumii}{0}
|
||||
\setcounter{enumiii}{0}
|
||||
@@ -243,7 +274,7 @@
|
||||
\setcounter{lstnumber}{15}
|
||||
\setcounter{FancyVerbLine}{0}
|
||||
\setcounter{linenumber}{1}
|
||||
\setcounter{LN@truepage}{69}
|
||||
\setcounter{LN@truepage}{71}
|
||||
\setcounter{FancyVerbWriteLine}{0}
|
||||
\setcounter{FancyVerbBufferLine}{0}
|
||||
\setcounter{FV@TrueTabGroupLevel}{0}
|
||||
|
||||
+73
-22
@@ -51,7 +51,7 @@ The vizualization of the noise signals is shown in Figure \ref{fig:fig_noise_sig
|
||||
\end{figure}
|
||||
\noindent Figure \ref{fig:fig_snr_comparison.png} shows the expected \ac{SNR}-Gain for the different noise signals and filter lengths. The results shows, that a minimum filter length of about 32 taps is required, before (in any case) a significant rise in the \ac{SNR}-Gain can be observed - this is highly contrary to the synchrone intermediate high level simulation, where a filter length of only 16 taps provided sufficent noise reduction. This circumstance can be explained by the fact, that the corruption noise signal is now delayed to the reference noise signal, meaning, that the filter needs a certain length before it can be sufficently adapted. The results also show, that the \ac{SNR}-Gain is different for the different noise signals, indicating, that the noise signals have different characteristics, like the number of peaks, their frequency spectrum an their amplitude.\\ \\
|
||||
The mean \ac{SNR}-Gain of the different noise signals, also shown in Figure \ref{fig:fig_snr_comparison.png}, signals, that after reaching 95\% of the maximum \ac{SNR}-Gain, the \ac{SNR}-Gain increase is slowing down. This threshold is reached at a filter length of 45 taps. This means, that a filter length of 45 taps represents an optimal solution for a statisfying performance of the \ac{ANR} algorithm, while a further increase of the filter length does not lead to a significant increase of the \ac{SNR}-Gain in this setup. This is an important finding, as it allows to optimize the computational efficiency of the \ac{ANR} algorithm by choosing an appropriate filter length.
|
||||
\subsection{Evaluation of the computational load for a fixed update implementation}
|
||||
\subsection{Evaluation of a a fixed update implementation}
|
||||
\subsubsection{Full-Update implementation}
|
||||
\noindent Equation \ref{equation_computing_final} can now be utilized to calculate the needed cycles for the calculation of one sample of the filter output, using a filter length of 45 taps and an update of the filter coefficients every cycle. The needed cycles are calculated as follows:
|
||||
\begin{equation}
|
||||
@@ -77,12 +77,12 @@ As already mentioned, the reduction of the update rate is initially evaluated fo
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=1.0\linewidth]{Bilder/fig_snr_update_rate.png}
|
||||
\caption{Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the update rate of the ANR algorithm for the benchmark case. The baseline of 100\% is the full update implementation. The marked dots represent the results of the simulation for an explicit setup.}
|
||||
\caption{Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the update rate for the benchmark case. The baseline of 100\% is the full update implementation. The marked dots represent the results of the simulation for an explicit setup.}
|
||||
\label{fig:fig_snr_update_rate.png}
|
||||
\end{figure}
|
||||
|
||||
\noindent Figure \ref{fig:fig_snr_update_rate.png} descriptively illustrates the trend of the \ac{SNR}-Gain, the executed cycles per sample and the \ac{DSP} load compared to the full-update variant of the benchmark case. Contrary to the executed cycles per sample and the load of the processor, the \ac{SNR}-Gain does not behave linear over the course of reducing the update frequency. This behavior allows us to determinte the update rate, where the most benevolent ratio of \ac{SNR}-Gain in regard to \ac{DSP} load can be expected.\\ \\
|
||||
The maximum offset bewteen the two graphs can be cound found at an updat rate of 0.39, meaning, that an update of the filter coefficients is only conducted in roughly 2 out of 5 samples. Updating Equation \ref{equation_computing_calculation_full_update} and \ref{equation_load_calculation_full_update} therefore delivers:
|
||||
The maximum offset bewteen the two graphs can be found at an updat rate of 0.39, meaning, that an update of the filter coefficients is only conducted in roughly 2 out of 5 samples. Updating Equation \ref{equation_computing_calculation_full_update} and \ref{equation_load_calculation_full_update} therefore delivers:
|
||||
\begin{equation}
|
||||
\label{equation_computing_calculation_reduced_update_1}
|
||||
C_{total} = 45 + (6*45+8)*0.39 + 34 = 188 \text{ cycles}
|
||||
@@ -113,43 +113,94 @@ Now the same evaluation as in the previous subchapter is conducted for the five
|
||||
\end{equation}
|
||||
\begin{equation}
|
||||
\label{equation_load_calculation_reduced_update_2}
|
||||
Load_{DSP} = \frac{C_{total}}{C_{budget}} = \frac{188 \text{ cycles}}{800 \text{ cycles}} = 20.8 \%
|
||||
Load_{DSP} = \frac{C_{total}}{C_{budget}} = \frac{168 \text{ cycles}}{800 \text{ cycles}} = 20.8 \%
|
||||
\end{equation}
|
||||
Equation \ref{equation_computing_calculation_reduced_update_2} and \ref{equation_load_calculation_reduced_update_2} confirm, that for an update rate of 0.32, a reduction of the \ac{DSP} load to 20.8\% can be achieved, correlating with a performance gain of 24.9\%. This means, that for all viewed scenarios, an update rate of 0.32 represents the best cost-value ratio, for reducing the load while geting the best possible noise reduction. The relative performance for all scenarios result in a mean \ac{SNR}-Gain reduction of XX\% from 11.54 dB to XX.XX dB, while the load of the \ac{DSP} core is reduced by about 53.4\% from 44.6\% to 20.8\%.
|
||||
Equation \ref{equation_computing_calculation_reduced_update_2} and \ref{equation_load_calculation_reduced_update_2} confirm, that for an update rate of 0.32, a reduction of the \ac{DSP} load to 20.8\% can be achieved, correlating with a performance gain of 24.9\%. This means, that for all viewed scenarios, an update rate of 0.32 represents the best cost-value ratio, for reducing the load while geting the best possible noise reduction. The relative performance for all scenarios result in a mean \ac{SNR}-Gain reduction of 24.5\% from 11.54 dB to 8.72 dB, while the load of the \ac{DSP} core is reduced by about 53.4\% from 44.6\% to 20.8\%.
|
||||
\subsubsection{Computational load for reduced-update implementation}
|
||||
\subsection{Evaluation of the computational load for an error driven implementation}
|
||||
The most straight forward implmementation of a reduced update rate is through the use of a counter and a modulo operation, which checks, if for the current sample the filter coefficients has to be updated or not. The code must therefore be extended by two blocks which are responsible for additional computational load:
|
||||
\begin{gather}
|
||||
\label{equation_update_1}
|
||||
C_{increment\_counter} = 5 \text{ cycles} \\
|
||||
\label{equation_update_2}
|
||||
C_{check\_counter} = 23 (24) \text{ cycles}
|
||||
\end{gather}
|
||||
Incrementing the counter and checking if the counter has reached the update rate through a modulo operation adds 29 cycles to cycle count for one sample (28 when the coefficients are updated and 29 when they are not updated). Equation \ref{equation_computing_calculation_reduced_update_3} and \ref{equation_load_calculation_reduced_update_3} show the new calculation of the needed cycles and the load of the \ac{DSP} core for an update rate of 0.32:
|
||||
\begin{equation}
|
||||
\label{equation_computing_calculation_reduced_update_3}
|
||||
C_{total} = 45 + (6*45+8)*0.32 + 63 = 197 \text{ cycles}
|
||||
\end{equation}
|
||||
\begin{equation}
|
||||
\label{equation_load_calculation_reduced_update_3}
|
||||
Load_{DSP} = \frac{C_{total}}{C_{budget}} = \frac{197 \text{ cycles}}{800 \text{ cycles}} = 24.6 \%
|
||||
\end{equation}
|
||||
The results from the updated equations show, that the computational load for an update rate of 0.32 increase substantially from 20.8\% to 24.6\% through the use of a counter and a modulo operation, as the latter is quite computational expensive. A better alternative would be the use of a bitwise check, but this would reduce the possible update rates to powers of 2.
|
||||
\subsection{Evaluation of an error driven implementation}
|
||||
In contrary to the fixed update implementation of the previous chapter, the error-driven implementation is a more sophisticated approach, which focuses on an error metric, over which the decision for an coefficient update is made.
|
||||
The idea is, as the size update of the filter coefficients gets smaller, the benefit of updating them decreases. In practice, a closer look at the update of the filter coefficients is taken: As shown in Figure \ref{fig:fig_dsp_coefficient_cycle.jpg}, the size of the update of the filter coefficients is directly related to the error signal - if the error signal decreases, the update-size of the filter coefficients also decreases. \\ \\
|
||||
As the fixed update implementation is not able to detect such changes, the reduction in update frequency is applied in a static way, which means, that there are situations were it is beneficial and situations where it is not. The error-driven implementation, on the other hand, is able to detect such changing behaviorr and therefore can adapt the update frequency accordingly. Therefore, the error-driven implementation is expected to deliver a better cost-value ratio than the fixed update implementation.
|
||||
\subsubsection{Error threshold implementation for the benchmark case}
|
||||
In contrary to the fixed update implementation of the previous chapter, the error-driven implementation is a more sophisticated approach, which focuses on an error metric, over which the decision for an coefficient update is made. The idea is, that in a more static acoustic situation, the filter coefficients do not need to be updated as frequently as in a more dynamic situation, where the characteristics of the noise signal are changing more rapidly. As the fixed update implementation is not able to detect such changes, the reduction in update frequency is applied in a static way, which means, that there are situations were it is beneficial and situations where it is not. The error-driven implementation, on the other hand, is able to detect such changes and therefore can adapt the update frequency accordingly. Therefore, the error-driven implementation is expected to deliver a better cost-value ratio than the fixed update implementation. !!!It has to be taken into the mind, that this more complex approach also requires more computing power for the decision making, which affects the overall load of the \ac{DSP} core.!!!
|
||||
The chosen approach for this thessis the use a fixed error threshold. This means, that if the error signal remains below an, in advance set, certain threshold, the filter coefficients remain unchanged and are not updated. If the error signal exceeds the threshold, the filter coefficients are updated as in the full-update implementation. \\ \\ The crucial aspect of this approach, is the right choise of the error threshold, which is expected to be highly dependent on the acoustic situation. To get an idea of a beneficial error threshold, different values are initially evaluated for the already used benchmark case.\\ \\ The reduction in computational load must now be calculated for the whole audio track by the percentage of samples, where the error signal exceeds the threshold and therefore the coefficients are adapted. This means in detail, that if for a certain error threshold, 50000 of 200000 samples exceed said threshold, the filter coefficients are updated in 25\% of the samples - therefore the update rate of the filter coefficients amounts to 0.25. The result can therefore be expressed in the same way as for the fixed update implementation, where the update rate is directly calculated for one sample.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=1.0\linewidth]{Bilder/fig_snr_error_threshold.png}
|
||||
\caption{Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the fixed error threshold. The baseline is the full update variant the complex usecase. The marked dots represent the results of the simulation for an explicit setup.}
|
||||
\label{fig:fig_snr_error_threshold.png.png}
|
||||
\end{figure}
|
||||
\subsubsection{Error threshold implementaion for multiple noise signals}
|
||||
The first approach for the error-driven implementation is to use a fixed error threshold. This means, that if the error signal remains below an, in advance set, certain threshold, the filter coefficients remain unchanged and are not updated. If the error signal exceeds the threshold, the filter coefficients are updated as in the full-update implementation. \\ \\ The crucial aspect of this approach, is the right choise of the error threshold, which is expected to be highly dependent on the acoustic situation. To get an idea of a beneficial error threshold, different values are evaluated for the already used signal/noise benchmark of a male speaker disturbed by a breathing noise. The reduction in computational load must now be calculated for the whole audio track by the percentage of samples, where the error signal exceeds the threshold. This means in detail, that if for a certain error threshold, 50000 of 200000 samples exceed said threshold, the update rate of the filter coefficients amounts 0.25, which means that the filter coefficients are only updated in 25\% of the samples. The result can therefore be expressed in the same way as for the fixed update implementation, where the update rate is directly calculated for one sample.
|
||||
\caption{Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the error threshold for the benchmark case. The baseline of 100\% is the full update implementation. The marked dots represent the results of the simulation for an explicit setup.}
|
||||
\label{fig:fig_snr_error_threshold.png}
|
||||
|
||||
\end{figure}
|
||||
\noindent Our benchmark track is evaluated for error tresholds ranging from 0 to 0.5. The results, represented in Figure \ref{fig:fig_snr_error_threshold.png}, show for small thresholds, especially smaller than 0.1, a highly beneficial behavior can be anticipated, where the \ac{SNR}-Gain is only slightly reduced, while the load of the \ac{DSP} core significantly drops. The maximum offset between the two graphs can be found at an error threshold of 0.02 - at this point, the coefficient adaption is only conducted in ~81400 of 200000 samples, which equivalents an update rate of about 41\%. Updating Equation \ref{equation_computing_calculation_full_update} and \ref{equation_load_calculation_full_update} therefore delivers:
|
||||
\begin{equation}
|
||||
\label{equation_computing_calculation_error threshold_1}
|
||||
C_{total} = 45 + (6*45+8)*0.41 + 34 = 193 \text{ cycles}
|
||||
\end{equation}
|
||||
\begin{equation}
|
||||
\label{equation_load_calculation_error threshold_1}
|
||||
Load_{DSP} = \frac{C_{total}}{C_{budget}} = \frac{193 \text{ cycles}}{800 \text{ cycles}} = 24.1 \%
|
||||
\end{equation}
|
||||
The performance difference to reducing the update rate is already clearly for the benchmark case: With a similar \ac{DSP} load of 24.1\% (again, nearly half the load of the full update implementation), the \ac{SNR}-Gain is reduced by only 8.9\% from 9.47dB to 8.63 dB. The same analysis will be applied on all introduced noise signal, to get an idea of the general validity of the made observation.
|
||||
\subsubsection{Error threshold implementaion for multiple noise signals}
|
||||
Again, the same evaluation as for the benchmark case is conducted for the five introduced noise signals, featuring the the performance gain instead of the \ac{SNR}-Gain as a performance metric.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=1.0\linewidth]{Bilder/fig_gain_error_threshold.png}
|
||||
\caption{Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the fixed error threshold. The baseline is the full update variant the complex usecase. The marked dots represent the results of the simulation for an explicit setup.}
|
||||
\label{fig:fig_gain_error_threshold.png.png}
|
||||
\caption{Performance gain (distance between relative SNR-Gain and needed relative cycles/sample) in relation to the error threshold for different noise signals.}
|
||||
\label{fig:fig_gain_error_threshold.png}
|
||||
\end{figure}
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=1.0\linewidth]{Bilder/fig_load_error_threshold.png}
|
||||
\caption{Relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the fixed error threshold. The baseline is the full update variant the complex usecase. The marked dots represent the results of the simulation for an explicit setup.}
|
||||
\label{fig:fig_load_error_threshold.png.png}
|
||||
\caption{Absolute \ac{DSP} load in relation to the error threshold for different noise signals.}
|
||||
\label{fig:fig_load_error_threshold.png}
|
||||
\end{figure}
|
||||
\noindent Our benchmark track is evaluated for error tresholds ranging from 0 to 0.5. The results, represented in Figure \ref{fig:fig_snr_error_threshold.png.png}, show for small thresholds, especially smaller than 0.1, a highly beneficial behavior can be anticipated, where the \ac{SNR}-Gain is only slightly reduced, while the load of the \ac{DSP} core is significantly reduced. The maximum offset between the two graphs can be found at an error threshold of 0.02 - at this point the \ac{SNR}-Gain is reduced by only 8.9\% to 8.63 dB, while the coefficient adaption is only conducted in ~81400 of 200000 samples, which equivalents an update rate of about 41\%.
|
||||
\noindent Similar to the reduced update rate implementation, the obersvation made for every signal/noise combination is comparable to the benchmark case, but not the same. Figure \ref{fig:fig_gain_error_threshold.png} shows the performance gain for the five different scenarios. The most beneficial error threshold shifted noticeable to a value of 0.07. It´s interesting to notice, that the benchmark case seems to be a bit of an exception compared to the behavior of the other scenarios.\\ \\
|
||||
A mean error threshold of 0.07 results in a mean update of 38244 out of 200000 samples, which equivalents an update rate of 19.1\%. The \ac{DSP} load for all scenarios is now not the same anymore, but still quite similar - Figure \ref{fig:fig_load_error_threshold.png} shows the absolute load of the \ac{DSP} core for an error threshold of 0.07 results in only 16.6\%.
|
||||
\begin{equation}
|
||||
\label{equation_computing_calculation_error_threshold}
|
||||
C_{total} = 45 + (6*45+8)*0.407 + 34 = 192 \text{ cycles}
|
||||
\label{equation_computing_calculation_error_threshold_2}
|
||||
C_{total} = 45 + (6*45+8)*0.191 + 34 = 132 \text{ cycles}
|
||||
\end{equation}
|
||||
\begin{equation}
|
||||
\label{equation_load_calculation_error_threshold}
|
||||
Load_{DSP} = \frac{C_{total}}{C_{budget}} = \frac{192 \text{ cycles}}{800 \text{ cycles}} = 24.0 \%
|
||||
\label{equation_load_calculation_error_threshold_2}
|
||||
Load_{DSP} = \frac{C_{total}}{C_{budget}} = \frac{132 \text{ cycles}}{800 \text{ cycles}} = 16.6 \%
|
||||
\end{equation}
|
||||
Equation \ref{equation_computing_calculation_error_threshold_2} and \ref{equation_load_calculation_error_threshold_2} confirm, that for an error threshold of 0.07, a reduction of the \ac{DSP} load to 16.6\% can be achieved, correlating with a performance gain of 48.4\%. This means, that for all viewed scenarios, an error threshold of 0.07 represents the best cost-value ratio, for reducing the load while geting the best possible noise reduction. The relative performance for all scenarios result in a mean \ac{SNR}-Gain reduction of 11.7\% from 11.54 dB to 10.19 dB, while the load of the \ac{DSP} core is reduced by about 62.8\% from 44.6\% to 16.6\%.
|
||||
\subsubsection{Computational load for error threshold implementation}
|
||||
In contrary to the fixed update implementation, the error threshold implementation for a fixed error threshold does not require computational expensive operations: The threshold is implemented as a 32-bit integer which is simply checked for every sample by a single if-clause.
|
||||
\begin{gather}
|
||||
\label{equation_update_3}
|
||||
C_{check\_threshold} = 10 \text{ cycles}
|
||||
\end{gather}
|
||||
The check of the 32-bit threshold adds 10 cycles to cycle count for one sample.
|
||||
Equation \ref{equation_computing_calculation_error_threshold_3} and \ref{equation_load_calculation_error_threshold_3} show the new calculation of the needed cycles and the load of the \ac{DSP} core for an error threshold of 0.07:
|
||||
\begin{equation}
|
||||
\label{equation_computing_calculation_error_threshold_3}
|
||||
C_{total} = 45 + (6*45+8)*0.191 + 44 = 142 \text{ cycles}
|
||||
\end{equation}
|
||||
\begin{equation}
|
||||
\label{equation_load_calculation_error_threshold_3}
|
||||
Load_{DSP} = \frac{C_{total}}{C_{budget}} = \frac{142 \text{ cycles}}{800 \text{ cycles}} = 17.8 \%
|
||||
\end{equation}
|
||||
Contrary to the fixed update implementation, the computational load for an error threshold of 0.07 only shows only a minimal increase from 16.6\% to 17.8\% through the use of a computational cheap if-clause. This is a clear advantage compared to the fixed update implementation.
|
||||
\subsection{Summary of the performance evaluation}
|
||||
The results of the fixed error threshold implementation shows, that at it´s optimum setting, about the same reduction in needed cycles/sample than in the reduced updated implemenation can be achieved (188 vs 192 cycles), while the \ac{SNR}-Gain is reduced by only 8.9\% compared to 31\% for the reduced update implementation. This means, that the fixed error threshold implementation delivers a far better cost-value ratio than the fixed update implementation, while still being a rather simple approach.
|
||||
The results of two analysis can be summarized as follows: \\ \\ With the optimal filter length of 45 taps and an update rate of the filter coefficients every cycle, the \ac{ANR} algorithm is able to achieve a \ac{SNR}-Gain of about 11.54 dB, averaged over all different signal/noise combinations. Under this circumstances, the computational load of the \ac{DSP} core amounts about 45\%, which means that 55\% of the time, which a new sample takes to arrive, it can be halted, and therefore, the overall power consumption can be reduced.\\ \\
|
||||
A simple method to further reduce the load of the \ac{DSP} core is to reduce the update frequency of the filter coeffcients. For the benchmark signal/noise combination, an update rate of 0.39 nearly halfs the processor load from 44.6\% to 23.5\%, while only reducing the \ac{SNR}-Gain by rougly 31 \% from 9.47 dB to 6.40 dB. For all viewed scenarios, an update rate of 0.32 represents the best cost-value ratio, for reducing the load while geting the best possible noise reduction - with a mean \ac{SNR}-Gain reduction of 24.5\% from 11.54 dB to 8.72 dB, while the load of the \ac{DSP} core is reduced by about 53.4\% from 44.6\% to 20.8\%. While the perfromance benefit of this approach is reasonable, the computanional effort of the implementation is significant - the 20.8\% total load rise to 24.6\%\\ \\
|
||||
A more sophisticated method to reduce the load of the \ac{DSP} core is to use an error-driven implementation, where the update of the filter coefficients is only conducted, if the error signal exceeds a certain threshold. For the benchmark case, with a similar \ac{DSP} load of 24.1\% the \ac{SNR}-Gain is reduced by only 8.9\% from 9.47dB to 8.63 dB. For all viewed scenarios, an error threshold of 0.07 represents the best cost-value ratio, for reducing the load while geting the best possible noise reduction - with a mean \ac{SNR}-Gain reduction of 11.7\% from 11.54 dB to 10.19 dB, while the load of the \ac{DSP} core is reduced by about 62.8\% from 44.6\% to 16.6\%. This substentional performance gain is bought by only a slight increase in computing effort - the 16.6\% total load rise only to 17.8\%\\ \\
|
||||
This result proofes, that an error-driven implementation of the \ac{ANR} algorithm is highly suitable to reduce the load needed for adaptive noise reduction in a \ac{CI} application, while still providing nearly 90\% of the maximum achievable performance under the viewed circumstances.
|
||||
+15
-4
@@ -1,8 +1,19 @@
|
||||
\relax
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {6}Conclusion and outlook}{70}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {6}Conclusion and outlook}{72}{}\protected@file@percent }
|
||||
\acronymused{ANR}
|
||||
\acronymused{CI}
|
||||
\acronymused{SNR}
|
||||
\acronymused{ANR}
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
\acronymused{DSP}
|
||||
\acronymused{SNR}
|
||||
\acronymused{SNR}
|
||||
\acronymused{DSP}
|
||||
\acronymused{SNR}
|
||||
\@setckpt{chapter_06}{
|
||||
\setcounter{page}{71}
|
||||
\setcounter{equation}{40}
|
||||
\setcounter{page}{74}
|
||||
\setcounter{equation}{49}
|
||||
\setcounter{enumi}{0}
|
||||
\setcounter{enumii}{0}
|
||||
\setcounter{enumiii}{0}
|
||||
@@ -136,7 +147,7 @@
|
||||
\setcounter{lstnumber}{15}
|
||||
\setcounter{FancyVerbLine}{0}
|
||||
\setcounter{linenumber}{1}
|
||||
\setcounter{LN@truepage}{70}
|
||||
\setcounter{LN@truepage}{73}
|
||||
\setcounter{FancyVerbWriteLine}{0}
|
||||
\setcounter{FancyVerbBufferLine}{0}
|
||||
\setcounter{FV@TrueTabGroupLevel}{0}
|
||||
|
||||
@@ -1 +1,9 @@
|
||||
\section{Conclusion and outlook}
|
||||
The focus of this thesis was to investigate the possibilities for the efficient implementation of a real-time capable \ac{ANR} algorithm in \ac{CI} systems. The initial high-level implementation in Python proofed the general feasibility of the proposed method, where the \ac{SNR}-Gain was introduced as a metric for the quality of the \ac{ANR} algorithm. Said metric was used to evaluate the performance of the algorithm in various settings andnoise conditions. First a fictional signal and noise signal were used to check the algrotihm for it´s general functionality. Then the step to a real recorded signal was made. The final and most complex combination,s (which then served as a benchmark for the remaining implementations) was the use of a real wordls signals, which passed different transfer functions and delays. In every case, the algorithm was able to achieve significant performance improvement in the \ac{SNR} for the processed signals. \\ \\
|
||||
\noindent The next challenge was to implement the algorithm in a efficient way in the C prgramming language, to achieve real-time capability. This was achieved by the use of \ac{DSP} cimpiler instrinsic functions, which allow to perform logic operations wih a minimum of needed instructions. After the C-implementation was fucntional, the performacne in the case of the benchmark track was compared to the initial python implementation. A histrogram of the differences between the two ouptuts shows only minor deviations, which can be attributed to the fixed-point calculations of the \ac{DSP} compiler.\\ \\
|
||||
\noindent With the working C-implementation in place, a closer look on the performance, especially the needed cycles to compute on sample, was taken - the resulting formula is a function of the filter length and the update rate. With this information in mind, several noise sources were put under test, to evaluatue the optimal filter length, which is a trade-off between the performance improvement and the computational cost - the result was 45 coefficients.\\ \\
|
||||
With a known filter length of 45 coefficients, the final improvement of the algorithm regarding performance and computational cost could be evaluated. The base was the computational most costly full-update implementation, needing 357 cycles to process one sample.\\ \\
|
||||
\noindent The first approach was a rather simple reduction in the update rate, evaluated for the benchmark case and different signal/noise combinations. The result was a significant reduction in the needed cycles, but with a also quite significant drop in the \ac{SNR}-Gain. Additionaly, the implementation of such an universal reduction, required computational expensive processor operations, further reducing the cost-benefit-ration.\\ \\
|
||||
\noindent The second approach was the proposed method of an error driven optimization, utilizing the idea of a fixed threshold for the error signal. Again, evaluated for the benchmark case and different signal/noise combinations, this approach can be considered a success, as it was able to achieve a significant reduction in the needed cycles, while only reducing the \ac{SNR}-Gain by a small amount. The implementation of this method is also computationally efficient, as it only requires a simple comparison operation to check if an update is necessary.\\ \\
|
||||
\noindent The final result of this thesis shows, that the second method of an error driven optimization, utilizing the idea of a fixed threshold for the error signal, is a viable method to achieve significant performance improvement, reducing the computational load of the \ac{DSP} Core by over 62\% while only redcuing the \ac{SNR}-Gain by roughly 12\%.\\ \\
|
||||
\noindent For future work, a proposed method to further optimize the system would be the use of a dynamic threshold, which could be adapted to the current noise conditions. The background for this proposal is the fact, that beside the error-signal, also the noise signal itself influences the size of the filter-coeffcient update. In the current implementation, the threshold is only dependend on the error signal - if a sitatuion arises, where the noise signal is very small, but the error/output signal is high due to a a input signal, an update of the filter coefficients would be triggered, even if not necessary. A dynamic threshold, which also takes the noise signal into account, could further reduce the number of updates, but with a potentially higher computational effort.
|
||||
Reference in New Issue
Block a user