In engineering, the goal is always to solve a problem.  The most important
thing I learned from this project is that fully understanding the domain of
the problem is just as important, and perhaps equally as difficult, as
actually solving it.  We failed to complete the project at least in part due
to my initial misunderstanding of the MP3 specification, and that is why I
believe this was the most important lesson I learned.


How it actually happened:

While planning out our architecture we considered many possibilities, all
involving multiple processors.  We considered pipelining the decoding since
the software seemed suitable for that, but we feared we would end up with an
uneven distribution with one or two stages taking a large percentage of the
decoding time. Instead, we decided parallelism was the way to go.  After a bit
of research, including Christopher's MP3 lecture, I was convinced parallel
frame decoding was possible.  Everything I read said that frames were not
independent, but they all said it was due to the bit reservoir.  I figured
that was easy enough to fix, and I drew overlapping frames on the whiteboard
and worked out pseudocode to rearrange the data into separate chunks.  It all
seemed simple.  We committed ourselves to building it and got to work.

On March 18th, I discovered a very serious problem.  I ran the first
multithreaded version of the code using a single decoding thread and it worked
great.  With two decoding threads the sound was a bit garbled.  To my dismay,
the output continued to deteriorate as I added more threads.  Since this was
two months into the semester, we had already devoted an immense amount of time
to design and much to implementation.  Ugh oh!


How it should have happened:

In retrospect, building a less accurate simulation much sooner in the semester
would have saved us weeks of work.  I spent a lot of time carefully arranging
the code into functional blocks so we would have an accurate software model,
but it ended up being completely worthless.  Since I ran into the problem two
weeks before spring break and it took us a week to decide to change
architectures, I didn't get geared back up until weeks later.  All of this
should have been figured out in the early weeks of the semester so we wouldn't
have spent so much time walking in the wrong direction.  In the future I will
try to approach problems in a much more hierarchical manner to try to shake
out serious misconceptions while there is still time to correct for them.


If this happens again:

Whether I like it or not, I can imagine myself running into similar situations
in the working world.  Time constraints are very real, and mistakes happen.
In 545, I lost a lot of my motivation when all of my work to date had to be
thrown out, especially since we switched to an architecture that I found to be
much less interesting.  I honestly do not know how I can correct for this in
the future, but past experience will definitely help.