High Level Requirement #1: Guitar Effects

 

The primary requirement to test to verify the system's functionality is whether the audio effects proposed were achieved. The first high level Requirement states:

​

“The product shall be able to produce the following guitar audio effects: distortion, delay, reverb and modulation.”

​

The testing criteria requires us to do a qualitative analysis of generic time domain waveforms found for these effects. For the generic signals chosen, “Reaper” has built in effects that are generic and serve as a good benchmark from which to compare the effects created for this product. It is worth noting that due to the amount of different possible combinations for the parameters of these effects, some parameters of the generic effects were modified to provide appropriate comparison. This is because there are instances where parameters are intrinsically arbitrary numbers without units. Note also that an input waveform will be presented across these results, this is shown as a tool to compare the output of the effect to the input, especially for time related effects such as Delay and Reverb in which the feedback is more apparent when looking at the input. This input waveform presented is the input to the generic effect and does not have any alteration.

​

Distortion Effect

As presented earlier, the distortion effect seeks to provide the sensation of clipping found in vintage electronics. Soft clipping is desired in the output waveform from the distortion effect. This is seen both in the generic and the Raspberry Pi distortion. Compared to the input waveform, it was experienced in both Generic and Raspberry Pi waveforms that the peaks of the waveform turn flat like a square wave. . Figure 3.28 Distortion Effect Comparison. it is worth noting that from the waveform there are slight differences from the generic waveform as there are slight imperfections which are not present in the Raspberry Pi signal. Both effects also seem to have about the same signal levels on each peak and valley observed. 

​

​

 

 

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Delay Effect

​

