Team Status Report for 2/11
The most significant risks that could jeopardize the success of the project. Risk management and contingency plans.
The most significant risk as of right now is the RT pitch detection. This is the main feature of the project and it is crucial that we get this component working. While we are attempting to approach this feature with a homegrown algorithm, we recognize that audio modules have many optimizations that might not be feasible to implement by hand. As performance is such a big factor, it’s reasonable that we auto-fallback on using the audio module if we know that’s the optimal solution. This is our approach/plan to mitigating risks associated with this feature.
Changes made to the existing design of the system (requirements, block diagram, system spec, etc). Along with an explanation of why it was necessary, what costs the change incurs, and how these costs be mitigated going forward.
After presenting and gathering feedback on our project proposal presentation, we have multiple strategies and changes to our design to minimize the latency between the user’s raw voice input and the feedback:
- Use a head-mounted mic so we have a close-talking signal to aid in the recognition and minimize background noise.
As our main goal is to reduce the amount of latency between the raw input signal and the feedback given to the user, this change is necessary to reduce the amount of signal processing needed. The monetary cost will depend on the type of headset chosen from Amazon. However, this does reduce the accessibility of our project, as people may not have the resources to buy a mic.
We may use this method of gathering signals at first in the early stages of our signal processing algorithm to verify that RT feedback is feasible, and then as we add complexity to our algorithm, we may revert back to cheaper/more common headphones.
- Develop the website locally to reduce web latency.
We have changed our goal of hosting the website on AWS to be a stretch goal. Because latency of pitch detection is so important to our project, we want to reduce latency elsewhere whenever possible. Hosting locally will mean not having to worry about AWS network latency and will help us achieve quick feedback to vocal input. This decreases our project scope, although it may be worth trying out hosting on AWS to see if we are correct in thinking that the network latency is disruptive to user experience, or if it is not noticeable.
- [Tentative] Use a module for signal processing.
As stated already, this would greatly reduce the amount of lag. Audio modules have many backend optimizations that may not be feasible to implement, so it may be necessary to make this change. There are no costs, however, we did have concerns about the complexity of our project if we made this change. We have asked our advisors for input, and are waiting on a response.
These changes do not negatively impact our schedule. If anything, if the module usage is approved, it would shift our time table up.
Photos of our progress and components we are proud of.
This week, we were quite proud of our UI mockups that can also be found on our figma.
These mockups were able to get us excited about the end goal of our project as well as facilitate some important discussions on how exactly our project should be presented from a user’s perspective.
Public health, safety and welfare, along with other global, cultural, societal, environmental and economic considerations.
Our project includes considerations for affordability and accessibility. With the goal of our project being to foster a casual environment, we chose to opt for less expensive headset microphones as well as strive to make our project run on just a computer microphone alone. Additionally, we decided on a web app to allow anyone to use our project with special consideration put into the UI as well as real time feedback to encourage the user to get better without fostering a negative environment (i.e. negative feedback being constructive and non-personal rather than mean and pointed).