Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
d6fa993
commit 05b282a
Showing
2 changed files
with
12 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
Authors | ||
======= | ||
|
||
Emmett Butler: graphics programming and design | ||
David Coss: audio programming and design |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,10 @@ | ||
opengl_audio_vis | ||
================ | ||
|
||
Realtime 3D visualization of audio streams | ||
Written by Emmett Butler and David Coss in Fall 2012 | ||
|
||
This project provides realtime 3d visualization of mono and stereo WAV audio streams. The visualizations created are mainly abstract and can be considered an emulation of the iTunes (or, more accurately, WMP) visualizer. It uses OpenGL, freeglut, portaudio and libsndfile to create these visuals in real time. | ||
|
||
Invoked from the command line, the visualizer takes the name of an audio file and a number of flags specifying graphical behaviors. These can range from the basic flat waveform to a colorful, dynamic shape of constantly-changing data. | ||
|
||
The main challenge of the project (beyond learning a book's worth of 3D graphics theory and practice) was to properly synchronize the audio streaming with the graphics rendering loop. This is accomplished using a shared buffer contianing a number of renderable "screens" worth of audio waveform data. The audio streamer acts as a server that fills free slots in the buffer, and the graphics rendering client pulls data from the filled slots. Since the audio runs at a much faster rate than the graphics, the audio ends up waiting around a bit. This is ok, since it has plenty of heavy number-crunching capacity as visualizations grow more advanced. |