Analysis of FLAC – Stage Three of Three – SPO600 Project

Hello and welcome to my blog!

For my final post this series, about my SPO 600 project, I will discuss the last part of the project, the pull request to the upstream project. And, I will be reviewing what I have learned while working on this project.


Here is my the link to the pull request I created:

The FLAC project has an extensive testing system that gets run by the continuous integration system of Travis CI. It took 2 hours, 28 minutes and 15 seconds for Travis to finish the tests on my pull request. Travis builds and runs the FLAC program in 16 different ways for the test. There are four different build settings for that are tested, and each build setting gets compiled twice once by the GCC compiler and once by the CLANG compiler. Travis will run these eight tests twice once on a Linux machine and then once on a Mac OSX machine. To speed up the tests, Travis will run multiple test scenarios at a time. The full run-time of all the test scenarios is 6 hours and 57 seconds.

My changes passed all the tests Travis ran. That means the changes I made didn’t affect the regular operation of the program.

It has been a little over a week since I made the PR. It is currently not merged, and I have not heard from the project owner. The day I made the pull request, I got asked if the CPU feature detection that I did was at run-time or compile time? Initially, I thought the question was referring to the detection of the CPU architecture, which gets performed at compile time. After some discussion, I understood that the original question was referring to choosing the correct version of a function based on variables at run-time. Which I did implement, the selection of which autocorrelation function to run gets decided by the variable “encoder->protected_->max_lpc_order.” As far as I can tell, this question was by another member of the community and not a project maintainer, but I could be wrong.

Since that question, there has not been any more activity on the pull request.


This course and project have been a great learning experience for me. I have learned a lot about low-level programming through the lectures and the project. Especially about compilation, for this project, I learned a lot about the GNU auto-tools build system. I now know how to read and edit a configure script. With the practice I got from working with this project, I am now comfortable with the whole build process using a configure script and make.

Through this course and project, I also learned about using assembler and intrinsics in the C language. I was able to gain practical experience working with x86 and aarch64 intrinsics during this project. Specifically, I learned how to use the intrinsic documentation to find the correct intrinsic I need and to understand how to use each intrinsics.

This project was the first major C/C++ project I worked on. I learned a lot about the build process of a C/C++ project. For example, how to detect the hardware details and the available software on a computer.

I also gained a lot of practice with profilers. I used profilers in the past for previous course projects, but this project gave me a practical way I could practice using profilers. For example, by finding hot spots in a program and by helping measure the performance changes in the optimization, I do to the program.


I have enjoyed doing this project, and I am glad I could mix my interests in audio and computer programming. This project has been a great learning experience and I would be interested in doing this type of work in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *