Hi, On Mon, Feb 21, 2011 at 5:43 AM, Daniel Dewald <daniel.dew...@time-shift.de>wrote:
> On Sunday 20 February 2011 22:58:51 you wrote: > > Hi, > > > > thanks for the immediate reply. > > > > 2011/2/21 Daniel Dewald <daniel.dew...@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. > > Hmm.. I can wait a bit and may be try something myself, if the time permits :) > > > 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. > Yes, Jonatan has re-factored a lot of code, and also i was hoping to get it packaged really soon... so i dont think this will be a problem :) > > > > > 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. > > noted :) > > 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). > > Hmm.... Currently I was focussing on getting the GLWidget done, so haven't yet thought about Phonon related stuff. Have given myself till the mid march for the GLWidget related stuff to be completed. > > > 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. > Hmm... was thinking of 2 experiments to avoid this issue (1 is something like to find something like XEmbed for Qt and the other is embedding another QGraphicsView widget which is GL enabled, as a normal widget in the applet), but before that I need to find out why http://doc.trolltech.com/qq/qq26-openglcanvas.zip fails on my laptop (apparently the paint engine isnt OpenGL ...) will post back as soon as I get the results :) > 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. > Ya, so I will have a look into the audio data issue... > 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). > Hmm..... Cheers, Dinesh > Greez > > > Daniel > > _______________________________________________ > Amarok-devel mailing list > Amarok-devel@kde.org > https://mail.kde.org/mailman/listinfo/amarok-devel > >
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
