Hi,<br><br>I'm Ricard Marxer and I'm planning to apply for the GSOC Analyzer Support Idea presented by Ian Monroe:<br><br><a href="http://techbase.kde.org/Projects/Summer_of_Code/2009/Ideas#Project:_Analyzer_Support" target="_blank">http://techbase.kde.org/Projects/Summer_of_Code/2009/Ideas#Project:_Analyzer_Support</a><br clear="all">

<br>I have been exchanging some thoughts in the <a href="http://mail.kde.org/pipermail/amarok/2009-February/007726.html" target="_blank">Amarok mailinglist</a> and I wanted to also discussed it here, since this project is closely related to Phonon.<br>

<br>The main idea is to make audio visualizations (using Phonon to access audio data) for Amarok 2 similarly as what was available in Amarok 1.x.  Most visualizations there were spectral based and we would then need some processing of each audio frame to be able to this.<br>

<br>I know that there already exists an experimental class in Phonon to access the audio data (AudioDataOutput) which has been made for that purpose.<br><br>And the following questions arise:<br>A - Use AudioDataOutput and then perform some basic analysis (windowing, FFT, bands and weighting) outside of Phonon.<br>

<br>B - Create another class in Phonon (sth like AudioSpectrumOutput) that will do the processing and just throw dataReady() signals with a qvector with the magnitudes per spectral band.<br>
<br>C - Do A and if it proves interesting to Phonon go for B.  We could keep the processing we have implemented in A inside Phonon as a fallback, and then little by little switch to using the backends when/if they are capable of performing the processing needed.<br>
<br>Option A means doing the processing outside of the Phonon backends (personally I would choose FFTW and Eigen to do this processing).<br>
<br>Option B would mean that we could use processing algorithms that are already implemented in the backends and create in Phonon an interface for them.  Amarok 1.x performed the processing of the audio for visualizations in the gstreamer and xine backends (see Ian's answer in the mailinglist).  However we still must see if other backends have this capability.  Of course, like in the rest of Phonon we could always just expose it as a capability of the backend.<br>

<br>Option C might be the most appropiate since it is a flexible plan that will let us see as we go.<br><br>Another main objective of the project is to make the AudioDataOutput more mature by making use of it in a Plasma Applet that will wrap <a href="http://projectm.sourceforge.net/" target="_blank">ProjectM</a>. This will serve as an applet for Amarok's Context or even on the Plasma desktop for general visualization of audio passed through Phonon.<br>

<br>Any thoughts about this GSOC idea or the plan?<br><br>As for the long term, I think this could lead to having more AudioXXXOutput classes such as AudioOnsetOutput or AudioPitchOutput, so maybe a special Analysis namespace/submodule in Phonon would be interesting for this.<br>
<br><br>Note: I CC the amarok ML to keep them uptodate about the discussion.<br>-- <br>ricard<br><a href="http://www.ricardmarxer.com" target="_blank">http://www.ricardmarxer.com</a><br><a href="http://www.caligraft.com" target="_blank">http://www.caligraft.com</a><br>