Thanks for the quick answer!<br><br>See below for some thoughts.<br><br><div class="gmail_quote">On Thu, Feb 26, 2009 at 1:44 AM, Ian Monroe <span dir="ltr"><<a href="mailto:ian.monroe@gmail.com">ian.monroe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Wed, Feb 25, 2009 at 2:19 PM, Ricard Marxer Piñón<br>
<<a href="mailto:email@ricardmarxer.com">email@ricardmarxer.com</a>> wrote:<br>
> Hi,<br>
><br>
> I'm Ricard Marxer and I'm planning to apply for the GSOC Analyzer Support<br>
> Idea presented by Ian Moore:<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>
><br>
> Ideas extending GSOC Analyzer Support proposal<br>
> -----------------------------------------------------------------<br>
><br>
> Data:<br>
> I have seen that Phonon offers an experimental AudioDataOutput class made<br>
> for the purpose of visualization and analysis.  This is the obvious entry<br>
> point for accessing the audio frames to perform further processing.<br>
<br>
</div>Yep! Whoever ends up mentoring, you'll probably be getting some<br>
direction from Kretz (the creator of Phonon) or maybe one of the<br>
Trolls especially on API issues.<br>
<div class="Ih2E3d"><br>
> Processing:<br>
> As for the library to be used for the mathematical processing of the audio<br>
> (FFT, MFCC, Onset Detection, Pitch Estimation...) I would like to use Eigen,<br>
> since it makes the code very readable and clear and it is highly optimized.<br>
> I would of course use some external libraries for some specific algos such<br>
> as FFTW.<br>
<br>
</div>I'm not sure how much processing is needed and how much is already<br>
done by Xine and/or Gstreamer. Eigen is pretty nifty though yea. :)<br>
<br>
Here's an example of a Xine plugin used to give Amarok analyzer<br>
information from Amarok 1.4:<br>
<a href="http://kollide.net:8060/browse/Amarok/src/engine/xine/xine-scope.c?r=10660" target="_blank">http://kollide.net:8060/browse/Amarok/src/engine/xine/xine-scope.c?r=10660</a><br>
And GstEngine::scope() from Amarok 1.4:<br>
<a href="http://kollide.net:8060/browse/Amarok/src/engine/gst/gstengine.cpp?r=2375" target="_blank">http://kollide.net:8060/browse/Amarok/src/engine/gst/gstengine.cpp?r=2375</a><br>
<br>
In both cases the code is probably utterly worthless, just showing you<br>
the sort of stuff you might end up doing on the backend side.<br>
</blockquote><div><br>I'm still wondering what processing should be done inside the backend and which outside.<br><br>Phonon already provides an experimental class which gives access to the audio frames as they arrive.  The class emits signals of the type dataReady(QMap<channel, vector of samples>).<br>
<br>The simplest processing would be to apply a windowing function, an FFT  and some weighting, scaling and band processing (for a simple EQ visualization).  If we do this outside of Phonon (e.g. using FFTW and Eigen) we don't have to duplicate the work for several backends.<br>
<br>However, some more complex processing/analysis (such as some onset detection and pitch estimation methods) require buffering since they may act on several overlapping frames.  In these cases backends can be very helpful.  It might even be that some of these backends already have this kind of methods implemented, have to check.<br>
<br>For really fast visualization such as smooth scrolling spectrograms we will also require some sort buffering, but I'm not so sure how Phonon could expose an interface for such specific techniques and how many of the backends would ease the task on making them.  This is something I will have to research a bit.<br>
<br>Next, I will contact Matthias to get some input from him.  About all this.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>

Given your experience using audio analysis techniques I'm sitting here<br>
wondering if perhaps we could expand the project to give applications<br>
access to the raw decoded audio. This would be useful for some other<br>
things we want to do in Amarok, and it would let you do more advanced<br>
analysis stuff. (The first priority is still the basic Codeine/Amarok<br>
1.4 analyzer though).<br>
<div class="Ih2E3d"><br>
> Visualization:<br>
> Here is where I would like to ask for some help about what would be the best<br>
> choice.  I think to start with, the simplest thing would be to first hook<br>
> the output of the processing directly to a Graphics View.<br>
> If you guys think it is a good idea it might be nice to have the Graphics<br>
> View inside a plasma applet (which could then fit in Amarok's context view).<br>
<br>
</div>Actually some of the analyzers in Amarok 1.4 were pretty cool and<br>
could probably be ported. Some used QPainter and others used OpenGL to<br>
do 3D stuff. QGV would also make sense.<br>
<br>
Probably for the bigger plasmoid-sized visualizations (as opposed to<br>
analyzers) we would want to use <a href="http://projectm.sourceforge.net/" target="_blank">http://projectm.sourceforge.net/</a>. Like<br>
the 'giving access to raw audio' idea above we might be getting out of<br>
scope for the project depending on what you want to do.<br>
<div class="Ih2E3d"></div></blockquote><div><br>I didn't know about ProjectM thanks for the link, it looks really good.  And since Phonon already exposes the audio frames, I think it shouldn't be too much work to connect these to and create ProjectM Plasma applet as part of the GSOC.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> Notes:<br>
> Of course the main goal is to have the lowest possible hit in CPU and still<br>
> keep beautiful visualization.  Also it should be possible to completely turn<br>
> off the audio processing and visualization when in power saving mode.<br>
><br>
> Anyway, this is just to create some discussion about the directions the idea<br>
> could take.  What do you all think?<br>
<br>
</div>I'm really glad that someone is taking an interest in this. As you can<br>
see there's some flexibility on where you want to make the emphasis of<br>
your proposal.<br>
<br>
A little inside baseball (sorry don't know a more international term,<br>
lol): this project has a decent chance of being selected as<br>
kdelibs-related projects (and Phonon at least used to be in kdelibs)<br>
typically aren't proposed so often but have a lot of people voting for<br>
them since they help out many parts of KDE. Making this clear in your<br>
proposal would be good politics.</blockquote><div><br>Yes, you are right I'm going to have to narrow down the exact goals and select them smartly so that it can advantage the most of KDE.  I think creating a good base for applications wanting to analyze audio (whether it is for visualization or content based organization) could be good direction.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<font color="#888888"><br>
Ian<br>
</font></blockquote></div><br>Well everything is still a bit ripe, but I will try to contact Matthias Kretz to get things clearer.<br clear="all"><br>-- <br>ricard<br><a href="http://www.ricardmarxer.com">http://www.ricardmarxer.com</a><br>
<a href="http://www.caligraft.com">http://www.caligraft.com</a><br>