For the delay effect comparison two effect conditions were tested, a long delay (1s) and a short delay (200ms). The purpose of the long delay test is to verify the behavior of the circular buffer, and the short delay is to compare the behavior when the input and output signals overlap. The long delay proved to be reproduced by the raspberry pi effect as seen in the figure. In this test it is noticeable that the input signal seen between the first 0-20000 samples was played back successfully by the effect around 48000 samples later, thus being a 1s delay. (since a sample frequency of 48kHz was used .

​

​

​

​

​

​

​

 

 

 

 

 

​

​

​

​

​

​

 

 

Comparable results were experienced when testing the short delay as the signal was played back having the delayed copy overlap the original signal. From Figure 3.30 is also worth noting that in the generic waveform the amplitude does deviate from the Raspberry Pi signal after the delay time, signaling the that the generic waveform does have a sort of decay that is not present in the raspberry pi signal. For this project's purposes, this can be safely ignored, as the lack of decay in the output wave does not stop the effect from being a delay effect. The presence of decay is more of a feature that a delay effect might have but not necessarily a requirement for it, unlike with the reverb effect in which the decay is intrinsic to the effect’s functionality.

 

 

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

 

 

Reverb Effect

​

The comparisons made for the previous two effects needs to be abstracted as the complexity of the effect scales up dramatically with Reverb. As referenced in the previous section, a reverb’s main characteristic is diffusion or decay [11], compared to the delay effect where this is more of a secondary byproduct of the effect. In general, a good reverb effect will be one in which the specific delay lines are not easily identifiable from one another and instead a diffused sound is achieved [11]. Here a clear limitation of the raspberry pi is noticeable as the diffused sound becomes more computationally expensive for longer decay times. In each of our diffusion steps presented in Section 3.2.1.3 we compute random volume levels for 8 different delay lines applied for each diffusion step, which depends on the “Size” parameter going from 8-13 diffusion steps. The problem is that when increasing the tail or diffusion time of the reverb, the number of delay lines is spread over a longer time interval, making the diffusion less noticeable for longer decay times. To account for this the system would ideally have more delay lines but since we are bound computationally by the performance of the Raspberry pi, the effect had to be limited to 8 delay lines per diffusion step to achieve the desired output with any tearing or distortion occurring from running out of time in our process block. the figure below displays this limitation, as for a 600ms reverb tail, the diffusion is not as consistent as the diffusion in the generic waveform. In the Raspberry Pi signal, individual delay taps are recognizable from the waveform itself, something indicating that the diffusion is too spread out.

 

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

For shorter reverb tails, a much better response was recorded as seen in the figure below for a 400ms tail, a much more gradual decay of the original signal was experienced, and no individual delay lines are identifiable in the time domain response of the effect suggesting that the diffusion experienced was much more consistent. Due to these observations, the Reverb effect had to be limited to a maximum tail of 400ms to meet the requirements for a Standard Reverb Effect. Figure 3.32 Reverb Effect Comparison: 400 ms Reverb Tail.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

​

 

 

 

​

Chorus Effect

Looking at the whole waveform tested in the Figure below it can be appreciated that the two waveforms closely resemble each other. The only noticeable difference between the Generic signal and the Raspberry Pi signal is that the Raspberry Pi’s modulation signal has a slight phase shift from that of the Generic signal. This is expected to be the case as the LFO modulating the raspberry pi signal and the generic signal start in different positions in time. This effect also passes the requirements as expected, since this effect was created using a JUCE Library. 

​

​

​

​

​

​

 

 

 

​

​

​

​

​

​

​

​

​

High Level Requirement #2 / Medium Level Requirement #1: Signal Comparison and Bypass:

Two requirements are combined in this section which is the high-level requirement:

 

“The system shall correctly process input sound from the guitar pickups and be available at the output with the same level as the pickup input (instrument level of –30 dB) “

 

And Medium level requirement:

​

“The guitar shall be able to bypass the guitar pickup signal to the output.“

 

Since the bypassed signal is the pickup signal itself (if we set the volume potentiometer is at 0Ω series resistance), this signal can be used to test the high-level requirement. This means that meeting the high-level requirement while using the signal bypassed by the switch, the medium level requirement will automatically be met. For testing this requirement, the same G3 note played for testing the effects requirements was played from both the bypassed pickup signal and the Raspberry Pi output. Note that the polarity on the Raspberry Pi was inverted in the Bandpass filter displayed on Section 3.3.1.2 in the report, since this does not constitute any audible difference the polarity of the raspberry Pi signal was inverted in our graphs for comparison purposes. The results from this recording are plotted in the Figure below. In the time domain signals it is noticeable that the signals preserve the same shape as well as roughly the same amplitudes. The raspberry Pi signal by design has less attack (less amplitude at the beginning) due to the High-pass filter, which removes lower frequencies that usually creates more attack on the strings. The latency shown in the previous requirement was removed to better compare the input and output waveform. Note that the amplitudes have been normalized to keep the results consistent. It is also worth noting that the signals will not match exactly one another due to the presence of the band-pass filter. Which is removing some high frequency components.

 

 

 

 

 

 

​

​

​

​

​

​

​

​

​

​

 

 

Looking at the frequency response of both signals, they appear to be similar as well. Note that in the lower frequencies, the effect of the High-Pass filter is noticeable in the 3-db the cut of the lower frequencies. Overall, the attenuation produced at the lower frequencies is greatly appreciated in these plots and is an expected response.

​

Pickup Signal Frequency Response

​

​

​

​

​

​

​

​

​

​

​

​

​

Raspberry Pi Clean Signal Frequency Response

 

​

​

 

 

 

 

 

 

​

​

​

​

​

When analyzing noise in more detail (recording while not playing anything), both signals have comparable noise. A slight high-pitched noise is present in the raspberry pi signal as seen around 10kHz. In general, the noise floor was also appreciated to be –18db after 1kHz for both signals. For frequencies less than 1kHz, the raspberry pi signal had a peak noise level of –12 dB while the pickup signal had a peak noise level of –6dB at lower frequencies.

​

Pickup Signal Noise:

​

​

​

​

​

​

​

​

​

​

​

​

​

Raspberry Pi Signal Noise:
 

​

​

​

​

​

​

​

​

​

​

​

​

High Level Requirement #3: I/O Latency

​

“The system shall have no more than 10 ms latency between guitar input from pickups and output signal.”

Compared to the previous requirement, this one is simple to verify. A sound cable was connected directly to the pickups and compared to the output signal from the raspberry pi’s DAC. The measured latency recorded when playing was 6 ms, which meets our engineering requirement of 10 ms delay.

​

​

​

 

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Low-Level Requirement: Battery Life

“Product shall be able to remain powered on for 4 hours with the display active.”

The following test was conducted to confirm that the chosen power bank will sufficiently power the system. To power a Raspberry Pi 4B a power supply of 5V and 3A (15W) is required without peripherals attached. This system will have peripherals attached that have a minor draw on the battery. The battery purchased for this project has an output of 5V at 4A, which will be enough for the Raspberry Pi and its peripherals. This test would first analyze the output voltage when plugged into its designated power supply. This was around 5.1-5.28 V, and when strain was added to the Pi, the voltage dropped to 5.06V. The Pi was then connected to the Power Bank, and it survived a boot, the first test was a success. The voltage was tested and received around 4.99-5.03V, and when the strain was added to the CPU, 4.95-4.98V was the drop. This test was also successful and was ready to move on to the next test. This test dealt with going into the system configuration and overclocking the CPU. The config file had the CPU frequency at 0.6 GHz in which it was increased to 1.75 GH. The system was then rebooted to test to see if the power was sufficient to boot the Raspberry Pi. The voltage received from the output was 5.03V and can now confirm that this test passed. The CPU was then completely maxed out at 2.14 GHz to test extreme strain. It survived a reboot without warning and successfully performed with strain on the CPU. The output voltage was 4.90-5.0V and passed all tests. The power bank can be used to power the Pi.

The Raspberry Pi overclocked and played YouTube videos to keep the system working as if it were at a concert. Speakers were then connected to the Pi to draw power and a monitor was connected using the HDMI port and the frequency changes were then analyzed. The system maintained the 2.14 GHz intended and stayed in the desired output voltage ranges. The plan of the test was to run the system until the power bank died. The system ran for four hours, our minimum requirement, and the power bank was still alive. This test was also a pass and will be used to power our system. The power bank has a capacity of 10,000 mAh and will be more than plenty for our system.