Hi: Regarding VSXu Applet

[Daniel Dewald]

On Sunday 20 February 2011 22:58:51 you wrote:
> Hi,
> 
> thanks for the immediate reply.
> 
> 2011/2/21 Daniel Dewald <Daniel.Dewald at time-shift.de>
> 
> > Hi,
> > 
> > Take my good advice and don't put any more work into this. Phonon's Audio
> > Data
> > Output is not working in 90% of all phonon Backends and from what I've
> > heard
> > so far will not be working in any future. I've already designed and
> > implemented a working OpenGL Amarok applet and realized a spectrum
> > analyzer with it. After that I was waiting for the backends to finally
> > get the Data Output working and stabilized.. they won't. I tried begging
> > and complaining and even tried to force the issue.. nobody is interested
> > in this kind of work.
> > Without the phonon audio data output all the work becomes meaningless.
> > You should have talked with the vsxu maintainer (or the Amarok devs) and
> > he would've told you.
> 
> Markey said that the Phonon issues have been fixed in the VLC backend, but
> don't exactly know if it is the same issues that have blocked your work.
> 

The audio data output stuff of vlc has be changed recently. I haven't tested it 
yet since I'm currently working on my bachelor thesis and this has not a very 
hight priority for me anymore. For other backends the same applies. I was 
waiting (and begging) for almost 5 month to improve the situation and nothing 
changed then. Maybe you have more luck, maybe not. I'll test the backend if 
time allows and report my results to you asap (though this may take somewhat 
longer). Since I've waited long for this I won't get my hopes up before I know 
otherwise. The audio data output of the vlc backend is at least stable. Xine 
will crash Amarok after every song if the audio data output is used.

> > Also vsxu is currently not yet in a state where it is
> > likely to be put into any distribution. As long as its not distributed
> > properly an vsxu applet is not likely to be placed into the official
> > Amarok
> 
> trunk (This however is a problem that could be solved in a small time
> 
> > window).
> 
> I think this can be fixed too.. isnt it?

The VSXU maintainer is a very nice an reasonable person. Until I had to bring 
him the news of (as mark put it) "my failure" he did everything  he could to 
support my efforts and bring his code in a state that would be accepted by 
distros. I only wish I could've done the same for him and bring VSXU into 
Amarok. So yes thats definitely an issue that CAN be solved in reasonable time.

> 
> > Sorry to kill the dreams but I've already put a tremendous amount of work
> > into
> > this and all for nothing.
> 
> This really can't be an option for me because I ve already submitted this
> for my course project, and so dropping this out means a really hard time
> for me :(
> 

If you want to do some OSS stuff in the future I humbly recommend contacting 
the maintainers and dev's first and do some research whether or not someone 
else tried to do this and he / she failed why so. Otherwise work might be done 
twice and that will either piss you off or the guy who's work you're crossing. 
Just a suggestion.


> So may be if you can enlist the issues, then I can try fixing them one by
> one..
> 

The only thing thats standing between you and a workable visualization plugin 
is a workable audio data output in all the major backends the users use. 
Otherwise you have very nice visualization with no connection to the sound 
you're hearing whatsoever. Or you have a lot of angry users and devs because 
Amarok is crashing or hanging all the time. I doubt such a patch will make it 
into trunk (which is the reason why my spectrum analyzer and my fingerprinter 
never where included and why I did stop my work on the visualization after 
some disappointments of other kind).

> > If you want to display any other (non audio data
> > related) OpenGL stuff just give me a call. My applet might need some
> > over-howl
> > but was working the last time I tried it. However it uses quite some
> > hacks because the Amarok context area does not support OpenGL pre se
> > (because its not an opengl applet area).
> 
> You mean rendering it onto a label right? I was looking onto it, and was
> actually looking for other alternatives to this. Also was searching for
> something that doesn't use a timer to refresh the QGLWidget... (something
> like vsync, but apparently we don't have such an option - even the Gluon
> guys use a timer)
> 

Yes. My applet renders into a label. Is nasty, its ugly and its (so far) the 
only possible way. Plasma applets can use OpenGL. But then the whole viewport 
of the applet must be an OpenGL context (which means all other applets that 
use the same viewport must use OpenGL also). Since the context area of amarok 
shares one viewport with all applets you'd have to rewrite all the applets to 
get the desired result. Uncool I guess :-P.

If you still want to continue your work I'll assist you in any way I can. If 
you get the audio data output working you can use my OpenGL applet. All you'll 
have to do is take care of the rendering stuff then. This applet also enables 
the audio data output in Amarok and connects the applet to it. The downside is 
that the audio data output stuff is in the core. So whether you use the applet 
or not, the audio source will be connected to the audio data output which is 
then connected to the sink. And since audio data output is unstable in some 
backends, Amarok will crash (with xine backend) hang (with gstreamer backend) 
or just don't give you audio data (with vlc backend) whether you use the 
applet or not. So before this could be used, all backends would at least have 
to be in a state where they don't crash or hang the app. Otherwise users (and 
devs) won't like your patch very much ;o). The upside is that as soon as its 
working every applet (or any other part of amaroks code) can simply connect 
itself to the audio data ouput to get access to the audio data (which means my 
spectrum analyzer applet would also work).


Greez


Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2921 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20110221/b072e340/attachment.p7s