Programming notes

Friture is mostly written in the programming language called Python.

Additionally, Friture uses the following libraries:

• PortAudio for cross-platform audio capture (Python bindings: Pyaudio),
• Numpy and Scipy for digital processing on the audio data,
• Qt for the graphical user interface (Python bindings: PyQt4),
• Qwt for the plot widgets (Python bindings: PyQwt).

Where performance is critical, some operations are specifically written in Cython, a programming language that provides C-extensions for Python. Meanwhile, some critical graphical operations are accelerated with OpenGL (Python bindings: PyOpenGL).

Here are some technical details about the design of Friture:

Initial design

Initially, the program was based on multiple processes: one gets the data from the soundcard, sends to the second for processing, which in turn sends to the third for display. Ultimately this scheme looked too complex and introduced too many synchronization issues.

Second design

A first rewrite was done to base the program on a single timer which periodically checks for audio data from the soundcard. Now there is one critical parameter : the period of that timer. It must obey to several time constraints:

1. The display should be as smooth as possible. Quantitatively, the various audio widgets should update every 20 ms or less (so a frequency of 50Hz and faster). At first, it was precisely set as the time needed to acquire 1024 samples at 44100 samples per second, which is 23,22 ms. Ideally, it should to be set to the vertical syncing period of the display.
2. The length of the FFT, which defines the number of points in the computed spectra, defines another time constant, which is the length N of the FFT times the sampling rate (typically 44100 samples per second). The longer the FFT is, the slower it gets refreshed. Also note that for algorithmic performance reasons, the FFT is best done on power-of-two lengths. So for the above setting (1024 samples per timer period), we can draw eight spectra at 128 points, four at 256 points, two at 512 points, one at 1024 points, and for higher numbers of points several ticks of the timer are needed.
3. The size of the rolling spectrogram window, in pixels, and the time dT associated with it, defines a time per pixel constraint. It means we should roll the window by one pixel every dT, by using the spectra which are available at that time.

Current design

The current scheme is based on multiple timers, with distinct period constraints. A first timer has a period of 20 ms (50 Hz) for smooth display update of the levels, scope and 1D spectrum widgets. The other timers have a period that is fixed by the display constraints of their associated widget. Currently, the rolling spectrogram widget uses such a custom timer. Its period is the time associated to one column of the rolling spectrogram. All timers first fetch the available data from the audio input, then pass the data to a circular audio buffer, and finally update their associated widget with the data contained in this audio buffer.

Profiling

To optimize the source code of Friture and make it suitable for run-time audio analysis with a computer of average power, profiling is essential. It has helped a lot writing efficient pieces like the rolling spectrogram, whose logic almost never appears in the profiles now. Learn more about the profiles.

---

Friture Homepage Download Friture