Latex/Masterarbeit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Abgabe

Browse Source
This commit is contained in:
patha
2026-05-17 13:29:48 +02:00
parent edaab00dd2
commit 38aa63d2fc
12 changed files with 100 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files
chapter_05.tex
+9 -9
View File
@@ -70,13 +70,13 @@ Now the same evaluation as in the previous subchapter is conducted for the five
\begin{figure}[H]
\centering
\includegraphics[width=1.0\linewidth]{Bilder/fig_gain_update_rate.png}
\caption{Performance gain (distance between relative SNR-Gain and needed relative cycles/sample) in relation to the update rate of the ANR algorithm for different noise signals.}
\caption{Performance gain (distance between relative SNR-Gain and needed relative cycles/sample) in relation to the update rate of the ANR algorithm for different noise signals}
\label{fig:fig_gain_update_rate.png}
\end{figure}
\begin{figure}[H]
\centering
\includegraphics[width=1.0\linewidth]{Bilder/fig_load_update_rate.png}
\caption{Absolute \ac{DSP} load in relation to the update rate of the ANR algorithm for different noise signals.}
\caption{Absolute \ac{DSP} load in relation to the update rate of the ANR algorithm for different noise signals}
\label{fig:fig_load_update_rate.png}
\end{figure}
\noindent Figure \ref{fig:fig_gain_update_rate.png} shows the performance gain for the five different scenarios. The mean performance gain for all scenarious now wandered to an update rate of 0.32. Figure \ref{fig:fig_load_update_rate.png} shows the load of the \ac{DSP} core for the different update rates, which is the same for all scenarios, as it is only dependent on the update rate itself.
@@ -95,9 +95,9 @@ The most straight forward implementation of a reduced-update rate is through the
\label{equation_update_1}
\text{C}_{\text{increment\_counter}} = 5 \text{ cycles} \\
\label{equation_update_2}
\text{C}_{\text{check\_counter}} = 23 (24) \text{ cycles}
\text{C}_{\text{check\_counter}} = 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:
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. 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}
\text{C}_{\text{total}} = 45 + (6*45+8)*0.32 + 63 = 197 \text{ cycles}
@@ -112,7 +112,7 @@ In contrary to the fixed update implementation of the previous chapter, the erro
The idea is, as the update size 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 Equation \ref{equation_lms}, 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 behavior 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-driven implementation for the benchmark case}
The chosen approach for an error-driven implementation is 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.
The chosen approach for an error-driven implementation is 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.\\ \\ 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}
@@ -134,13 +134,13 @@ Again, the same evaluation as for the benchmark track is conducted for the five
\begin{figure}[H]
\centering
\includegraphics[width=1.0\linewidth]{Bilder/fig_gain_error_threshold.png}
\caption{Performance gain (distance between relative SNR-Gain and needed relative cycles/sample) in relation to the error threshold for different noise signals.}
\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{Absolute \ac{DSP} load in relation to the error threshold for different noise signals.}
\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 Similar to the reduced-update rate implementation, the observation made for every signal/noise combination is similar to the benchmark case. 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.\\ \\
@@ -173,14 +173,14 @@ Equation \ref{equation_computing_calculation_error_threshold_3} and \ref{equatio
Contrary to the reduced-update implementation, the computational load for an error threshold of 0.07 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. In the case of the benchmark track, the load rises from 24.1\% to 25.7\%.
\subsection{Summary of the performance evaluation}
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 these 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\%. Figure \ref{fig:fig_snr_update_rate_new.png} shows the updated plot of the relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the update rate for the benchmark case, where the higher load is indicated by the newly added continuous grahps. The initial graphs are still slightly visible allowing a better comparison of the two implementations.
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\% averagetotal load rise to 24.6\%. Figure \ref{fig:fig_snr_update_rate_new.png} shows the updated plot of the relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the update rate for the benchmark case, where the higher load is indicated by the newly added continuous grahps. The initial graphs are still slightly visible allowing a better comparison of the two implementations.
\begin{figure}[H]
\centering
\includegraphics[width=1.0\linewidth]{Bilder/fig_snr_update_rate_new.png}
\caption{Updated plot of the 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 higher load is indicated by the newly added continuous lines.}
\label{fig:fig_snr_update_rate_new.png}
\end{figure}
\noindent 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\% (compared to the reduced-update implementation), the \ac{SNR}-Gain is reduced by only 8.9\% from 9.47 dB to 8.63 dB. For all viewed scenarios, an error threshold of 0.07 represents the best cost-value ratio - 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\%\\ \\
\noindent 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\% (compared to the reduced-update implementation), the \ac{SNR}-Gain is reduced by only 8.9\% from 9.47 dB to 8.63 dB. For all viewed scenarios, an error threshold of 0.07 represents the best cost-value ratio - 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\% average 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. Again, Figure \ref{fig:fig_snr_error_threshold_new.png} shows the updated plot of the relative performance of the SNR-Gain, the cycles per samples and the DSP load in regard of the error threshold for the benchmark case.
\begin{figure}[H]
\centering