Hi: Regarding VSXu Applet

Mon Feb 21 21:13:17 CET 2011

Hi,

On Mon, Feb 21, 2011 at 5:43 AM, Daniel Dewald
<Daniel.Dewald at 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.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.
>
>
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 at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20110222/e14e5bce/attachment-0001.htm 