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. > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
